- Makes the warning part of the `intra_doc_link_resolution_failure`
lint.
- Tightens the span to just the ambiguous link.
- Reports ambiguities across all three namespaces.
- Uses structured suggestions for disambiguation.
- Adds a test for the warnings.
Musl host toolchain
Based on https://github.com/rust-lang/rust/pull/55163 and https://github.com/rust-lang/rust/pull/57359
Depends on https://github.com/rust-lang/rust/pull/55566
CC https://github.com/rust-lang/rust/issues/57439
### How it works
Tested compiler made by `dist` on glibc and musl based distributions and verified binaries it produces:
* Ubuntu (glibc) - installed it as a target for host toolchain and observed no regressions for static (default) linking, dynamic linking apparently requires musl build libgcc so I didn't test it.
* Alpine (musl) - installed as the host toolchain, by default it links statically (executables are portable and work on glibc distributions) but with `-C target-feature=-crt-static` Rust flag it links dynamically (executables require musl built libraries).
### What's debatable
It should be decided whether this toolchain should link dynamically or statically when using it on musl distribution. I believe the distributions would prefer dynamic linking but it'd be misleading because `$ARCH-unknown-linux-musl` target links statically on the other hosts.
Another problem is using `RUSTFLAGS='-C target-feature=-crt-static'` for dynamic builds which is really uncomfortable.
To address both issues I suggest leaving `$ARCH-unknown-linux-musl` static for both host and cross target and introducing "alias triple" `$ARCH-unknown-linux-dynmusl`. It'd be the same as `$ARCH-unknown-linux-musl` (and use the same libraries to avoid duplication) but it'd link dynamically.
<del>
### Why it's still WIP (help wanted)
I'm having a hard time getting all tests to pass and I'd appreciate help.
Non-verbose error:
<details>
```
Testing proc_macro stage1 (x86_64-unknown-linux-musl -> x86_64-unknown-linux-musl)
Compiling proc_macro v0.0.0 (/checkout/src/libproc_macro)
error[E0463]: can't find crate for `std`
error[E0463]: can't find crate for `std`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0463`.
error: aborting due to previous error
For more information about this error, try `rustc --explain E0463`.
[RUSTC-TIMING] proc_macro test:true 0.529
[RUSTC-TIMING] proc_macro test:false 0.530
error: Could not compile `proc_macro`.
warning: build failed, waiting for other jobs to finish...
error: Could not compile `proc_macro`.
To learn more, run the command again with --verbose.
command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "x86_64-unknown-linux-musl" "-j" "16" "--release" "--locked" "--manifest-path" "/checkout/src/libtest/Cargo.toml" "-p" "proc_macro" "--"
expected success, got: exit code: 101
failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test --host x86_64-unknown-linux-musl --target x86_64-unknown-linux-musl
```
</details>
Verbose error:
<details>
```
Testing proc_macro stage1 (x86_64-unknown-linux-musl -> x86_64-unknown-linux-musl)
Compiling proc_macro v0.0.0 (/checkout/src/libproc_macro)
Running `/checkout/obj/build/bootstrap/debug/rustc --edition=2018 --crate-name proc_macro src/libproc_macro/lib.rs --color never --crate-type lib --emit=dep-info,link -C opt-level=2 -C metadata=09ddd3ecc930ab63 -C extra-filename=-09ddd3ecc930ab63 --out-dir /checkout/obj/build/x86_64-unknown-linux-musl/stage1-test/x86_64-unknown-linux-musl/release/deps --target x86_64-unknown-linux-musl -L dependency=/checkout/obj/build/x86_64-unknown-linux-musl/stage1-test/x86_64-unknown-linux-musl/release/deps -L dependency=/checkout/obj/build/x86_64-unknown-linux-musl/stage1-test/release/deps -C target-feature=-crt-static`
Running `/checkout/obj/build/bootstrap/debug/rustc --edition=2018 --crate-name proc_macro src/libproc_macro/lib.rs --color never --emit=dep-info,link -C opt-level=2 --test -C metadata=a564d363930469c8 -C extra-filename=-a564d363930469c8 --out-dir /checkout/obj/build/x86_64-unknown-linux-musl/stage1-test/x86_64-unknown-linux-musl/release/deps --target x86_64-unknown-linux-musl -L dependency=/checkout/obj/build/x86_64-unknown-linux-musl/stage1-test/x86_64-unknown-linux-musl/release/deps -L dependency=/checkout/obj/build/x86_64-unknown-linux-musl/stage1-test/release/deps -C target-feature=-crt-static`
error[E0463]: can't find crate for `std`
error[E0463]: can't find crate for `std`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0463`.
error: aborting due to previous error
For more information about this error, try `rustc --explain E0463`.
[RUSTC-TIMING] proc_macro test:false 0.248
error: Could not compile `proc_macro`.
Caused by:
process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustc --edition=2018 --crate-name proc_macro src/libproc_macro/lib.rs --color never --crate-type lib --emit=dep-info,link -C opt-level=2 -C metadata=09ddd3ecc930ab63 -C extra-filename=-09ddd3ecc930ab63 --out-dir /checkout/obj/build/x86_64-unknown-linux-musl/stage1-test/x86_64-unknown-linux-musl/release/deps --target x86_64-unknown-linux-musl -L dependency=/checkout/obj/build/x86_64-unknown-linux-musl/stage1-test/x86_64-unknown-linux-musl/release/deps -L dependency=/checkout/obj/build/x86_64-unknown-linux-musl/stage1-test/release/deps -C target-feature=-crt-static` (exit code: 1)
warning: build failed, waiting for other jobs to finish...
[RUSTC-TIMING] proc_macro test:true 0.248
error: Could not compile `proc_macro`.
Caused by:
process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustc --edition=2018 --crate-name proc_macro src/libproc_macro/lib.rs --color never --emit=dep-info,link -C opt-level=2 --test -C metadata=a564d363930469c8 -C extra-filename=-a564d363930469c8 --out-dir /checkout/obj/build/x86_64-unknown-linux-musl/stage1-test/x86_64-unknown-linux-musl/release/deps --target x86_64-unknown-linux-musl -L dependency=/checkout/obj/build/x86_64-unknown-linux-musl/stage1-test/x86_64-unknown-linux-musl/release/deps -L dependency=/checkout/obj/build/x86_64-unknown-linux-musl/stage1-test/release/deps -C target-feature=-crt-static` (exit code: 1)
command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "x86_64-unknown-linux-musl" "-j" "16" "--release" "--locked" "--manifest-path" "/checkout/src/libtest/Cargo.toml" "--verbose" "-p" "proc_macro" "--"
expected success, got: exit code: 101
failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test --host x86_64-unknown-linux-musl --target x86_64-unknown-linux-musl
```
</details>
Whole tests non-verbose output: [rust-tests.log](https://github.com/rust-lang/rust/files/2879945/rust-tests.log)
I think the error is because build system (correctly?) tries to use `obj/build/x86_64-unknown-linux-musl/stage1-test/x86_64-unknown-linux-musl/release/deps` which is empty but `obj/build/x86_64-unknown-linux-gnu/stage1-test/x86_64-unknown-linux-musl/release/deps` contains required libs.
</del>
The musl-target doesn't automatically disable static linking of musl when building a dylib, and then complains it can't build a dylib.
As a workaround, disable static linking via RUSTFLAGS, to see how far the build gets.
The proper fix is to have rustc figure that out automagically.
Update cargo
6 commits in 95b45eca19ac785263fed98ecefe540bb47337ac..0e35bd8af0ec72d3225c4819b330b94628f0e9d0
2019-03-06 19:24:30 +0000 to 2019-03-13 06:52:51 +0000
- Make `hg` optional for tests. (rust-lang/cargo#6739)
- Fingerprint build script deps only for path packages. (rust-lang/cargo#6734)
- Add --quiet option for `cargo test` (rust-lang/cargo#6358)
- .gitignore should end with a newline. (rust-lang/cargo#6732)
- Emit warning on misspelled environment variables (rust-lang/cargo#6694)
- Update glob requirement from 0.2.11 to 0.3.0 (rust-lang/cargo#6724)
resolve: Simplify import resolution for mixed 2015/2018 edition mode
Non-controversial part of https://github.com/rust-lang/rust/pull/57745.
Before:
| Local edition (per-span) | Global edition (--edition) | Imports (`use foo;`) | Absolute paths (`::foo`) |
| ------------- |----------------|-----------------------------------------|------------------------------------------------|
| 2018 | Any | Uniform | Extern prelude |
| 2015 | 2015 | Crate-relative | Crate-relative |
| 2015 | 2018 | Crate-relative with fallback to Uniform (future-proofed to error if the result is not Crate-relative or from Extern prelude) | Crate-relative with fallback to Extern prelude |
After:
| Local edition (per-span) | Global edition (--edition) | Imports (`use foo;`) | Absolute paths (`::foo`) |
| ------------- |----------------|-----------------------------------------|------------------------------------------------|
| 2018 | Any | Uniform | Extern prelude |
| 2015 | 2015 | Crate-relative | Crate-relative |
| 2015 | 2018 | Crate-relative with fallback to Extern prelude | Crate-relative with fallback to Extern prelude |
I.e. only the behavior of the mixed local-2015-global-2018 mode is changed.
This mixed mode has two goals:
- Address regressions from https://github.com/rust-lang/rust/pull/56053#issuecomment-440826397.
Both "before" and "after" variants address those regressions.
- Be retrofit-able to "full 2015" edition (https://github.com/rust-lang/rust/pull/57745).
Any more complex fallback scheme (with more candidates) than "Crate-relative with fallback to Extern prelude" will give more regressions than https://github.com/rust-lang/rust/pull/57745#issuecomment-455855089 and is therefore less retrofit-able while also being, well, more complex.
So, we can settle on "Crate-relative with fallback to Extern prelude".
(I'll hopefully proceed with https://github.com/rust-lang/rust/pull/57745 after mid-February.)
r? @Centril
Rollup of 16 pull requests
Successful merges:
- #58829 (librustc_interface: Update scoped-tls to 1.0)
- #58876 (Parse lifetimes that start with a number and give specific error)
- #58908 (Update rand version)
- #58998 (Fix documentation of from_ne_bytes and from_le_bytes)
- #59056 (Use lifetime contravariance to elide more lifetimes in core+alloc+std)
- #59057 (Standardize `Range*` documentation)
- #59080 (Fix incorrect links in librustc_codegen_llvm documentation)
- #59083 (Fix#54822 and associated faulty tests)
- #59093 (Remove precompute_in_scope_traits_hashes)
- #59101 (Reduces Code Repetitions like `!n >> amt`)
- #59121 (impl FromIterator for Result: Use assert_eq! instead of assert!)
- #59124 (Replace assert with assert_eq)
- #59129 (Visit impl Trait for dead_code lint)
- #59130 (Note that NonNull does not launder shared references for mutation)
- #59132 (ignore higher-ranked object bound conditions created by WF)
- #59138 (Simplify Iterator::{min, max})
Failed merges:
r? @ghost
Simplify Iterator::{min, max}
This PR simplifies the `select_fold1` helper method used to implmement `Iterator::{min, min_by, min_by_key, max, max_by, max_by_key}` by removing the projection argument, which was only used by the implementations of `min_by_key` and `max_by_key`.
I also added tests to ensure that the stability as mentioned in the comments of `min` and `max` is preserved, and fixed the `iter::{bench_max, bench_max_by_key}` benchmarks which the compiler presumably was able to collapse into closed-form expressions. None of the benchmark results were impacted, I suspect their generated assembly didn't change.
ignore higher-ranked object bound conditions created by WF
In the `issue-53548` test added in this PR, the `Box<dyn Trait>` type is expanded to `Box<dyn Trait + 'static>`, but the generator "witness" that results is `for<'r> { Box<dyn Trait + 'r> }`. The WF code was encountering an ICE (when debug-assertions were enabled) and an unexpected compilation error (without debug-asserions) when trying to process this `'r` region bound. In particular, to be WF, the region bound must meet the requirements of the trait, and hence we got `for<'r> { 'r: 'static }`. This would ICE because the `Binder` constructor we were using was assering that no higher-ranked regions were involved (because the WF code is supposed to skip those). The error (if debug-asserions were disabled) came because we obviously cannot prove that `'r: 'static` for any region `'r`. Pursuant with
our "lazy WF" strategy for higher-ranked regions, the fix is not to require that `for<'r> { 'r: 'static }` holds (this is also analogous to what we would do for higher-ranked regions appearing within the trait in other positions).
Fixes#53548
r? @pnkfelix
Reduces Code Repetitions like `!n >> amt`
Fixes#49937 .
This PR contains defining a function which operates bit inversion and reducing bit operation like `!0u128 >> (128 - size.bits())`.
Fix#54822 and associated faulty tests
Type checking associated constants can require trait bounds, but an empty
parameter environment was provided to the trait solver. Providing an
appropriate parameter environment seems to fix#54822 and also make one of the
cases in src/test/ui/nll/trait-associated-constant.rs that should compile
successfully do so. It also (slightly) improves the error message in
src/test/ui/associated-const/associated-const-generic-obligations.rs
Standardize `Range*` documentation
This updates the final example in the documentation for the types
`Range`, `RangeFrom`, `RangeFull`, `RangeInclusive`, `RangeTo`,
`RangeToInclusive`.
Use lifetime contravariance to elide more lifetimes in core+alloc+std
Sample:
```diff
- impl<'a, 'b, A: ?Sized, B: ?Sized> PartialEq<&'b mut B> for &'a mut A where A: PartialEq<B> {
+ impl<A: ?Sized, B: ?Sized> PartialEq<&mut B> for &mut A where A: PartialEq<B> {
#[inline]
- fn eq(&self, other: &&'b mut B) -> bool { PartialEq::eq(*self, *other) }
+ fn eq(&self, other: &&mut B) -> bool { PartialEq::eq(*self, *other) }
#[inline]
- fn ne(&self, other: &&'b mut B) -> bool { PartialEq::ne(*self, *other) }
+ fn ne(&self, other: &&mut B) -> bool { PartialEq::ne(*self, *other) }
}
```
[I didn't know this worked](https://internals.rust-lang.org/t/why-can-you-use-different-unconstrained-lifetimes-to-implement-traits/9544/2?u=scottmcm) until recently, but since defining methods contravariantly in their lifetimes this way has worked back to Rust 1.0, we might as well take advantage of combining it with IHLE.
Fix documentation of from_ne_bytes and from_le_bytes
Copypasta mistake, the documentation of `from_ne_bytes` and `from_le_bytes` used the big-endian variant in the example snippets.
