rustc: Tweak visibility of some lang items
This commit tweaks the linker-level visibility of some lang items that rustc
uses and defines. Notably this means that `#[panic_implementation]` and
`#[alloc_error_handler]` functions are never marked as `internal`. It's up to
the linker to eliminate these, not rustc.
Additionally `#[global_allocator]` generated symbols are no longer forced to
`Default` visibility (fully exported), but rather they're relaxed to `Hidden`
visibility). This symbols are *not* needed across DLL boundaries, only as a
local implementation detail of the compiler-injected allocator symbols, so
`Hidden` should suffice.
Closes#51342Closes#52795
Add HirId to VisibilityKind::Restricted
I'm not confident that these changes are correct -- mostly just tried to copy previous PRs.
Specifically, it's unclear to me if/how to remove the NodeId now that we have HirIds in more structs; is that a all-at-once change that'll happen later?
revert #52991
Reverts https://github.com/rust-lang/rust/pull/52991 which is flawed. I have an idea how to fix it but might as well revert first since it is so wildly flawed. That's what I get for opening PRs while on PTO =)
r? @pnkfelix
This commit tweaks the linker-level visibility of some lang items that rustc
uses and defines. Notably this means that `#[panic_implementation]` and
`#[alloc_error_handler]` functions are never marked as `internal`. It's up to
the linker to eliminate these, not rustc.
Additionally `#[global_allocator]` generated symbols are no longer forced to
`Default` visibility (fully exported), but rather they're relaxed to `Hidden`
visibility). This symbols are *not* needed across DLL boundaries, only as a
local implementation detail of the compiler-injected allocator symbols, so
`Hidden` should suffice.
Closes#51342Closes#52795
The previous iteration was a large `match` which was quite heavily indented,
making it slightly difficult to read and see what was going on. This iteration
is a refactoring (no functional change intended) to make it a bit easier on the
eyes and a bit easier to modify over time.
Place unions, pointer casts and pointer derefs behind extra feature gates
To ensure we don't stabilize these things together with const fn stabilization (or any other stabilization)
This PR moves union field accesses inside `const fn` behind a feature gate. It was possible without a feature gate before, but since `const fn` was behind a feature gate we can do this change.
While "dereferencing raw pointers" and "casting raw pointers to usize" were hard errors before this PR, one could work around them by abusing unions:
```rust
// deref
union Foo<T> {
x: &'static T,
y: *const T,
}
const FOO: u32 = unsafe { *Foo { y: 42 as *const T }.x };
// as usize cast
union Bar<T> {
x: usize,
y: *const T,
}
const BAR: usize = unsafe { Bar { y: &1u8 }.x };
```
r? @eddyb
cc @nikomatsakis
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.
