Fix `unused_unsafe` around `await`
Enables `unused_unsafe` lint for `unsafe { future.await }`.
The existing test for this is `unsafe { println!() }`, so I assume that `println!` used to contain compiler-generated unsafe but this is no longer true, and so the existing test is broken. I replaced the test with `unsafe { ...await }`. I believe `await` is currently the only instance of compiler-generated unsafe.
Reverts some parts of #85421, but the issue predates that PR.
Add `future_prelude_collision` lint
Implements #84594. (RFC rust-lang/rfcs#3114 ([rendered](https://github.com/rust-lang/rfcs/blob/master/text/3114-prelude-2021.md))) Not entirely complete but wanted to have my progress decently available while I finish off the last little bits.
Things left to implement:
* [x] UI tests for lints
* [x] Only emit lint for 2015 and 2018 editions
* [ ] Lint name/message bikeshedding
* [x] Implement for `FromIterator` (from best I can tell, the current approach as mentioned from [this comment](https://github.com/rust-lang/rust/issues/84594#issuecomment-847288288) won't work due to `FromIterator` instances not using dot-call syntax, but if I'm correct about this then that would also need to be fixed for `TryFrom`/`TryInto`)*
* [x] Add to `rust-2021-migration` group? (See #85512) (added to `rust-2021-compatibility` group)
* [ ] Link to edition guide in lint docs
*edit: looked into it, `lookup_method` will also not be hit for `TryFrom`/`TryInto` for non-dotcall syntax. If anyone who is more familiar with typecheck knows the equivalent for looking up associated functions, feel free to chime in.
Rollup of 11 pull requests
Successful merges:
- #85054 (Revert SGX inline asm syntax)
- #85182 (Move `available_concurrency` implementation to `sys`)
- #86037 (Add `io::Cursor::{remaining, remaining_slice, is_empty}`)
- #86114 (Reopen#79692 (Format symbols under shared frames))
- #86297 (Allow to pass arguments to rustdoc-gui tool)
- #86334 (Resolve type aliases to the type they point to in intra-doc links)
- #86367 (Fix comment about rustc_inherit_overflow_checks in abs().)
- #86381 (Add regression test for issue #39161)
- #86387 (Remove `#[allow(unused_lifetimes)]` which is now unnecessary)
- #86398 (Add regression test for issue #54685)
- #86493 (Say "this enum variant takes"/"this struct takes" instead of "this function takes")
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Say "this enum variant takes"/"this struct takes" instead of "this function takes"
This makes error messages for functions with incorrect argument counts adapt if they refer to a struct or enum variant:
```
error[E0061]: this enum variant takes 1 argument but 0 arguments were supplied
--> $DIR/struct-enum-wrong-args.rs:7:13
|
LL | let _ = Ok();
| ^^-- supplied 0 arguments
| |
| expected 1 argument
error[E0061]: this struct takes 1 argument but 0 arguments were supplied
--> $DIR/struct-enum-wrong-args.rs:8:13
|
LL | let _ = Wrapper();
| ^^^^^^^-- supplied 0 arguments
| |
| expected 1 argument
```
Fixes#86481.
Add MIR pass to lower call to `core::slice::len` into `Len` operand
During some larger experiment with range analysis I've found that code like `let l = slice.len()` produces different MIR then one found in bound checks. This optimization pass replaces terminators that are calls to `core::slice::len` with just a MIR operand and Goto terminator.
It uses some heuristics to remove the outer borrow that is made to call `core::slice::len`, but I assume it can be eliminated, just didn't find how.
Would like to express my gratitude to `@oli-obk` who helped me a lot on Zullip
Emit warnings for unused fields in custom targets.
Add a warning which lists any fields in a custom target `json` file that aren't used. Currently unrecognized fields are ignored so, for example, a typo in the `json` will silently produce a target which isn't the one intended.
Do not emit alloca for ZST locals with multiple assignments
This extends 35566bfd7d to additionally stop emitting unnecessary allocas for zero sized locals that are assigned multiple times.
When rebuilding the standard library with `-Zbuild-std` this reduces the number of locals that require an allocation from 62315 to 61767.
Replace some `std::iter::repeat` with `str::repeat`
I noticed that there were some instances where `std::iter::repeat` would be used to repeat a string or a char to take a specific count of it and then collect it into a `String` when `str::repeat` is actually much faster and better for that.
See also: https://github.com/rust-lang/rust-clippy/issues/7260.
Add pattern walking support to THIR walker
Suggested in https://github.com/rust-lang/rust/pull/85263#issuecomment-861906730, this splits off the support for pattern walking in THIR from #85263. This has no observable effect on THIR unsafety checking, since it is not currently possible to trigger unsafety from the THIR checker using the additional patterns or constants that are now walked. THIR patterns are walked in source code order.
r? `@LeSeulArtichaut`
Fix ICE with `#[repr(simd)]` on enum
This pull request fixes#83505. `#[repr(simd)]` may only be applied to structs, which correctly causes `E0517` for the example given in #83505, but the compiler attempts to recover from this error, which leads to an ICE later, when `.non_enum_variant()` is called on the `AdtDef`. I have added a check that prevents this from happening.
make UB during CTFE a hard error
This is a next step for https://github.com/rust-lang/rust/issues/71800. `const_err` has been a future-incompatibility lint for 4 months now since https://github.com/rust-lang/rust/pull/80394 (and err-by-default for many years before that), so I think we could try making it a proper hard error at least in some situations.
I didn't yet adjust the tests, since I first want to gauge the fall-out via crater.
Cc `@rust-lang/wg-const-eval`
Remove some last remants of {push,pop}_unsafe!
These macros have already been removed, but there was still some code handling these macros. That code is now removed.
Provide option for specifying the profiler runtime
Currently, if `-Zinstrument-coverage` is enabled, the target is linked
against the `library/profiler_builtins` crate (which pulls in LLVM's
compiler-rt runtime).
This option enables backends to specify an alternative runtime crate for
handling injected instrumentation calls.
Use `AttrVec` for `Arm`, `FieldDef`, and `Variant`
Uses `AttrVec` for `Arm`, `FieldDef`, and `Variant`, i.e., where the size of the vector can be empty often.
Skips `Crate` and `Item` because I think they may have the attributes on common cases and need more work outside of `rustc_ast` (e.g. rustc_expand needs a lot of tweaks). But if it's reasonable to change, I'm happy to do so.
Fixes#77662
Fix ICE when using `#[doc(keyword = "...")]` on non-items
This pull request fixes#83512. The code for checking attributes calls `expect_item()` when it shouldn't, thus causing an ICE. I have implemented a proper check for the node kind, so that an error is reported instead of the ICE.
Make `s` pre-interned
Now we should be able to pre-intern `s` as the test `ui/lint/rfc-2457-non-ascii-idents/lint-confusable-idents.rs` no longer fails.
Prefer `partition_point` to look up assoc items
Since we now have `partition_point` (instead of `equal_range`), I think it's worth trying to use it instead of manually finding it.
`partition_point` uses `binary_search_by` internally (#85406) and its performance has been improved (#74024), so I guess this will make a performance difference.
Use better error message for hard errors in CTFE
I noticed this while working on #86255: currently the same message is used for hard errors and soft errors in CTFE. This changes the error messages to make hard errors use a message that indicates the reality of the situation correctly, since usage of the constant is never allowed when there was a hard error evaluating it. This doesn't affect the behaviour of these error messages, only the content.
This changes the error logic to check if the error should be hard or soft where it is generated, instead of where it is emitted, to allow this distinction in error messages.
Replace parent substs of associated types with inference vars in borrow checker
Fixes https://github.com/rust-lang/rust/issues/83190
Fixes https://github.com/rust-lang/rust/issues/78450
When we normalize an associated type that refers to an opaque type, it can happen that the substs of the associated type do not occur in the projection (they are parent substs). We previously didn't replace those substs with inference vars, which left a concrete region after all regions should have already been replaced with inference vars and triggered a `delay_span_bug`. After we normalize the opaque type, we now try to replace any remaining concrete regions with inference vars.
Handle C-variadic arguments properly when reporting region errors
This pull request fixes#86053. The issue is that for a C-variadic function
```rust
#![feature(c_variadic)]
unsafe extern "C" fn foo(_: (), ...) {}
```
`foo`'s signature will contain only the first parameter (and have `c_variadic` set to `true`), whereas its body has a second argument (a `hir::Pat` for the `...`).
The code for reporting region errors iterates over the body's parameters and tries to fetch the corresponding parameter from the signature; this causes an out-of-bounds ICE for the `...` (though not in the example above, because there are no region errors to report).
I have simply restricted the iteration over the body parameters to exclude `...`, which is fine because `...` cannot cause a region error.
Stop returning a value from `report_assert_as_lint`
This function only ever returns `None`. Make that explicity by not returning a value at all.
`@rustbot` modify labels +C-cleanup +T-compiler
Fix span calculation in format strings
This pull request fixes#86085. The ICE described there is due to an error in the span calculation inside format strings, if the format string is the result of a macro invocation:
```rust
fn main() {
format!(concat!("abc}"));
}
```
currently produces:
```
error: invalid format string: unmatched `}` found
--> test.rs:2:17
|
2 | format!(concat!("abc}"));
| ^ unmatched `}` in format string
```
which is obviously incorrect. This happens because the span of the entire `concat!()` is combined with the _relative_ location of the unmatched `` `}` `` in the _result_ of the macro invocation (i.e. 4).
In #86085, this has led to a span that starts or ends in the middle of a multibyte character, but the root cause was the same. This pull request fixes the problem.
Box `thir::ExprKind::Adt` for performance
`Adt` is the biggest variant in the enum and probably isn't used very often compared to the other expr kinds, so boxing it should be beneficial for performance. We need a perf test to be sure.
Refactor vtable codegen
This refactor the codegen of vtables of miri interpreter, llvm, cranelift codegen backends.
This is preparation for the implementation of trait upcasting feature. cc #65991
Note that aside from code reorganization, there's an internal behavior change here that now InstanceDef::Virtual's index now include the three metadata slots, and now the first method is with index 3.
cc `@RalfJung` `@bjorn3`
Currently the same message is used for hard errors and soft errors. This
makes hard errors use a message that indicates the reality of the
situation correctly, since usage of the constant is never allowed when
there was a hard error evaluating it.
Improve CTFE UB validation error messages
As mentioned in https://github.com/rust-lang/rust/pull/86245#discussion_r650494012 this PR slightly improves the formatting of validation errors, to move the path to the error prefix.
From:
`type validation failed: encountered invalid vtable: size is bigger than largest supported object at .0`
To:
`type validation failed at .0: encountered invalid vtable: size is bigger than largest supported object`.
Fix force-warns to allow dashes.
The `--force-warns` flag was not allowing lint names with dashes, only supporting underscores. This changes it to allow dashes to match the behavior of the A/W/D/F flags.
Fix ICEs on invalid vtable size/alignment const UB errors
The invalid vtable size/alignment errors from `InterpCx::read_size_and_align_from_vtable` were "freeform const UB errors", causing ICEs when reaching validation. This PR turns them into const UB hard errors to catch them during validation and avoid that.
Fixes#86193
r? `@RalfJung`
(It seemed cleaner to have 2 variants but they can be merged into one variant with a message payload if you prefer that ?)
Do not suggest to add type annotations for unnameable types
Consider this example:
```rust
const A = || 42;
struct S<T> { t: T }
const B: _ = S { t: || 42 };
```
This currently produces the following output:
```
error: missing type for `const` item
--> src/lib.rs:1:7
|
1 | const A = || 42;
| ^ help: provide a type for the item: `A: [closure@src/lib.rs:1:11: 1:16]`
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> src/lib.rs:4:10
|
4 | const B: _ = S { t: || 42 };
| ^
| |
| not allowed in type signatures
| help: replace `_` with the correct type: `S<[closure@src/lib.rs:4:21: 4:26]>`
error: aborting due to 2 previous errors
```
However, these suggestions are obviously useless, because the suggested types cannot be written down. With my changes, the suggestion is replaced with a note, because there is no simple fix:
```
error: missing type for `const` item
--> test.rs:1:7
|
1 | const A = || 42;
| ^
|
note: however, the inferred type `[closure@test.rs:1:11: 1:16]` cannot be named
--> test.rs:1:11
|
1 | const A = || 42;
| ^^^^^
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> test.rs:4:10
|
4 | const B: _ = S { t: || 42 };
| ^ not allowed in type signatures
|
note: however, the inferred type `S<[closure@test.rs:4:21: 4:26]>` cannot be named
--> test.rs:4:14
|
4 | const B: _ = S { t: || 42 };
| ^^^^^^^^^^^^^^
error: aborting due to 2 previous errors
```
Hash DefId in rustc_span.
This is mostly just moving code around. Changes are simplifications of unneeded callbacks from rustc_span to rustc_middle.
r? `@petrochenkov`
Make `relate_type_and_mut` public
#85343 improved diagnostics around `Relate` impls but made `relate_type_and_mut` private, which was accessible as `relate` previously. This makes it public so that we can use it on rust-semverver.
r? ```@Aaron1011```
Detect incorrect vtable alignment during const eval
This PR fixes#86132 by detecting invalid alignment values for trait objects in the interpreter, and emitting an error about this conversion failure, to avoid the ICE.
I've noticed that the error emitted at a50d72158e/compiler/rustc_mir/src/interpret/traits.rs (L163-L166) doesn't seem to be present in the const-ub tests, so I've tried adding a test that triggers both of these cases: one for the invalid size, and another for the invalid alignment that #86132 tracks (I have found different magic values triggering different `Align::from_bytes` errors than the "power of 2" one, if need be).
However, when doing that, I *cannot* for the life of me figure out the correct incantation to make these 2 errors trigger with the "it is undefined behavior to use this value" message rather than the "any use of this value will cause an error" lint.
I've tried Oli's suggestions of different values, tuples and arrays, using the transparent wrapper trick from the other tests and I was only able to trigger the regular const-ub errors about the size of the vtable, or that the drop pointer was invalid. Maybe these "type validation failed" errors happen before this part of the interpreter is reached and there just needs some magic incorrect values to bypass them, I don't know.
Since this fixes an ICE, and if the constants are indeed used, these 2 tests will turn into a hard error, I thought I'd open the PR anyways. And if ```@RalfJung``` you know of a way I could manage that (if you think that these tests are worth checking that the `throw_ub_format!` does indeed create const-ub errors as we expect) I'd be grateful.
For that reason, r? ```@RalfJung``` and cc ```@oli-obk.```
Do not suggest ampmut if rhs is already mutable
Removes invalid suggestion in #85765, although it should highlight the user type instead of the local variable.
Looking at the comments of this line:
84b1005bfd/compiler/rustc_mir_build/src/build/matches/mod.rs (L2107)
It was intentionally set to `None`, causing it to highlight the local variable instead. I am not sure if I will be able to fix it.
Fixes#85765
Fix some diagnostic issues with const_generics_defaults feature gate
This PR makes a few changes:
- print out const param defaults in "lifetime ordering" errors rather than discarding them
- update `is_simple_text` to account for const params when checking if a type has no generics, this was causing a note to be failed to add to an error message
- fixes some diagnostic wording that incorrectly said there was ordering restrictions between type/const params despite the `const_generics_defaults` feature gate is active
Don't use a generator for BoxedResolver
The generator is non-trivial and requires unsafe code anyway. Using regular unsafe code without a generator is much easier to follow.
Based on #85810 as it touches rustc_interface too.
