Don't special-case llvm.* as nounwind
Certain LLVM intrinsics, such as `llvm.wasm.throw`, can unwind. Marking them as nounwind causes us to skip cleanup of locals and optimize out `catch_unwind` under inlining or when `llvm.wasm.throw` is used directly by user code.
The motivation for forcibly marking llvm.* as nounwind is no longer present: most intrinsics are linked as `extern "C"` or other non-unwinding ABIs, so we won't codegen `invoke` for them anyway.
Closesrust-lang/rust#132416.
`@rustbot` label +T-compiler +A-panic
Avoid unnecessary `new_adt`/`new_fn_def` calls.
They can be skipped if there are no arguments, avoiding the "relate" operation work and also the subsequent interning.
r? `@ghost`
Unify LLVM ctlz/cttz intrinsic generation
The type signature for `llvm.ctlz` is the same as the one for `llvm.cttz`, which enables a small simplification.
No longer need `alloca`s for consuming `Result<!, i32>` and similar
In optimized builds GVN gets rid of these already, but in `opt-level=0` we actually make `alloca`s for this, which particularly impacts `?`-style things that use actually-only-one-variant types like this.
While doing so, rewrite `LocalAnalyzer::process_place` to be non-recursive, solving a 6+ year old FIXME.
r? codegen
Enable outline-atomics for aarch64-unknown-linux-musl
They were disabled in bd287fa508 and haven't been causing problems for a while anymore, see https://github.com/rust-lang/rust/issues/89626 for details.
The entire testsuite still passes on `aarch64-unknown-linux-musl` with this feature enabled.
Stop compilation early if macro expansion failed
Fixesrust-lang/rust#116180.
So there isn't really a type that is central for macro expansion and some errors are actually emitted (because the resolution happens after the expansion I suppose) after the expansion pass (like "not found macro"). Sometimes, errors are only emitted on the second "try" (to improve error output). So I couldn't reach a similar solution than what was done in https://github.com/rust-lang/rust/pull/133937 and suggested by ````@estebank```` in https://github.com/rust-lang/rust/issues/116180#issuecomment-3109468922. But maybe I missed something?
So in the end, I realized that there is method called every time (except one, described below) a macro error is actually emitted: `ExtCtxt::trace_macros_diag`. Considering I updated what it did, I renamed it into `macro_error_and_trace_macros_diag` to better reflect it.
There is only one call of `trace_macros_diag` which isn't reporting an error but just used for `macro_trace` feature, so I kept it as is.
r? ````@oli-obk````
Let `codegen_transmute_operand` just handle everything
When combined with rust-lang/rust#143720, this means `rvalue_creates_operand` can just return `true` for *every* `Rvalue`. (A future PR could consider removing it, though just letting it optimize out is fine for now.)
It's nicer anyway, IMHO, because it avoids needing the layout checks to be consistent in the two places, and thus is an overall reduction in code. Plus it's a more helpful building block when used in other places this way.
(TBH, it probably would have been better to have it this way the whole time, but I clearly didn't understand `rvalue_creates_operand` when I originally wrote rust-lang/rust#109843.)
Skip walking into param-env component if it has no placeholder/re-var
Although it only provides a minor perf improvement, it seems like it could matter in more pathological cases.
resolve: Do not create `NameResolutions` on access unless necessary
`fn resolution` now just performs the access, and `fn resolution_or_default` will insert a default entry if the entry is missing.
Allow pretty printing paths with `-Zself-profile-events=args`
`-Zself-profile-events=args` is pretty heavy and can pretty print a lot of stuff. Rather than hunting down specific cases where this happens, I'd just allow calling `trimmed_def_paths` in this mode.
Fixes: https://github.com/rust-lang/rust/issues/144457
r? `@RalfJung`
Call `is_parsed_attribute` rather than keeping track of a list of parsed attributes manually
r? ```@oli-obk```
Nicer code & will prevent issues like https://github.com/rust-lang/rust/pull/144358 in the future
Suggest unwrapping when private method name is available in inner type
Given
```rust
fn main() {
let maybe_vec = Some(vec![1,2,3]);
assert_eq!(maybe_vec.len(), 3);
}
```
suggest unwraping `maybe_vec` to call `.len()` on the `Vec<_>`.
```
error[E0624]: method `len` is private
--> $DIR/enum-method-probe.rs:61:9
|
LL | res.len();
| ^^^ private method
--> $SRC_DIR/core/src/option.rs:LL:COL
|
= note: private method defined here
|
note: the method `len` exists on the type `Vec<{integer}>`
--> $SRC_DIR/alloc/src/vec/mod.rs:LL:COL
help: consider using `Option::expect` to unwrap the `Vec<{integer}>` value, panicking if the value is an `Option::None`
|
LL | res.expect("REASON").len();
| +++++++++++++++++
```
When a method isn't available, we emit E0599, but when it is private we emit E0624. We now just invoke the same suggestion logic from the later that we already did in the former.
Fixrust-lang/rust#143795.
Disable has_reliable_f128_math on musl targets
musl does not implement the symbols required by rustc for f128 maths. Disable the associated cfg for all musl targets and adjust the tests accordingly.
Closesrust-lang/rust#144423
Fix unused_parens false positive
Resolvesrust-lang/rust#143653.
The "no bounds exception" was indiscriminately set to `OneBound` for referents and pointees. However, if the reference or pointer type itself appears in no-bounds position, any constraints it has must be propagated.
```rust
// unused parens: not in no-bounds position
fn foo(_: Box<(dyn Send)>) {}
// unused parens: in no-bounds position, but one-bound exception applies
fn bar(_: Box<dyn Fn(&u32) -> &(dyn Send)>) {}
// *NOT* unused parens: in no-bounds position, but no exceptions to be made
fn baz(_: Box<dyn Fn(&u32) -> &(dyn Send) + Send>) {}
```
Mention type that could be `Clone` but isn't in more cases
When encountering a moved value of a type that isn't `Clone` because of unmet obligations, but where all the unmet predicates reference crate-local types, mention them and suggest cloning, as we do in other cases already:
```
error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure
--> f111.rs:14:25
|
13 | fn do_stuff(foo: Option<Foo>) {
| --- captured outer variable
14 | require_fn_trait(|| async {
| -- ^^^^^ `foo` is moved here
| |
| captured by this `Fn` closure
15 | if foo.map_or(false, |f| f.foo()) {
| ---
| |
| variable moved due to use in coroutine
| move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait
|
note: if `Foo` implemented `Clone`, you could clone the value
--> f111.rs:4:1
|
4 | struct Foo;
| ^^^^^^^^^^ consider implementing `Clone` for this type
...
15 | if foo.map_or(false, |f| f.foo()) {
| --- you could clone this value
```
CC rust-lang/rust#68119.
pattern_analysis: add option to get a full set of witnesses
This adds an option to the rustc_pattern_analysis machinery to have it report a complete set of patterns when a match is non-exhaustive (by default we only guarantee to report _some_ missing patterns). This is for use in rust-analyzer.
Leaving as draft until I'm sure this is what r-a needs.
r? ghost
musl does not implement the symbols required by std for f128 maths.
Disable the associated cfg for all musl targets and adjust the tests
accordingly.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
Do not run per-module late lints if they can be all skipped
We run ~70 late lints for all dependencies even if they use `--cap-lints=allow`, which seems wasteful. It looks like these lints are super fast (unlike early lints), but still.
r? `@ghost`
When encountering a moved value of a type that isn't `Clone` because of unmet obligations, but where all the unmet predicates reference crate-local types, mention them and suggest cloning, as we do in other cases already:
```
error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure
--> f111.rs:14:25
|
13 | fn do_stuff(foo: Option<Foo>) {
| --- captured outer variable
14 | require_fn_trait(|| async {
| -- ^^^^^ `foo` is moved here
| |
| captured by this `Fn` closure
15 | if foo.map_or(false, |f| f.foo()) {
| ---
| |
| variable moved due to use in coroutine
| move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait
|
note: if `Foo` implemented `Clone`, you could clone the value
--> f111.rs:4:1
|
4 | struct Foo;
| ^^^^^^^^^^ consider implementing `Clone` for this type
...
15 | if foo.map_or(false, |f| f.foo()) {
| --- you could clone this value
```
rustc_public: Remove movability from `RigidTy/AggregateKind::Coroutine`
Part of rust-lang/rust#119174 .
I think we should be good now to sync this change in rustc_public.
Remove dead code and extend test coverage and diagnostics around it
I was staring a bit at the `dont_niche_optimize_enum` variable and figured out that part of it is dead code (at least today it is). I changed the diagnostic and test around the code that makes that part dead code, so everything that makes removing that code sound is visible in this PR
resolve: Remove `Scope::CrateRoot`
Use `Scope::Module` with the crate root module inside instead, which should be identical.
This is a simplification by itself, but it will be even larger simplification if something like https://github.com/rust-lang/rust/pull/144131 is implemented, because `Scope::CrateRoot` is also a module with two actual scopes in it (for globs and non-globs).
I also did some renamings for consistency:
- `ScopeSet::AbsolutePath` -> `ScopeSet::ModuleAndExternPrelude`
- `ModuleOrUniformRoot::CrateRootAndExternPrelude` -> `ModuleOrUniformRoot::ModuleAndExternPrelude`
- `is_absolute_path` -> `module_and_extern_prelude`
Don't emit two `assume`s in transmutes when one is a subset of the other
For example, transmuting between `bool` and `Ordering` doesn't need two `assume`s because one range is a superset of the other.
Multiple are still used for things like `char` <-> `NonZero<u32>`, which overlap but where neither fully contains the other.
