Apply some fixes to cross-language LTO (especially when targeting MSVC)
This PR contains a few fixes that were needed in order to get Firefox compiling with Rust/C++ cross-language ThinLTO on Windows. The commits are self-contained and should be self-explanatory.
r? @alexcrichton
clarify partially initialized Mutex issues
Using a `sys_common::mutex::Mutex` without calling `init` is dangerous, and yet there are some places that do this. I tried to find all of them and add an appropriate comment about reentrancy.
I found two places where (I think) reentrancy can actually occur, and was not able to come up with an argument for why this is okay. Someone who knows `io::lazy` and/or `sys_common::at_exit_imp` should have a careful look at this.
[NLL] Use span of the closure args in free region errors
Also adds a note when one of the free regions is BrEnv.
In a future PR I'll change these messages to say "return requires", which should improve them a bit more.
r? @nikomatsakis
Make IpvXAddr::new const fns and the well known addresses associated constants
Implements/fixes https://github.com/rust-lang/rust/issues/44582
I just got a PR towards libc (https://github.com/rust-lang/libc/pull/1044) merged. With the new feature added in that PR it is now possible to create `in6_addr` instances as consts. This enables us to finally make the constructors of the IP structs const fns and to make the localhost/unspecified addresses associated constants, as agreed in the above mentioned tracking issue.
I also added a BROADCAST constant. Personally this is the well known address I tend to need the most often.
resolve: Support custom attributes when macro modularization is enabled
Basically, if resolution of a single-segment attribute is a determined error, then we interpret it as a custom attribute.
Since custom attributes are integrated into general macro resolution, `feature(custom_attribute)` now requires and implicitly enables macro modularization (`feature(use_extern_macros)`).
Actually, a few other "advanced" macro features now implicitly enable macro modularization too (and one bug was found and fixed in process of enabling it).
The first two commits are preliminary cleanups/refactorings.
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
with ThinLTO and cross-lang-lto.
Normally, when compiling with whole-crate-graph ThinLTO, we expect
rustc's LTO step to "uplift" upstream object files/LLVM modules to
the current set of compilation artifacts. Therefore the staticlib
creation code skips this uplifting. However, when compiling with
"cross-language LTO" (i.e. defer LTO to the actual linker), the LTO
step in rustc is not performed, so we have to take care of copying
upstream object files during archive creation (like we already do
when compiling without any LTO).
