Enable new pass manager with LLVM 13
The new pass manager is enabled by default in clang since Clang/LLVM 13. Per the recent discussion on llvm-dev (https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html) the legacy pass manager will be unmaintained in LLVM 14 and removed entirely in LLVM 15.
This switches us to use the new pass manager if LLVM >= 13 is used. It's possible to still use the old pass manager using `-Z new-llvm-pass-manager=no`.
Introduce `Rvalue::ShallowInitBox`
Polished version of #88700.
Implements MCP rust-lang/compiler-team#460, and should allow #43596 to go forward.
In short, creating an empty box is split from a nullary-op `NullOp::Box` into two steps, first a call to `exchange_malloc`, then a `Rvalue::ShallowInitBox` which transmutes `*mut u8` to a shallow-initialized `Box<T>`. This allows the `exchange_malloc` call to unwind. Details can be found in the MCP.
`NullOp::Box` is not yet removed, purely to make reverting easier in case anything goes wrong as the result of this PR. If revert is needed a reversion of "Use Rvalue::ShallowInitBox for box expression" commit followed by a test bless should be sufficient.
Experiments in #88700 showed a very slight compile-time perf regression due to (supposedly) slightly more time spent in LLVM. We could omit unwind edge generation (in non-`oom=panic` case) in box expression MIR construction to restore perf; but I don't think it's necessary since runtime perf isn't affected and perf difference is rather small.
Check whether a call/invoke of the function exists, but don't
match a leftover function declaration.
Also remove the CHECK-LABELs: In panic-in-drop=unwind mode the
call will not actually be in either of those functions, so
remove the restriction and look for any calls.
Rollup of 8 pull requests
Successful merges:
- #88893 (Add 1.56.0 release notes)
- #89001 (Be explicit about using Binder::dummy)
- #89072 (Avoid a couple of Symbol::as_str calls in cg_llvm )
- #89104 (Simplify scoped_thread)
- #89208 ([rfc 2229] Drop fully captured upvars in the same order as the regular drop code)
- #89210 (Add missing time complexities to linked_list.rs)
- #89217 (Enable "generate-link-to-definition" option on rust tools docs as well)
- #89221 (Give better error for `macro_rules! name!`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add basic checks for well-formedness of `fn`/`fn_mut` lang items
This pull request fixes#83471. Lang items are never actually checked for well-formedness (#9307). This means that one can get an ICE quite easily, e.g. as follows:
```rust
#![feature(lang_items)]
#[lang = "fn"]
trait MyFn {
const call: i32 = 42;
}
fn main() {
(|| 42)();
}
```
or this:
```rust
#![feature(lang_items)]
#[lang = "fn"]
trait MyFn {
fn call(i: i32, j: i32);
}
fn main() {
(|| 42)();
}
```
Ideally, there should probably be a more comprehensive strategy for checking lang items for well-formedness, but for the time being, I have added some rudimentary well-formedness checks that prevent #83471 and similar issues.
[rfc 2229] Drop fully captured upvars in the same order as the regular drop code
Currently, with the new 2021 edition, if a closure captures all of the
fields of an upvar, we'll drop those fields in the order they are used
within the closure instead of the normal drop order (the definition
order of the fields in the type).
This changes that so we sort the captured fields by the definition order
which causes them to drop in that same order as well.
Fixesrust-lang/project-rfc-2229#42
r? `@nikomatsakis`
Run `no_core` rustdoc tests only on Linux
I don't think this is really worth investigating further so I just disabled them.
They currently fail like this:
```
error: linking with `cc` failed: exit status: 1
|
= note: "cc" "-Wl,-exported_symbols_list,/var/folders/pg/gjhzdz7n361f0pv665d0723w0000gn/T/rustcPUsMpx/list" "-arch" "arm64" "/Users/hans/dev/rust/build/aarch64-apple-darwin/test/rustdoc/intra-doc/prim-methods-external-core/auxiliary/my-core.my_core.9f3c60de-cgu.0.rcgu.o" "/Users/hans/dev/rust/build/aarch64-apple-darwin/test/rustdoc/intra-doc/prim-methods-external-core/auxiliary/my-core.50fu2g9urkmisdsg.rcgu.o" "-L" "/Users/hans/dev/rust/build/aarch64-apple-darwin/native/rust-test-helpers" "-L" "/Users/hans/dev/rust/build/aarch64-apple-darwin/test/rustdoc/intra-doc/prim-methods-external-core/auxiliary" "-L" "/Users/hans/dev/rust/build/aarch64-apple-darwin/stage1/lib/rustlib/aarch64-apple-darwin/lib" "-L" "/Users/hans/dev/rust/build/aarch64-apple-darwin/stage1/lib/rustlib/aarch64-apple-darwin/lib" "-o" "/Users/hans/dev/rust/build/aarch64-apple-darwin/test/rustdoc/intra-doc/prim-methods-external-core/auxiliary/libmy_core.dylib" "-Wl,-dead_strip" "-dynamiclib" "-Wl,-dylib" "-Wl,-install_name" "-Wl,``@rpath/libmy_core.dylib"`` "-nodefaultlibs"
= note: ld: dynamic main executables must link with libSystem.dylib for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
r? ``@jyn514``
Revise never type fallback algorithm
This is a rebase of https://github.com/rust-lang/rust/pull/84573, but dropping the stabilization of never type (and the accompanying large test diff).
Each commit builds & has tests updated alongside it, and could be reviewed in a more or less standalone fashion. But it may make more sense to review the PR as a whole, I'm not sure. It should be noted that tests being updated isn't really a good indicator of final behavior -- never_type_fallback is not enabled by default in this PR, so we can't really see the full effects of the commits here.
This combines the work by Niko, which is [documented in this gist](https://gist.github.com/nikomatsakis/7a07b265dc12f5c3b3bd0422018fa660), with some additional rules largely derived to target specific known patterns that regress with the algorithm solely derived by Niko. We build these from an intuition that:
* In general, fallback to `()` is *sound* in all cases
* But, in general, we *prefer* fallback to `!` as it accepts more code, particularly that written to intentionally use `!` (e.g., Result's with a Infallible/! variant).
When evaluating Niko's proposed algorithm, we find that there are certain cases where fallback to `!` leads to compilation failures in real-world code, and fallback to `()` fixes those errors. In order to allow for stabilization, we need to fix a good portion of these patterns.
The final rule set this PR proposes is that, by default, we fallback from `?T` to `!`, with the following exceptions:
1. `?T: Foo` and `Bar::Baz = ?T` and `(): Foo`, then fallback to `()`
2. Per [Niko's algorithm](https://gist.github.com/nikomatsakis/7a07b265dc12f5c3b3bd0422018fa660#proposal-fallback-chooses-between--and--based-on-the-coercion-graph), the "live" `?T` also fallback to `()`.
The first rule is necessary to address a fairly common pattern which boils down to something like the snippet below. Without rule 1, we do not see the closure's return type as needing a () fallback, which leads to compilation failure.
```rust
#![feature(never_type_fallback)]
trait Bar { }
impl Bar for () { }
impl Bar for u32 { }
fn foo<R: Bar>(_: impl Fn() -> R) {}
fn main() {
foo(|| panic!());
}
```
r? `@jackh726`
Currently, with the new 2021 edition, if a closure captures all of the
fields of an upvar, we'll drop those fields in the order they are used
within the closure instead of the normal drop order (the definition
order of the fields in the type).
This changes that so we sort the captured fields by the definition order
which causes them to drop in that same order as well.
Fixes https://github.com/rust-lang/project-rfc-2229/issues/42
Lazy TAIT preparation cleanups
Check that TAIT generics are fully generic in mir typeck instead of wf-check, as wf-check can by definition only check TAIT in return position and not account for TAITs defined in the body of the function
r? `@spastorino` `@nikomatsakis`
Support `#[track_caller]` on closures and generators
## Lang team summary
This PR adds support for placing the `#[track_caller]` attribute on closure and generator expressions. This attribute's addition behaves identically (from a users perspective) to the attribute being placed on the method in impl Fn/FnOnce/FnMut for ... generated by compiler.
The attribute is currently "double" feature gated -- both `stmt_expr_attributes` (preexisting) and `closure_track_caller` (newly added) must be enabled in order to place these attributes on closures.
As the Fn* traits lack a `#[track_caller]` attribute in their definition, caller information does not propagate when invoking closures through dyn Fn*. There is no limitation that this PR adds in supporting this; it can be added in the future.
# Implementation details
This is implemented in the same way as for functions - an extra
location argument is appended to the end of the ABI. For closures,
this argument is *not* part of the 'tupled' argument storing the
parameters - the final closure argument for `#[track_caller]` closures
is no longer a tuple.
For direct (monomorphized) calls, the necessary support was already
implemented - we just needeed to adjust some assertions around checking
the ABI and argument count to take closures into account.
For calls through a trait object, more work was needed.
When creating a `ReifyShim`, we need to create a shim
for the trait method (e.g. `FnOnce::call_mut`) - unlike normal
functions, closures are never invoked directly, and always go through a
trait method.
Additional handling was needed for `InstanceDef::ClosureOnceShim`. In
order to pass location information throgh a direct (monomorphized) call
to `FnOnce::call_once` on an `FnMut` closure, we need to make
`ClosureOnceShim` aware of `#[tracked_caller]`. A new field
`track_caller` is added to `ClosureOnceShim` - this is used by
`InstanceDef::requires_caller` location, allowing codegen to
pass through the extra location argument.
Since `ClosureOnceShim.track_caller` is only used by codegen,
we end up generating two identical MIR shims - one for
`track_caller == true`, and one for `track_caller == false`. However,
these two shims are used by the entire crate (i.e. it's two shims total,
not two shims per unique closure), so this shouldn't a big deal.
This PR allows applying a `#[track_caller]` attribute to a
closure/generator expression. The attribute as interpreted as applying
to the compiler-generated implementation of the corresponding trait
method (`FnOnce::call_once`, `FnMut::call_mut`, `Fn::call`, or
`Generator::resume`).
This feature does not have its own feature gate - however, it requires
`#![feature(stmt_expr_attributes)]` in order to actually apply
an attribute to a closure or generator.
This is implemented in the same way as for functions - an extra
location argument is appended to the end of the ABI. For closures,
this argument is *not* part of the 'tupled' argument storing the
parameters - the final closure argument for `#[track_caller]` closures
is no longer a tuple.
For direct (monomorphized) calls, the necessary support was already
implemented - we just needeed to adjust some assertions around checking
the ABI and argument count to take closures into account.
For calls through a trait object, more work was needed.
When creating a `ReifyShim`, we need to create a shim
for the trait method (e.g. `FnOnce::call_mut`) - unlike normal
functions, closures are never invoked directly, and always go through a
trait method.
Additional handling was needed for `InstanceDef::ClosureOnceShim`. In
order to pass location information throgh a direct (monomorphized) call
to `FnOnce::call_once` on an `FnMut` closure, we need to make
`ClosureOnceShim` aware of `#[tracked_caller]`. A new field
`track_caller` is added to `ClosureOnceShim` - this is used by
`InstanceDef::requires_caller` location, allowing codegen to
pass through the extra location argument.
Since `ClosureOnceShim.track_caller` is only used by codegen,
we end up generating two identical MIR shims - one for
`track_caller == true`, and one for `track_caller == false`. However,
these two shims are used by the entire crate (i.e. it's two shims total,
not two shims per unique closure), so this shouldn't a big deal.
Re-enable the `src/test/debuginfo/mutex.rs` test on Windows
This test required a newer version of cdb than was previously enabled in
CI thus leading to some bitrot in the test since the time it was
originally created. With the update to the `windows-latest` image last
week, we're now running this test in CI and thus uncovered the
regression.
I've updated the test and it now passes.
r? `@ehuss`
"Fix" an overflow in byte position math
r? `@estebank`
help! I fixed the ICE only to brick the diagnostic.
I mean, it was wrong previously (using an already expanded macro span), but it is really bad now XD
Implement `#[must_not_suspend]`
implements #83310
Some notes on the impl:
1. The code that searches for the attribute on the ADT is basically copied from the `must_use` lint. It's not shared, as the logic did diverge
2. The RFC does specify that the attribute can be placed on fn's (and fn-like objects), like `must_use`. I think this is a direct copy from the `must_use` reference definition. This implementation does NOT support this, as I felt that ADT's (+ `impl Trait` + `dyn Trait`) cover the usecase's people actually want on the RFC, and adding an imp for the fn call case would be significantly harder. The `must_use` impl can do a single check at fn call stmt time, but `must_not_suspend` would need to answer the question: "for some value X with type T, find any fn call that COULD have produced this value". That would require significant changes to `generator_interior.rs`, and I would need mentorship on that. `@eholk` and I are discussing it.
3. `@estebank` do you know a way I can make the user-provided `reason` note pop out? right now it seems quite hidden
Also, I am not sure if we should run perf on this
r? `@nikomatsakis`
In suggest_missing_return_type, erase late bound regions after normalizing
Fixes#88360
There might be some hardening that could be done to not error or avoid erroring with LUBing `ReErased` with `ReEmpty`, but this was the most simple fix for this particular case.
r? `@nikomatsakis`
Fix debuginfo for parameters passed via the ScalarPair abi on Windows
Mark all of these as locals so the debugger does not try to interpret
them as being a pointer to the value. This extends the approach used
in #81898.
Fixes#88625
Fix ICE when `indirect_structural_match` is allowed
Fixes#89088. The ICE is caused by `delay_good_path_bug()`, which is called (indirectly) from a `format!()` macro invocation. I have moved the macro invocation into the `decorate` closure of `struct_span_lint_hir()`, so that the macro is only invoked if the lint is not allowed (i.e., causes at least a warning, and thus prevents `delay_good_path_bug()` from firing).
rustc_codegen_llvm: make sse4.2 imply crc32 for LLVM 14
This fixes compiling things like the `snap` crate after
https://reviews.llvm.org/D105462. I added a test that verifies the
additional attribute gets specified, and confirmed that I can build
cargo with both LLVM 13 and 14 with this change applied.
r? `@nagisa` cc `@nikic`
This allows the format_args! macro to keep the pre-expansion code out of
the unsafe block without doing gymnastics with nested `match`
expressions. This reduces codegen.
