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.
When missing a comma in a macro call, suggest it, regardless of
position. When a macro call doesn't match any of the patterns, check
if the call's token stream could be missing a comma between two idents,
and if so, create a new token stream containing the comma and try to
match against the macro patterns. If successful, emit the suggestion.
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
Previously it was only emitted for assigments, which was an
unnecessary restriction. Now it doesn't care where the mutability
comes from.
This commit also adds `` quotes around the printed type.
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).
