Rollup of 10 pull requests
Successful merges:
- #52885 (Remove some unused method arguments from typeck)
- #52886 (cleanup: Remove `Def::GlobalAsm`)
- #53028 (Building librustc_codegen_llvm in a separate directory)
- #53052 (fixed broken links to char)
- #53060 (Change rustdoc style so fully qualified name does not overlap src link)
- #53068 (Rename Executor trait to Spawn)
- #53093 (Enable macros to pass $:literal to another macro)
- #53107 (Remove references to `StaticMutex` which got removed a while ago)
- #53135 (Rust 2018: Disable catch_expr, not targeted for 2018 edition)
- #53139 (set emit_debug_gdb_scripts: false for riscv32imac-unknown-none target)
Remove references to `StaticMutex` which got removed a while ago
`StaticMutex` got removed two years ago with https://github.com/rust-lang/rust/pull/34705, but still got referenced in some comments and even an error explanation.
Rename Executor trait to Spawn
Renames the `Executor` trait to `Spawn` and the method on `Context` to `spawner`.
Note: Best only merge this after we've the alpha 3 announcement post ready.
r? @cramertj
Building librustc_codegen_llvm in a separate directory
This allows clearing it out and building it separately from the
compiler. Since it's essentially a different and separate crate this
makes sense to do, each cargo invocation should generally happen in its
own directory.
r? @alexcrichton
Extract impl_header_lifetime_elision out of in_band_lifetimes
This way we can experiment with `impl Debug for &MyType` separately from `impl Debug for &'a MyType`.
I can't say I know what the code in here is doing, so please let me know if there's a better way 🙂
I marked this as enabled in 2018 so that edition code continues to work without another flag.
Actual feature PR https://github.com/rust-lang/rust/pull/49251; Tracking Issue https://github.com/rust-lang/rust/issues/15872; In-band lifetimes tracking issue https://github.com/rust-lang/rust/issues/44524.
cc @aturon, per discussion on discord earlier
cc @cramertj & @nikomatsakis, who actually wrote these features
Add errors for unknown, stable and duplicate feature attributes
- Adds an error for unknown (lang and lib) features.
- Extends the lint for unnecessary feature attributes for stable features to libs features (this already exists for lang features).
- Adds an error for duplicate (lang and lib) features.
```rust
#![feature(fake_feature)] //~ ERROR unknown feature `fake_feature`
#![feature(i128_type)] //~ WARNING the feature `i128_type` has been stable since 1.26.0
#![feature(non_exhaustive)]
#![feature(non_exhaustive)] //~ ERROR duplicate `non_exhaustive` feature attribute
```
Fixes#52053, fixes#53032 and address some of the problems noted in #44232 (though not unused features).
There are a few outstanding problems, that I haven't narrowed down yet:
- [x] Stability attributes on macros do not seem to be taken into account.
- [x] Stability attributes behind `cfg` attributes are not taken into account.
- [x] There are failing incremental tests.
Fix ICE when rustdoc encounters certain usages of HRTBs
Fixes#51236
Under certain circumstances, `AutoTraitFinder` could end up computing a `ParamEnv` involving two trait predicates that differed only in the region parameters involved. One of these parameters would be a HRTB, while the other would be a normal region parameter.
When this `ParamEnv` was later passed to `SelectionContext`, an `Ambiguity` error would occur, since the erased versions of these predicates would be identical. To solve the issue, we de-duplicate our list of predicates as we build it up. Whenever we encounter two predicates that differ only in their assignment of region parameters (a HRTB vs a normal lifetime parameter), we pick the HRTB. This corresponds to selecting a 'stricter' bound to display in the generated documentation: we're requiring that a particular type works for all possible lifetime parameters if it's going to implement a particular auto trait.
This allows clearing it out and building it separately from the
compiler. Since it's essentially a different and separate crate this
makes sense to do, each cargo invocation should generally happen in its
own directory.
Fix NLL migration mode so that reports region errors when necessary.
The code here was trying to be clever, and say "lets not report diagnostics when we 'know' NLL will report an error about them in the future."
The problem is that in migration mode, when no error was reported here, the NLL error that we "knew" was coming was downgraded to a warning (!).
Thus causing #53026
(I hope it is the only instance of such a scenario, but we will see.)
Anyway, this PR fixes that by only doing the "clever" skipping of region error reporting when we are not in migration mode. As noted in the FIXME, I'm not really thrilled with this band-aid, but it is small enough to be back-ported easily if that is necessary.
Rather than make a separate test for issue 53026, I just took the test that uncovered this in a first place, and extended it (via our revisions system) to explicitly show all three modes in action: AST-borrowck, NLL, and NLL migration mode.
(To be honest I hope not to have to add such revisions to many tests. Instead I hope to adopt some sort of new `compare-mode` for either borrowck=migrate or for the 2018 edition as a whole.)
Fix#53026
dead-code lint: say "constructed" for structs
Respectively.
This is a sequel to November 2017's #46103 / 1a9dc2e9. It had been
reported (more than once—at least #19140, #44083, and #44565) that the
"never used" language was confusing for enum variants that were "used"
as match patterns, so the wording was changed to say never "constructed"
specifically for enum variants. More recently, the same issue was raised
for structs (#52325). It seems consistent to say "constructed" here,
too, for the same reasons.
~~While we're here, we can also use more specific word "called" for unused
functions and methods. (We declined to do this in #46103, but the
rationale given in the commit message doesn't actually make sense.)~~
This resolves#52325.
