Perform `cfg` attribute processing during macro expansion and fix bugs
This PR refactors `cfg` attribute processing and fixes bugs. More specifically:
- It merges gated feature checking for stmt/expr attributes, `cfg_attr` processing, and `cfg` processing into a single fold.
- This allows feature gated `cfg` variables to be used in `cfg_attr` on unconfigured items. All other feature gated attributes can already be used on unconfigured items.
- It performs `cfg` attribute processing during macro expansion instead of after expansion so that macro-expanded items are configured the same as ordinary items. In particular, to match their non-expanded counterparts,
- macro-expanded unconfigured macro invocations are no longer expanded,
- macro-expanded unconfigured macro definitions are no longer usable, and
- feature gated `cfg` variables on macro-expanded macro definitions/invocations are now errors.
This is a [breaking-change]. For example, the following would break:
```rust
macro_rules! m {
() => {
#[cfg(attr)]
macro_rules! foo { () => {} }
foo!(); // This will be an error
macro_rules! bar { () => { fn f() {} } }
#[cfg(attr)] bar!(); // This will no longer be expanded ...
fn g() { f(); } // ... so that `f` will be unresolved.
#[cfg(target_thread_local)] // This will be a gated feature error
macro_rules! baz { () => {} }
}
}
m!();
```
r? @nrc
Fix `asm-misplaced-option` on ARM/AArch64
This fixesrust-lang/rust#33737. Of course, since we don't run `make check` for ARM cross builds, you probably won't notice it.
Fix handling of FFI arguments
r? @eddyb @nikomatsakis or whoever else.
cc @alexcrichton @rust-lang/core
The strategy employed here was to essentially change code we generate from
```llvm
%s = alloca %S ; potentially smaller than argument, but never larger
%1 = bitcast %S* %s to { i64, i64 }*
store { i64, i64 } %0, { i64, i64 }* %1, align 4
```
to
```llvm
%1 = alloca { i64, i64 } ; the copy of argument itself
store { i64, i64 } %0, { i64, i64 }* %1, align 4
%s = bitcast { i64, i64 }* %1 to %S* ; potentially truncate by casting to a pointer of smaller type.
```
Fixes to mir dataflow
Fixes to mir dataflow
This collects a bunch of changes to `rustc_borrowck::borrowck::dataflow` (which others have pointed out should probably migrate to some crate that isn't tied to the borrow-checker -- but I have not attempted that here, especially since there are competing approaches to dataflow that we should also evaluate).
These changes:
1. Provide a family of related analyses: MovingOutStatements (which is what the old AST-based dataflo computed), as well as MaybeInitialized, MaybeUninitalized, and DefinitelyInitialized.
* (The last two are actually inverses of each other; we should pick one and drop the other.)
2. Fix bugs in the pre-existing analysis implementation, which was untested and thus some obvious bugs went unnoticed, which brings us to the third point:
3. Add a unit test infrastructure for the MIR dataflow analysis.
* The tests work by adding a new intrinsic that is able to query the analysis state for a particular expression (technically, a particular L-value).
* See the examples in compile-fail/mir-dataflow/inits-1.rs and compile-fail/mir-dataflow/uninits-1.rs
* These tests are only checking the results for MaybeInitialized, MaybeUninitalized, and DefinitelyInitialized; I am not sure if it will be feasible to generalize this testing strategy to the MovingOutStatements dataflow operator.
Make sure that macros that didn't pass LHS checking are not expanded.
This avoid duplicate errors for things like invalid fragment specifiers, or
parsing errors for ambiguous macros.
Save metadata even with -Z no-trans (e.g. for multi-crate cargo check).
Removes the item symbol map in metadata, as we can now generate them in a deterministic manner.
The `-Z no-trans` change lets the LLVM passes and linking run, but with just metadata and no code.
It fails while trying to link a binary because there's no `main` function, which is correct but not good UX.
There's also no way to easily throw away all of the artifacts to rebuild with actual code generation.
We might want `cargo check` to do that using cargo-internal information and then it would just work.
cc @alexcrichton @nikomatsakis @Aatch @michaelwoerister
Allow `concat_idents!` in type positions as well as in expression positions
This allows the `concat_idents!` macro in type positions as well as in expression positions.
r? @nrc
Use libc::abort, not intrinsics::abort, in rtabort!
intrinsics::abort compiles down to an illegal instruction, which on
Unix-like platforms causes the process to be killed with SIGILL. A more
appropriate way to kill the process would be SIGABRT; this indicates
better that the runtime has explicitly aborted, rather than some kind of
compiler bug or architecture mismatch that SIGILL might indicate.
For rtassert!, replace this with libc::abort. libc::abort raises
SIGABRT, but is defined to do so in such a way that it will terminate
the process even if SIGABRT is currently masked or caught by a signal
handler that returns.
On non-Unix platforms, retain the existing behavior. On Windows we
prefer to avoid depending on the C runtime, and we need a fallback for
any other platforms that may be defined. An alternative on Windows
would be to call TerminateProcess, but this seems less essential than
switching to using SIGABRT on Unix-like platforms, where it is common
for the process-killing signal to be printed out or logged.
This is a [breaking-change] for any code that depends on the exact
signal raised to abort a process via rtabort!
cc #31273
cc #31333
intrinsics::abort compiles down to an illegal instruction, which on
Unix-like platforms causes the process to be killed with SIGILL. A more
appropriate way to kill the process would be SIGABRT; this indicates
better that the runtime has explicitly aborted, rather than some kind of
compiler bug or architecture mismatch that SIGILL might indicate.
For rtassert!, replace this with libc::abort. libc::abort raises
SIGABRT, but is defined to do so in such a way that it will terminate
the process even if SIGABRT is currently masked or caught by a signal
handler that returns.
On non-Unix platforms, retain the existing behavior. On Windows we
prefer to avoid depending on the C runtime, and we need a fallback for
any other platforms that may be defined. An alternative on Windows
would be to call TerminateProcess, but this seems less essential than
switching to using SIGABRT on Unix-like platforms, where it is common
for the process-killing signal to be printed out or logged.
This is a [breaking-change] for any code that depends on the exact
signal raised to abort a process via rtabort!
cc #31273
cc #31333
rustdoc: Add doc snippets for trait impls, with a read more link
The read more link only appears if the documentation is more than one line long.
It currently does not appear on non-defaulted methods, since you can document them directly. I could make it so that default documentation gets forwarded if regular docs don't exist.
Fixes#33672
r? @alexcrichton
cc @steveklabnik
rustbuild: Touch up some test suites
This adds in some missing test suites, primarily a few pretty suites. It also starts optimizing tests by default as the current test suite does, but also recognizes `--disable-optimize-tests`.
Currently the optimization of tests isn't recognized by crate tests because Cargo doesn't support the ability to compile an unoptimized test suite against an optimized library. Perhaps a feature to add, though!
Originally fixed in #29961 the bug was unfortunately still present in the face
of crates using `#[macro_use]`. This commit refactors for the two code paths to
share common logic to ensure that they both pick up the same bug fix.
Closes#33762
rustc: Add a new crate type, cdylib
This commit is an implementation of [RFC 1510] which adds a new crate type,
`cdylib`, to the compiler. This new crate type differs from the existing `dylib`
crate type in a few key ways:
* No metadata is present in the final artifact
* Symbol visibility rules are the same as executables, that is only reachable
`extern` functions are visible symbols
* LTO is allowed
* All libraries are always linked statically
This commit is relatively simple by just plubming the compiler with another
crate type which takes different branches here and there. The only major change
is an implementation of the `Linker::export_symbols` function on Unix which now
actually does something. This helps restrict the public symbols from a cdylib on
Unix.
With this PR a "hello world" `cdylib` is 7.2K while the same `dylib` is 2.4MB,
which is some nice size savings!
[RFC 1510]: https://github.com/rust-lang/rfcs/pull/1510Closes#33132
This commit is an implementation of [RFC 1510] which adds a new crate type,
`cdylib`, to the compiler. This new crate type differs from the existing `dylib`
crate type in a few key ways:
* No metadata is present in the final artifact
* Symbol visibility rules are the same as executables, that is only reachable
`extern` functions are visible symbols
* LTO is allowed
* All libraries are always linked statically
This commit is relatively simple by just plubming the compiler with another
crate type which takes different branches here and there. The only major change
is an implementation of the `Linker::export_symbols` function on Unix which now
actually does something. This helps restrict the public symbols from a cdylib on
Unix.
With this PR a "hello world" `cdylib` is 7.2K while the same `dylib` is 2.4MB,
which is some nice size savings!
[RFC 1510]: https://github.com/rust-lang/rfcs/pull/1510Closes#33132
