Reject a LHS formed of a single sequence TT during `macro_rules!` checking.
This was already rejected during expansion. Encountering malformed LHS or RHS during expansion is now considered a bug.
Follow up to #33689.
r? @pnkfelix
Note: this can break code that defines such macros but does not use them.
refactor autoderef to avoid prematurely registering obligations
Refactor `FnCtxt::autoderef` to use an external iterator and to not
register any obligation from the main autoderef loop, but rather to
register them after (and if) the loop successfully completes.
Fixes#24819Fixes#25801Fixes#27631Fixes#31258Fixes#31964Fixes#32320Fixes#33515Fixes#33755
r? @eddyb
Increase spacing in error format for readability.
Two small tweaks that seem to help readability quite a bit:
* Add spacing header<->snippet, but use the |> on the side for visual consistency
* Fix#33819
* Fix#33763
* Move format-sensitive test (issue-26480 in cfail) to ui test
r? @nikomatsakis
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
Refactor `FnCtxt::autoderef` to use an external iterator and to not
register any obligation from the main autoderef loop, but rather to
register them after (and if) the loop successfully completes.
Fixes#24819Fixes#25801Fixes#27631Fixes#31258Fixes#31964Fixes#32320Fixes#33515Fixes#33755
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
