Lint pinned `#[must_use]` pointers (in particular, `Box<T>` where `T` is `#[must_use]`) in `unused_must_use`.
Fixes: #111458
This is motivated by a common async/await pattern:
```rs
fn foo() -> Pin<Box<dyn Future<Output = i32>>> {
Box::pin(async { 42 })
}
// call `foo`, but forget to await the result
foo();
```
Unlike with `async fn` or return position `impl Future`, this does not currently warn the user that the `Future` is unused.
To fix this, I've extended the `unused_must_use` lint to catch `Pin<P>`, where `P` must be used. In particular, this applies to `Pin<Box<T>>`, where `T` must be used. I'm not sure if there are other pointers where this applies, but I can't think of any situation the user wouldn't want to be warned.
Suggest field typo through derefs
Take into account implicit dereferences when suggesting fields.
```
error[E0609]: no field `longname` on type `Arc<S>`
--> $DIR/suggest-field-through-deref.rs:10:15
|
LL | let _ = x.longname;
| ^^^^^^^^ help: a field with a similar name exists: `long_name`
```
CC https://github.com/rust-lang/rust/issues/78374#issuecomment-719564114
Remove option_payload_ptr; redundant to offset_of
The `option_payload_ptr` intrinsic is no longer required as `offset_of` supports traversing enums (#114208). This PR removes it in order to dogfood offset_of (as suggested at https://github.com/rust-lang/rust/issues/106655#issuecomment-1790907626). However, it will not build until those changes reach beta (which I think is within the next 8 days?) so I've opened it as a draft.
When a local binding shadows a fn, point at fn def in call failure
When a local binding shadows a function that is then called, this local binding will cause an E0618 error. We now point not only at the binding definition, but also at the locally defined function of the same name.
```
error[E0618]: expected function, found `&str`
--> $DIR/issue-22468.rs:3:13
|
LL | let foo = "bar";
| --- `foo` has type `&str`
LL | let x = foo("baz");
| ^^^-------
| |
| call expression requires function
...
LL | fn foo(file: &str) -> bool {
| -------------------------- this function of the same name is available here, but it shadowed by the local binding of the same name
```
Fix#53841
Reenable effects in libcore
With #116670, #117531, and #117171, I think we would be comfortable with re-enabling the effects feature for more testing in libcore.
r? `@oli-obk`
cc `@fmease`
cc #110395
Add some additional warnings for duplicated diagnostic items
This commit adds warnings if a user supplies several diagnostic options where we can only apply one of them. We explicitly warn about ignored options here. In addition a small test for these warnings is added.
r? `@compiler-errors`
For now that's the last PR to improve the warnings generated by misused `#[diagnostic::on_unimplemented]` attributes. I'm not sure what needs to be done next to move this closer to stabilization.
When a local binding shadows a function that is then called, this local
binding will cause an E0618 error. We now point not only at the binding
definition, but also at the locally defined function of the same name.
```
error[E0618]: expected function, found `&str`
--> $DIR/issue-22468.rs:3:13
|
LL | let foo = "bar";
| --- `foo` has type `&str`
LL | let x = foo("baz");
| ^^^-------
| |
| call expression requires function
...
LL | fn foo(file: &str) -> bool {
| -------------------------- this function of the same name is avalable here, but it shadowed by the local binding of the same name
```
Fix#53841
When using existing fn as module, don't claim it doesn't exist
Tweak wording of module not found in resolve, when the name exists but belongs to a non-`mod` item.
Fix#81232.
Remove asmjs
Fulfills [MCP 668](https://github.com/rust-lang/compiler-team/issues/668).
`asmjs-unknown-emscripten` does not work as-specified, and lacks essential upstream support for generating asm.js, so it should not exist at all.
More detail when expecting expression but encountering bad macro argument
On nested macro invocations where the same macro fragment changes fragment type from one to the next, point at the chain of invocations and at the macro fragment definition place, explaining that the change has occurred.
Fix#71039.
```
error: expected expression, found pattern `1 + 1`
--> $DIR/trace_faulty_macros.rs:49:37
|
LL | (let $p:pat = $e:expr) => {test!(($p,$e))};
| ------- -- this is interpreted as expression, but it is expected to be pattern
| |
| this macro fragment matcher is expression
...
LL | (($p:pat, $e:pat)) => {let $p = $e;};
| ------ ^^ expected expression
| |
| this macro fragment matcher is pattern
...
LL | test!(let x = 1+1);
| ------------------
| | |
| | this is expected to be expression
| in this macro invocation
|
= note: when forwarding a matched fragment to another macro-by-example, matchers in the second macro will see an opaque AST of the fragment type, not the underlying tokens
= note: this error originates in the macro `test` (in Nightly builds, run with -Z macro-backtrace for more info)
```
ignore implied bounds with placeholders
given the following code:
```rust
trait Trait {
type Ty<'a> where Self: 'a;
}
impl<T> Trait for T {
type Ty<'a> = () where Self: 'a;
}
struct Foo<T: Trait>(T)
where
for<'x> T::Ty<'x>: Sized;
```
when computing the implied bounds from `Foo<X>` we incorrectly get the bound `X: !x` from the normalization of ` for<'x> <X as Trait>::Ty::<'x>: Sized`. This is a a known bug! we shouldn't use the constraints that arise from normalization as implied bounds. See #109628.
Ignore these bounds for now. This should prevent later ICEs.
Fixes#112250Fixes#107409
new solver normalization improvements
cool beans
At the core of this PR is a `try_normalize_ty` which stops for rigid aliases by using `commit_if_ok`.
Reworks alias-relate to fully normalize both the lhs and rhs and then equate the resulting rigid (or inference) types. This fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/68 by avoiding the exponential blowup. Also supersedes #116369 by only defining opaque types if the hidden type is rigid.
I removed the stability check in `EvalCtxt::evaluate_goal` due to https://github.com/rust-lang/trait-system-refactor-initiative/issues/75. While I personally have opinions on how to fix it, that still requires further t-types/`@nikomatsakis` buy-in, so I removed that for now. Once we've decided on our approach there, we can revert this commit.
r? `@compiler-errors`
On resolve error of `[rest..]`, suggest `[rest @ ..]`
When writing a pattern to collect multiple entries of a slice in a single binding, it is easy to misremember or typo the appropriate syntax to do so, instead writing the experimental `X..` pattern syntax. When we encounter a resolve error because `X` isn't available, we suggest `X @ ..` as an alternative.
```
error[E0425]: cannot find value `rest` in this scope
--> $DIR/range-pattern-meant-to-be-slice-rest-pattern.rs:3:13
|
LL | [1, rest..] => println!("{rest:?}"),
| ^^^^ not found in this scope
|
help: if you meant to collect the rest of the slice in `rest`, use the at operator
|
LL | [1, rest @ ..] => println!("{rest:?}"),
| +
```
Fix#88404.
Misc changes to StableMIR required to Kani use case.
First, I wanted to say that I can split this review into multiple if it makes reviewing easier. I bundled them up, since I've been testing them together (See https://github.com/rust-lang/project-stable-mir/pull/51 for the set of more thorough checks).
So far, this review includes 3 commits:
1. Add more APIs and fix `Instance::body`
- Add more APIs to retrieve information about types.
- Add a few more instance resolution options. For the drop shim, we return None if the drop body is empty. Not sure it will be enough.
- Make `Instance::body()` return an Option<Body>, since not every instance might have an available body. For example, foreign instances, virtual instances, dependencies.
2. Fix a bug on MIRVisitor
- We were not iterating over all local variables due to a typo.
3. Add more SMIR internal impl and callback return value
- In cases like Kani, we will invoke the rustc_internal run command directly for now. It would be handly to be able to have a callback that can return a value.
- We also need extra methods to convert stable constructs into internal ones, so we can break down the transition into finer grain commits.
- For the internal implementation of Region, we're always returning `ReErased` for now.
document ABI compatibility
I don't think we have any central place where we document our ABI compatibility rules, so let's create one. The `fn()` pointer type seems like a good place since ABI questions can only become relevant when invoking a function through a function pointer.
This will likely need T-lang FCP.
This commit adds warnings if a user supplies several diagnostic options
where we can only apply one of them. We explicitly warn about ignored
options here. In addition a small test for these warnings is added.
When writing a pattern to collect multiple entries of a slice in a
single binding, it is easy to misremember or typo the appropriate syntax
to do so, instead writing the experimental `X..` pattern syntax. When we
encounter a resolve error because `X` isn't available, we suggest
`X @ ..` as an alternative.
```
error[E0425]: cannot find value `rest` in this scope
--> $DIR/range-pattern-meant-to-be-slice-rest-pattern.rs:3:13
|
LL | [1, rest..] => println!("{rest:?}"),
| ^^^^ not found in this scope
|
help: if you meant to collect the rest of the slice in `rest`, use the at operator
|
LL | [1, rest @ ..] => println!("{rest:?}"),
| +
```
Fix#88404.
Better handle type errors involving `Self` literals
When encountering a type error involving a `Self` literal, point at the self type of the enclosing `impl` and suggest using the actual type name instead.
```
error[E0308]: mismatched types
--> $DIR/struct-path-self-type-mismatch.rs:13:9
|
LL | impl<T> Foo<T> {
| - ------ this is the type of the `Self` literal
| |
| found type parameter
LL | fn new<U>(u: U) -> Foo<U> {
| - ------ expected `Foo<U>` because of return type
| |
| expected type parameter
LL | / Self {
LL | |
LL | | inner: u
LL | |
LL | | }
| |_________^ expected `Foo<U>`, found `Foo<T>`
|
= note: expected struct `Foo<U>`
found struct `Foo<T>`
= note: a type parameter was expected, but a different one was found; you might be missing a type parameter or trait bound
= note: for more information, visit https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters
help: use the type name directly
|
LL | Foo::<U> {
| ~~~~~~~~
```
Fix#76086.
Add more APIs to retrieve information about types, and add more instance
resolution options.
Make `Instance::body()` return an Option<Body>, since not every instance
might have an available body. For example, foreign instances, virtual
instances, dependencies.
Take into account implicit dereferences when suggesting fields.
```
error[E0609]: no field `longname` on type `Arc<S>`
--> $DIR/suggest-field-through-deref.rs:10:15
|
LL | let _ = x.longname;
| ^^^^^^^^ help: a field with a similar name exists: `long_name`
```
CC https://github.com/rust-lang/rust/issues/78374#issuecomment-719564114
When encountering a type error caused by the use of `Self`, suggest
using the actual type name instead.
```
error[E0308]: mismatched types
--> $DIR/struct-path-self-type-mismatch.rs:13:9
|
LL | impl<T> Foo<T> {
| - ------ this is the type of the `Self` literal
| |
| found type parameter
LL | fn new<U>(u: U) -> Foo<U> {
| - ------ expected `Foo<U>` because of return type
| |
| expected type parameter
LL | / Self {
LL | |
LL | | inner: u
LL | |
LL | | }
| |_________^ expected `Foo<U>`, found `Foo<T>`
|
= note: expected struct `Foo<U>`
found struct `Foo<T>`
= note: a type parameter was expected, but a different one was found; you might be missing a type parameter or trait bound
= note: for more information, visit https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters
help: use the type name directly
|
LL | Foo::<U> {
| ~~~~~~~~
```
Fix#76086.
Fix depth check in ProofTreeVisitor.
The hack to cutoff overflows and cycles in the new trait solver was incorrect. We want to inspect everything with depth [0..10].
This fix exposed a previously unseen bug, which caused the compiler to ICE when invoking `trait_ref` on a non-assoc type projection. I simply added the guard in the `AmbiguityCausesVisitor`, and updated the expected output for the `auto-trait-coherence` test which now includes the extra note:
```text
|
= note: upstream crates may add a new impl of trait `std::marker::Send` for type `OpaqueType` in future versions
```
r? `@lcnr`
Add -Z llvm_module_flag
Allow adding values to the `!llvm.module.flags` metadata for a generated module. The syntax is
`-Z llvm_module_flag=<name>:<type>:<value>:<behavior>`
Currently only u32 values are supported but the type is required to be specified for forward compatibility. The `behavior` element must match one of the named LLVM metadata behaviors.viors.
This flag is expected to be perma-unstable.
finish `RegionKind` renaming
second step of https://github.com/rust-lang/types-team/issues/95
continues the work from #117876. While working on this and I encountered a bunch of further cleanup which I'll either open a tracking issue for or will do in a separate PR:
- rewrite the `RegionKind` docs, they still talk about `ReEmpty` and are generally out of date
- rename `DescriptionCtx` to `DescriptionCtxt`
- what is `CheckRegions::Bound`?
- `collect_late_bound_regions` et al
- `erase_late_bound_regions` -> `instantiate_bound_regions_with_erased`?
- `EraseEarlyRegions` visitor should be removed, feels duplicate
r? `@BoxyUwU`
Don't expect a rcvr in `print_disambiguation_help`
We don't necessarily have a receiver when we are both accidentally using the `.` operator *AND* we have more than one ambiguous method candidate.
Fixes#117728
Add richer structure for Stable MIR Projections
Resolves https://github.com/rust-lang/project-stable-mir/issues/49.
Projections in Stable MIR are currently just strings. This PR replaces that representation with a richer structure, namely projections become vectors of `ProjectionElem`s, just as in MIR. The `ProjectionElem` enum is heavily based off of the MIR `ProjectionElem`.
This PR is a draft since there are several outstanding issues to resolve, including:
- How should `UserTypeProjection`s be represented in Stable MIR? In MIR, the projections are just a vector of `ProjectionElem<(),()>`, meaning `ProjectionElem`s that don't have Local or Type arguments (for `Index`, `Field`, etc. objects). Should `UserTypeProjection`s be represented this way in Stable MIR as well? Or is there a more user-friendly representation that wouldn't drag along all the `ProjectionElem` variants that presumably can't appear?
- What is the expected behavior of a `Place`'s `ty` function? Should it resolve down the chain of projections so that something like `*_1.f` would return the type referenced by field `f`?
- Tests should be added for `UserTypeProjection`
Build pre-coroutine-transform coroutine body on error
I was accidentally building the post-transform coroutine body, rather than the pre-transform coroutine body. There's no pinning expected here yet, and the return type isn't yet transformed into `CoroutineState`.
Fixes#117670
Custom MIR: Support cleanup blocks
Cleanup blocks are declared with `bb (cleanup) = { ... }`.
`Call` and `Drop` terminators take an additional argument describing the unwind action, which is one of the following:
* `UnwindContinue()`
* `UnwindUnreachable()`
* `UnwindTerminate(reason)`, where reason is `ReasonAbi` or `ReasonInCleanup`
* `UnwindCleanup(block)`
Also support unwind resume and unwind terminate terminators:
* `UnwindResume()`
* `UnwindTerminate(reason)`
Cleanup blocks are declared with `bb (cleanup) = { ... }`.
`Call` and `Drop` terminators take an additional argument describing the
unwind action, which is one of the following:
* `UnwindContinue()`
* `UnwindUnreachable()`
* `UnwindTerminate(reason)`, where reason is `ReasonAbi` or `ReasonInCleanup`
* `UnwindCleanup(block)`
Also support unwind resume and unwind terminate terminators:
* `UnwindResume()`
* `UnwindTerminate(reason)`
Always point at index span on index obligation failure
Use more targetted span for index obligation failures by rewriting the obligation cause span.
CC #66023
tests: update check for inferred nneg on zext
This was broken by upstream
llvm/llvm-project@dc6d077396. It's easy enough to use a regex match to support both, so we do that.
r? `@nikic`
`@rustbot` label: +llvm-main
Compute layout with spans for better cycle errors in coroutines
Split out from #117703, this PR at least gives us a nicer span to point at when we hit a cycle error in coroutine layout cycles.
This was broken by upstream
llvm/llvm-project@dc6d077396. It's easy
enough to use a regex match to support both, so we do that.
r? @nikic
@rustbot label: +llvm-main
`ReLateBound` -> `ReBound`
first step of https://github.com/rust-lang/types-team/issues/95
already fairly large xx
there's some future work here I intentionally did not contribute as part of this PR, from my notes:
- `DescriptionCtx` to `DescriptionCtxt`
- what is `CheckRegions::Bound`?
- `collect_late_bound_regions` et al
- `erase_late_bound_regions` -> `instantiate_bound_regions_with_erased`?
- `EraseEarlyRegions` should be removed, feels duplicate
r? `@BoxyUwU`
coverage: Avoid creating malformed macro name spans
This is a workaround for #117788. It detects a particular scenario where we would create malformed coverage spans that might cause `llvm-cov` to immediately exit with an error, preventing the user from processing coverage reports.
The patch has been kept as simple as possible so that it's trivial to backport to beta (or stable) if desired.
---
The `maybe_push_macro_name_span` method is trying to detect macro invocations, so that it can split a span into two parts just after the `!` of the invocation.
Under some circumstances (probably involving nested macros), it gets confused and produces a span that is larger than the original span, and possibly extends outside its enclosing function and even into an adjacent file.
In extreme cases, that can result in malformed coverage mappings that cause `llvm-cov` to fail. For now, we at least want to detect these egregious cases and avoid them, so that coverage reports can still be produced.
Without the workaround applied, this test will produce malformed mappings that
cause `llvm-cov` to fail.
(And if it does emit well-formed mappings, they should be obviously incorrect.)
This is a aspect of Rust that frequently trips up people who are not
aware of it yet. This diagnostic attempts to explain what's happening
and why the lifetime constraint, that was never mentioned in the source,
arose.
Deny more `~const` trait bounds
thereby fixing a family of ICEs (delayed bugs) for `feature(const_trait_impl, effects)` code.
As discussed
r? `@fee1-dead`
Allow adding values to the `!llvm.module.flags` metadata for a generated
module. The syntax is
`-Z llvm_module_flag=<name>:<type>:<value>:<behavior>`
Currently only u32 values are supported but the type is required to be
specified for forward compatibility. The `behavior` element must match
one of the named LLVM metadata behaviors.viors.
This flag is expected to be perma-unstable.
Add `std:#️⃣:{DefaultHasher, RandomState}` exports (needs FCP)
This implements rust-lang/libs-team#267 to move the libstd hasher types to `std::hash` where they belong, instead of `std::collections::hash_map`.
<details><summary>The below no longer applies, but is kept for clarity.</summary>
This is a small refactor for #27242, which moves the definitions of `RandomState` and `DefaultHasher` into `std::hash`, but in a way that won't be noticed in the public API.
I've opened rust-lang/libs-team#267 as a formal ACP to move these directly into the root of `std::hash`, but for now, they're at least separated out from the collections code in a way that will make moving that around easier.
I decided to simply copy the rustdoc for `std::hash` from `core::hash` since I think it would be ideal for the two to diverge longer-term, especially if the ACP is accepted. However, I would be willing to factor them out into a common markdown document if that's preferred.
</details>
It's not clear to me (klinvill) that UserTypeProjections are produced
anymore with the removal of type ascriptions as per
https://github.com/rust-lang/rfcs/pull/3307. Furthermore, it's not clear
to me which variants of ProjectionElem could appear in such projections.
For these reasons, I'm reverting projections in UserTypeProjections to
simple strings until I can get more clarity on UserTypeProjections.
This commit includes richer projections for both Places and
UserTypeProjections. However, the tests only touch on Places. There are
also outstanding TODOs regarding how projections should be resolved to
produce Place types, and regarding if UserTypeProjections should just
contain ProjectionElem<(),()> objects as in MIR.
rustdoc-json: Fix test so it actually checks things
After #111427, no item has a `kind` field, so these assertions could never fail. Instead, assert that those two items arn't present.
r? `@GuillaumeGomez`
Emit #[inline] on derive(Debug)
While working on https://github.com/rust-lang/rust/pull/116583 I noticed that the `cross_crate_inlinable` query identifies a lot of derived `Debug` impls as a MIR body that's little more than a call, which suggests they may be a good candidate for `#[inline]`. So here I've implemented that change specifically.
It seems to provide a nice improvement to build times.
generator layout: ignore fake borrows
fixes#117059
We emit fake shallow borrows in case the scrutinee place uses a `Deref` and there is a match guard. This is necessary to prevent the match guard from mutating the scrutinee: fab1054e17/compiler/rustc_mir_build/src/build/matches/mod.rs (L1250-L1265)
These fake borrows end up impacting the generator witness computation in `mir_generator_witnesses`, which causes the issue in #117059. This PR now completely ignores fake borrows during this computation. This is sound as thse are always removed after analysis and the actual computation of the generator layout happens afterwards.
Only the second commit impacts behavior, and could be backported by itself.
r? types
Extend builtin/auto trait args with error when they have >1 argument
Reuse `extend_with_error` to add error args to any auto trait (or built-in trait like `Copy` that is defined incorrectly) that has additional non-`Self` args.
Fixes#117628
patterns: reject raw pointers that are not just integers
Matching against `0 as *const i32` is fine, matching against `&42 as *const i32` is not.
This extends the existing check against function pointers and wide pointers: we now uniformly reject all these pointer types during valtree construction, and then later lint because of that. See [here](https://github.com/rust-lang/rust/pull/116930#issuecomment-1784654073) for some more explanation and context.
Also fixes https://github.com/rust-lang/rust/issues/116929.
Cc `@oli-obk` `@lcnr`
Rollup of 5 pull requests
Successful merges:
- #117263 (handle the case when the change-id isn't found)
- #117282 (Recover from incorrectly ordered/duplicated function keywords)
- #117679 (tests/rustdoc-json: Avoid needless use of `no_core` and `lang_items`)
- #117702 (target: move base and target specifications)
- #117713 (Add test for reexported hidden item with `--document-hidden-items`)
r? `@ghost`
`@rustbot` modify labels: rollup
tests/rustdoc-json: Avoid needless use of `no_core` and `lang_items`
See #117487 for motivation.
I've split it into three commits, depending on how much work it was to remove `#![no_core]`. The first is entirely mechanical, the second makes no logical changes but couldn't be done with find+replace, and the third required rewriting assertions no not depend on having `#![no_core]`. All of the interesting changes for review are in the third commit, so I recommend reviewing commit-by-commit.
After this, 3 tests still use `#![no_core]`:
- `./tests/rustdoc-json/primitives/primitive_impls.rs`. Uses impls on primitives, so needs to simulate core
- `./tests/rustdoc-json/primitives/local_primitive.rs`: Uses `rustc_doc_primitive`, so needs to simulate core
- `./tests/rustdoc-json/impls/auto.rs`: Uses auto traits, so needs to simulate core
But after this change, we only rely on the core-rustc boundary in tests that deliberately test those interactions.
r? ``@GuillaumeGomez``
Fixes#117487
Compute polonius loan scopes over the region graph
In issue #117146 a loan flows into an SCC containing a placeholder, and whose representative is an existential region. Since we currently compute loan scopes by looking at SCCs and their representatives only, polonius would compute kill points for this loan here whereas NLLs would not of course.
There are a few ways to fix this:
- don't try to be efficient by doing the computation over SCCs, and simply look for free regions and placeholders in the successors of the issuing region.
- change how the SCC representatives are picked, biasing towards placeholders over existential regions. They *shouldn't* matter much, but some downstream code may subtly depend on the current scheme (though no tests fail if we do such a change). This is for unrelated reasons also the way #116891 changes the representative computation. So that PR would also fix issue #117146.
- try to remove placeholders from the main path, and contain them to a pre-pass + a post-pass kind of polonius leak check. If possible, it would fix this issue by turning an outlives constraints to a placeholder into a constraint to 'static. This should also fix the issue, as the representative would be the free region in the SCC. We want to prototype this change to see if it's possible to try to simplify the borrowck main path from having to deal with placeholders and higher-ranked subtyping 🤞.
I'd like to take advantage of fuzzing and a crater run sooner rather than later, so that we grow more confidence that the 2 models are indeed equivalent empirically. Therefore this PR implements option 1 to fix the issue now.
We can take care of efficiency later after validation, and once we implement option 3 (which could also impact option 2 and that associated PR, maybe the lack of placeholders could remove the need to change the representative computation) to traverse SCCs and their representative again.
(Or we maybe will have some kind of naive position-dependent outlives propagation by then and this code would have been changed)
Fixes#117146.
r? `@matthewjasper`
coverage: Rename the `run-coverage` test mode to `coverage-run`
Follow-up to https://github.com/rust-lang/rust/pull/117484#issuecomment-1788916563.
Renaming this test mode to `coverage-run` makes it more consistent with the `coverage-map` mode and the shared `tests/coverage` test directory.
---
``@rustbot`` label +A-code-coverage
Add -Zcross-crate-inline-threshold=yes
``@thomcc`` says this would be useful for
> seeing if it makes a difference in some code if i do it when building the sysroot, since -Zbuild-std + lto helps more than it seems like it should
And I've changed the possible values as a reference to ``@Manishearth`` saying
> LLVM's inlining heuristic is "yes".
Only use `normalize_param_env` when normalizing predicate in `check_item_bounds`
Only use the `normalize_param_env` when normalizing the item bound predicate in `check_item_bounds`, instead of using it when processing this obligation as well. This causes <BUG> to reoccur, but hopefully with better caching in the future, we can fix this would having such bad effects on perf.
This PR also fixes#117598. It turns out that the GAT predicate that we install is actually wrong -- given code like:
```
impl<'r> HasValueRef<'r> for Any {
type Database = Any;
}
```
We currently generate a predicate that looks like `<Any as HasValueRef<'r>>::Database = Any`, where `'r` is an early-bound variable. Really this GAT assumption should be universally quantified over the impl's args, i.e. `for<'r> <Any as HasValueRef<'r>>::Database = Any`, but then we'd need the binder to also include all the WC of the impl as well, which we don't support yet, lol.
To avoid `!matches!(...)`, which is hard to think about. Instead every
case now uses direct pattern matching and returns true or false.
Also add a couple of cases to the `stringify.rs` test that currently
print badly.
coverage: Unify `tests/coverage-map` and `tests/run-coverage` into `tests/coverage`
Ever since the introduction of the `coverage-map` suite, it's been awkward to have to manage two separate coverage test directories containing dozens of mostly-identical files.
However, those two suites were separate for good reasons. They have very different requirements (since only one of them requires actually running the test program), running only one suite is noticeably faster than running both, and having separate suites allows them to be blessed separately if desired. So while unifying them was an obvious idea, actually doing so was non-trivial.
---
Nevertheless, this PR finds a way to merge the two suites into one directory while retaining almost all of the developer-experience benefits of having two suites. This required non-trivial implementations of `Step`, but the end result works very smoothly.
---
The first 5 commits are a copy of #117340, which has been closed in favour of this PR.
Method suggestion code tweaks
I was rummaging around the method suggestion code after https://github.com/rust-lang/rust/pull/117006#discussion_r1384153722 and saw a few things to simplify.
This is two unrelated commits, both in the same file. Review them separately, if you'd like.
r? estebank
warn when using an unstable feature with -Ctarget-feature
Setting or unsetting the wrong target features can cause ABI incompatibility (https://github.com/rust-lang/rust/issues/116344, https://github.com/rust-lang/rust/issues/116558). We need to carefully audit features for their ABI impact before stabilization. I just learned that we currently accept arbitrary unstable features on stable and if they are in the list of Rust target features, even unstable, then we don't even warn about that!1 That doesn't seem great, so I propose we introduce a warning here.
This has an obvious loophole via `-Ctarget-cpu`. I'm not sure how to best deal with that, but it seems better to fix what we can and think about the other cases later, maybe once we have a better idea for how to resolve the general mess that are ABI-affecting target features.
Give a better diagnostic for missing parens in Fn* bounds
Fixes#108109
It would be nice to try and recover here, but I'm not sure it's worth the effort, especially as the bounds on the recovered function would be incorrect.
Thir unsafeck fixes
- Recognise thread local statics in THIR unsafeck
- Add suggestion for unsafe_op_in_unsafe_fn
- Fix unsafe checking of let expressions
Only instantiate binder during dyn's built-in trait candidate probe once
See UI test for demonstration of the issue.
This was "caused" by #117131, but only because we're using the `normalize_param_env` (which has been augmented with a projection clause used to normalize GATs) which features non-lifetime bound vars in it.
Fixes#117602 technically, though that's also fixed by #117542.
r? types
When not finding assoc fn on type, look for builder fn
When we have a resolution error when looking at a fully qualified path on a type, look for all associated functions on inherent impls that return `Self` and mention them to the user.
```
error[E0599]: no function or associated item named `new` found for struct `TcpStream` in the current scope
--> tests/ui/resolve/fn-new-doesnt-exist.rs:4:28
|
4 | let stream = TcpStream::new();
| ^^^ function or associated item not found in `TcpStream`
|
note: if you're trying to build a new `TcpStream` consider using one of the following associated functions:
TcpStream::connect
TcpStream::connect_timeout
--> /home/gh-estebank/rust/library/std/src/net/tcp.rs:156:5
|
156 | pub fn connect<A: ToSocketAddrs>(addr: A) -> io::Result<TcpStream> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
172 | pub fn connect_timeout(addr: &SocketAddr, timeout: Duration) -> io::Result<TcpStream> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Fix#69512.
When we have a resolution error when looking at a fully qualified path
on a type, look for all associated functions on inherent impls that
return `Self` and mention them to the user.
Fix#69512.
There is another test named `if.rs` in `tests/coverage-map/status-quo/`, so
this test stands in the way of flattening that directory into its parent.
Fortunately both tests are more-or-less equivalent, so removing this one is
fine.
This is a step towards being able to unify the two coverage test directories.
There are two tests that require adjustment:
- `overflow.rs` requires an explicit `-Coverflow-checks=yes`
- `sort_groups.rs` is sensitive to provably unused instantiations
Emit explanatory note for move errors in packed struct derives
Derive expansions for packed structs with non-`Copy` fields cause move errors because they prefer copying over borrowing since borrowing the fields of a packed struct can result in unaligned access.
This underlying cause of the errors, however, is not apparent to the user. This PR adds a diagnostic note to make it clear to the user (the new note is on the second last line):
```
tests/ui/derives/deriving-with-repr-packed-move-errors.rs:13:16
|
12 | #[derive(Debug, PartialEq, Eq, PartialOrd, Ord, Hash, Clone, Default)]
| ----- in this derive macro expansion
13 | struct StructA(String);
| ^^^^^^ move occurs because `self.0` has type `String`, which does not implement the `Copy` trait
|
= note: `#[derive(Debug)]` triggers a move because taking references to the fields of a packed struct is undefined behaviour
= note: this error originates in the derive macro `Debug` (in Nightly builds, run with -Z macro-backtrace for more info)
```
Fixes#117406
Partially addresses #110777
Rollup of 4 pull requests
Successful merges:
- #117190 (add test for #113381)
- #117516 (add test for #113375)
- #117631 (Documentation cleanup for core::error::Request.)
- #117637 (Check binders with bound vars for global bounds that don't hold)
r? `@ghost`
`@rustbot` modify labels: rollup
Detect misparsed binop caused by missing semi
When encountering
```rust
foo()
*bar = baz;
```
We currently emit potentially two errors, one for the return type of
`foo` not being multiplicative by the type of `bar`, and another for
`foo() * bar` not being assignable.
We now check for this case and suggest adding a semicolon in the right
place and emit only a single error.
Fix#80446.
Couple of small changes
These are unrelated to each other, but they are each small enough that opening separate PR's doesn't make sense to me either.
* Remove a place where the parse driver query is stolen.
* Update an outdated doc comment
* Use correct crate name in `-Zprint-vtable-sizes` when using `#![crate_name = "..."]`.
Add FileCheck annotations to a few MIR opt tests
const_debuginfo did not specify which passes were running.
const_prop_miscompile is renamed and moved to const_prop directory.
while_storage was broken.
Stabilize `const_maybe_uninit_zeroed` and `const_mem_zeroed`
Make `MaybeUninit::zeroed` and `mem::zeroed` const stable. Newly stable API:
```rust
// core::mem
pub const unsafe fn zeroed<T>() ->;
impl<T> MaybeUninit<T> {
pub const fn zeroed() -> MaybeUninit<T>;
}
```
This relies on features based around `const_mut_refs`. Per `@RalfJung,` this should be OK since we do not leak any `&mut` to the user.
For this to be possible, intrinsics `assert_zero_valid` and `assert_mem_uninitialized_valid` were made const stable.
Tracking issue: #91850
Zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/.60const_mut_refs.60.20dependents
r? libs-api
`@rustbot` label -T-libs +T-libs-api +A-const-eval
cc `@RalfJung` `@oli-obk` `@rust-lang/wg-const-eval`
Make sure that predicates with unmentioned bound vars are still considered global in the old solver
In the old solver, we consider predicates with late-bound vars to not be "global":
9c8a2694fa/compiler/rustc_trait_selection/src/traits/select/mod.rs (L1840-L1844)
The implementation of `has_late_bound_vars` was modified in #115834 so that we'd properly anonymize binders that had late-bound vars but didn't reference them. This fixed an ICE.
However, this also led to a behavioral change in https://github.com/rust-lang/rust/issues/117056#issuecomment-1775014545 for a couple of crates, which now consider `for<'a> GL33: Shader` (note the binder var that is *not* used in the predicate) to not be "global". This forces associated types to not be normalizable due to the old trait solver being dumb.
This PR distinguishes types which *reference* late-bound vars and binders which *have* late-bound vars. The latter is represented with the new type flag `TypeFlags::HAS_BINDER_VARS`, which is used when we only care about knowing whether binders have vars in their bound var list (even if they're not used, like for binder anonymization).
This should fix (after beta backport) the `luminance-gl` and `luminance-webgl` crates in #117056.
r? types
**(priority is kinda high on a review here given beta becomes stable on November 16.)**
Hint optimizer about try-reserved capacity
This is #116568, but limited only to the less-common `try_reserve` functions to reduce bloat in debug binaries from debug info, while still addressing the main use-case #116570
Rollup of 6 pull requests
Successful merges:
- #110340 (Deref docs: expand and remove "smart pointer" qualifier)
- #116894 (Guarantee that `char` has the same size and alignment as `u32`)
- #117534 (clarify that the str invariant is a safety, not validity, invariant)
- #117562 (triagebot no-merges: exclude different case)
- #117570 (fallback for `construct_generic_bound_failure`)
- #117583 (Remove `'tcx` lifetime on `PlaceholderConst`)
r? `@ghost`
`@rustbot` modify labels: rollup
fallback for `construct_generic_bound_failure`
Fixes#117547
This case regressed at #115882.
In this context, `generic_param_scope` is produced by `RPITVisitor` and not included by `hir_owner`. Therefore, I've added a fallback to address this.
Make `core::mem::zeroed` const stable. Newly stable API:
// core::mem
pub const unsafe fn zeroed<T>() -> T;
This is stabilized with `const_maybe_uninit_zeroed` since it is a simple
wrapper.
In order to make this possible, intrinsics `assert_zero_valid` was made
const stable under `const_assert_type2`.
`assert_mem_uninitialized_valid` was also made const stable since it is
under the same gate.
Update the alignment checks to match rust-lang/reference#1387
Previously, we had a special case to not check `Rvalue::AddressOf` in this pass because we weren't quite sure if pointers needed to be aligned in the Place passed to it: https://github.com/rust-lang/rust/pull/112026
Since https://github.com/rust-lang/reference/pull/1387 merged, this PR updates this pass to match. The behavior of the check is nearly unchanged, except we also avoid inserting a check for creating references. Most of the changes in this PR are cleanup and new tests.
Cleanup `rustc_mir_build/../check_match.rs`
The file had become pretty unwieldy, with a fair amount of duplication. As a bonus, I discovered that we weren't running some pattern checks in if-let chains.
I recommend looking commit-by-commit. The last commit is a whim, I think it makes more sense that way but I don't hold this opinion strongly.
They've been deprecated for four years.
This commit includes the following changes.
- It eliminates the `rustc_plugin_impl` crate.
- It changes the language used for lints in
`compiler/rustc_driver_impl/src/lib.rs` and
`compiler/rustc_lint/src/context.rs`. External lints are now called
"loaded" lints, rather than "plugins" to avoid confusion with the old
plugins. This only has a tiny effect on the output of `-W help`.
- E0457 and E0498 are no longer used.
- E0463 is narrowed, now only relating to unfound crates, not plugins.
- The `plugin` feature was moved from "active" to "removed".
- It removes the entire plugins chapter from the unstable book.
- It removes quite a few tests, mostly all of those in
`tests/ui-fulldeps/plugin/`.
Closes#29597.
Fix incorrect trait bound restriction suggestion
Suggest
```
error[E0308]: mismatched types
--> $DIR/restrict-assoc-type-of-generic-bound.rs:9:12
|
LL | pub fn foo<A: MyTrait, B>(a: A) -> B {
| - - expected `B` because of return type
| |
| expected this type parameter
LL | return a.bar();
| ^^^^^^^ expected type parameter `B`, found associated type
|
= note: expected type parameter `B`
found associated type `<A as MyTrait>::T`
help: consider further restricting this bound
|
LL | pub fn foo<A: MyTrait<T = B>, B>(a: A) -> B {
| +++++++
```
instead of
```
error[E0308]: mismatched types
--> $DIR/restrict-assoc-type-of-generic-bound.rs:9:12
|
LL | pub fn foo<A: MyTrait, B>(a: A) -> B {
| - - expected `B` because of return type
| |
| expected this type parameter
LL | return a.bar();
| ^^^^^^^ expected type parameter `B`, found associated type
|
= note: expected type parameter `B`
found associated type `<A as MyTrait>::T`
help: consider further restricting this bound
|
LL | pub fn foo<A: MyTrait + <T = B>, B>(a: A) -> B {
| +++++++++
```
Fix#117501.
Pretty print `Fn` traits in `rustc_on_unimplemented`
I don't think that users really ever should need to think about `Fn*` traits' tupled args for a simple trait error.
r? diagnostics
Derive expansions for packed structs cause move errors because
they prefer copying over borrowing since borrowing the fields of a
packed struct can result in unaligned access and therefore undefined
behaviour.
This underlying cause of the errors, however, is not apparent
to the user. We add a diagnostic note here to remedy that.
Add all RPITITs when augmenting param-env with GAT bounds in `check_type_bounds`
When checking that associated type definitions actually satisfy their associated type bounds in `check_type_bounds`, we construct a "`normalize_param_env`" which adds a projection predicate that allows us to assume that we can project the GAT to the definition we're checking. For example, in:
```rust
type Foo {
type Bar: Display = i32;
}
```
We would add `<Self as Foo>::Bar = i32` as a projection predicate when checking that `i32: Display` holds.
That `normalize_param_env` was, for some reason, only being used to normalize the predicate before it was registered. This is sketchy, because a nested obligation may require the GAT bound to hold, and also the projection cache is broken and doesn't differentiate projection cache keys that differ by param-envs 😿.
This `normalize_param_env` is also not sufficient when we have nested RPITITs and default trait methods, since we need to be able to assume we can normalize both the RPITIT and all of its child RPITITs to sufficiently prove all of its bounds. This is the cause of #117104, which only starts to fail for RPITITs that are nested 3 and above due to the projection-cache bug above.[^1]
## First fix
Use the `normalize_param_env` everywhere in `check_type_bounds`. This is reflected in a test I've constructed that fixes a GAT-only failure.
## Second fix
For RPITITs, install projection predicates for each RPITIT in the same function in `check_type_bounds`. This fixes#117104.
not sure who to request, so...
r? `@lcnr` hehe feel free to reassign :3
[^1]: The projection cache bug specifically occurs because we try normalizing the `assumed_wf_types` with the non-normalization param-env. This causes us to insert a projection cache entry that keeps the outermost RPITIT rigid, and it trivially satisifes all its own bounds. Super sketchy![^2]
[^2]: I haven't actually gone and fixed the projection cache bug because it's only marginally related, but I could, and it should no longer be triggered here.
Suggest
```
error[E0308]: mismatched types
--> $DIR/restrict-assoc-type-of-generic-bound.rs:9:12
|
LL | pub fn foo<A: MyTrait, B>(a: A) -> B {
| - - expected `B` because of return type
| |
| expected this type parameter
LL | return a.bar();
| ^^^^^^^ expected type parameter `B`, found associated type
|
= note: expected type parameter `B`
found associated type `<A as MyTrait>::T`
help: consider further restricting this bound
|
LL | pub fn foo<A: MyTrait<T = B>, B>(a: A) -> B {
| +++++++
```
instead of
```
error[E0308]: mismatched types
--> $DIR/restrict-assoc-type-of-generic-bound.rs:9:12
|
LL | pub fn foo<A: MyTrait, B>(a: A) -> B {
| - - expected `B` because of return type
| |
| expected this type parameter
LL | return a.bar();
| ^^^^^^^ expected type parameter `B`, found associated type
|
= note: expected type parameter `B`
found associated type `<A as MyTrait>::T`
help: consider further restricting this bound
|
LL | pub fn foo<A: MyTrait + <T = B>, B>(a: A) -> B {
| +++++++++
```
Fix#117501.
Fix order of implementations in the "implementations on foreign types" section
Fixes#117391.
We forgot to run the `sort_by_cached_key` on this section. This fixes it.
r? `@notriddle`
Remove support for alias `-Z symbol-mangling-version`
(This is very similar to the removal of `-Z instrument-coverage` in #117111.)
`-C symbol-mangling-version` was stabilized back in rustc 1.59.0 (2022-02-24) via #90128, with the old unstable flag kept around (with a warning) as an alias to ease migration.
Clarify `Unsize` documentation
The documentation erroneously says that:
```rust
/// - Types implementing a trait `Trait` also implement `Unsize<dyn Trait>`.
/// - Structs `Foo<..., T, ...>` implement `Unsize<Foo<..., U, ...>>` if all of these conditions
/// are met:
/// - `T: Unsize<U>`.
/// - Only the last field of `Foo` has a type involving `T`.
/// - `Bar<T>: Unsize<Bar<U>>`, where `Bar<T>` stands for the actual type of that last field.
```
Specifically, `T: Unsize<U>` is not required to hold -- only the final field must implement `FinalField<T>: Unsize<FinalField<U>>`. This can be demonstrated by the test I added.
---
Second commit fleshes out the documentation a lot more.
Don't check for alias bounds in liveness when aliases have escaping bound vars
I actually have no idea how we *should* be treating aliases with escaping bound vars here... but the simplest behavior is just doing what we used to do before.
r? aliemjay
Fixes#117455
Most notably, this commit changes the `pub use crate::*;` in that file
to `use crate::*;`. This requires a lot of `use` items in other crates
to be adjusted, because everything defined within `rustc_span::*` was
also available via `rustc_span::source_map::*`, which is bizarre.
The commit also removes `SourceMap::span_to_relative_line_string`, which
is unused.
Rollup of 4 pull requests
Successful merges:
- #117298 (Recover from missing param list in function definitions)
- #117373 (Avoid the path trimming ICE lint in error reporting)
- #117441 (Do not assert in op_to_const.)
- #117488 (Update minifier-rs version to 0.3.0)
r? `@ghost`
`@rustbot` modify labels: rollup
Do not assert in op_to_const.
`op_to_const` is used in `try_destructure_mir_constant_for_diagnostics`, which may encounter invalid constants created by optimizations and debugging.
r? ``@oli-obk``
Fixes https://github.com/rust-lang/rust/issues/117368
Add FileCheck annotations to MIR-opt inlining tests
Part of #116971, adds FileCheck annotations to MIR-opt tests in `tests/mir-opt/inline`.
I left out a few (such as `inline_cycle`) where it mentioned that the particular outcome of inlining isn't important, just that the inliner doesn't get stuck in an infinite loop.
r? cjgillot
Account for `ref` and `mut` in the wrong place for pattern ident renaming
If the user writes `S { ref field: name }` instead of `S { field: ref name }`, we suggest the correct code.
Fix#72298.
Support enum variants in offset_of!
This MR implements support for navigating through enum variants in `offset_of!`, placing the enum variant name in the second argument to `offset_of!`. The RFC placed it in the first argument, but I think it interacts better with nested field access in the second, as you can then write things like
```rust
offset_of!(Type, field.Variant.field)
```
Alternatively, a syntactic distinction could be made between variants and fields (e.g. `field::Variant.field`) but I'm not convinced this would be helpful.
[RFC 3308 # Enum Support](https://rust-lang.github.io/rfcs/3308-offset_of.html#enum-support-offset_ofsomeenumstructvariant-field_on_variant)
Tracking Issue #106655.
Clean up unchecked_math, separate out unchecked_shifts
Tracking issue: #85122
Changes:
1. Remove `const_inherent_unchecked_arith` flag and make const-stability flags the same as the method feature flags. Given the number of other unsafe const fns already stabilised, it makes sense to just stabilise these in const context when they're stabilised.
2. Move `unchecked_shl` and `unchecked_shr` into a separate `unchecked_shifts` flag, since the semantics for them are unclear and they'll likely be stabilised separately as a result.
3. Add an `unchecked_neg` method exclusively to signed integers, under the `unchecked_neg` flag. This is because it's a new API and probably needs some time to marinate before it's stabilised, and while it *would* make sense to have a similar version for unsigned integers since `checked_neg` also exists for those there is absolutely no case where that would be a good idea, IMQHO.
The longer-term goal here is to prepare the `unchecked_math` methods for an FCP and stabilisation since they've existed for a while, their semantics are clear, and people seem in favour of stabilising them.
Match usize/isize exhaustively with half-open ranges
The long-awaited finale to the saga of [exhaustiveness checking for integers](https://github.com/rust-lang/rust/pull/50912)!
```rust
match 0usize {
0.. => {} // exhaustive!
}
match 0usize {
0..usize::MAX => {} // helpful error message!
}
```
Features:
- Half-open ranges behave as expected for `usize`/`isize`;
- Trying to use `0..usize::MAX` will tell you that `usize::MAX..` is missing and explain why. No more unhelpful "`_` is missing";
- Everything else stays the same.
This should unblock https://github.com/rust-lang/rust/issues/37854.
Review-wise:
- I recommend looking commit-by-commit;
- This regresses perf because of the added complexity in `IntRange`; hopefully not too much;
- I measured each `#[inline]`, they all help a bit with the perf regression (tho I don't get why);
- I did not touch MIR building; I expect there's an easy PR there that would skip unnecessary comparisons when the range is half-open.
Replace switch to unreachable by assume statements
`UnreachablePropagation` currently keeps some switch terminators alive in order to ensure codegen can infer the inequalities on the discriminants.
This PR proposes to encode those inequalities as `Assume` statements.
This allows to simplify MIR further by removing some useless terminators.
Rollup of 5 pull requests
Successful merges:
- #113241 (rustdoc: Document lack of object safety on affected traits)
- #117388 (Turn const_caller_location from a query to a hook)
- #117417 (Add a stable MIR visitor)
- #117439 (prepopulate opaque ty storage before using it)
- #117451 (Add support for pre-unix-epoch file dates on Apple platforms (#108277))
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: Document lack of object safety on affected traits
Closes#85138
I saw the issue didn't have any recent activity, if there is another MR for it I missed it.
I want the issue to move forward so here is my proposition.
It takes some space just before the "Implementors" section and only if the trait is **not** object
safe since it is the only case where special care must be taken in some cases and this has the
benefit of avoiding generation of HTML in (I hope) the common case.
Accept less invalid Rust in rustdoc
pulled out of https://github.com/rust-lang/rust/pull/117213 where this change was already approved
This only affects rustdoc, and has up to [20% perf regressions in rustdoc](https://github.com/rust-lang/rust/pull/117213#issuecomment-1785776288). These are unavoidable, as we are simply doing more checks now, but it's part of the longer term plan of making rustdoc more resistant to ICEs by only accepting valid Rust code.
Rollup of 5 pull requests
Successful merges:
- #116267 (Some codegen cleanups around SIMD checks)
- #116712 (When encountering unclosed delimiters during lexing, check for diff markers)
- #117416 (Also consider TAIT to be uncomputable if the MIR body is tainted)
- #117421 (coverage: Replace impossible `coverage::Error` with assertions)
- #117438 (Do not ICE on constant evaluation failure in GVN.)
r? `@ghost`
`@rustbot` modify labels: rollup
Also consider TAIT to be uncomputable if the MIR body is tainted
Not totally sure if this is the best solution. We could, alternatively, look at the hir typeck results and try to take a type from there instead of just falling back to type error, inferring `u8` instead of `{type error}`. Not certain it really matters, though.
Happy to iterate on this.
Fixes#117413
r? ``@oli-obk`` cc ``@Nadrieril``
Store #[deprecated] attribute's `since` value in parsed form
This PR implements the first followup bullet listed in https://github.com/rust-lang/rust/pull/117148#issue-1960240108.
We centralize error handling to the attribute parsing code in `compiler/rustc_attr/src/builtin.rs`, and thereby remove some awkward error codepaths from later phases of compilation that had to make sense of these #\[deprecated\] attributes, namely `compiler/rustc_passes/src/stability.rs` and `compiler/rustc_middle/src/middle/stability.rs`.
Detect object safety errors when assoc type is missing
When an associated type with GATs isn't specified in a `dyn Trait`, emit an object safety error instead of only complaining about the missing associated type, as it will lead the user down a path of three different errors before letting them know that what they were trying to do is impossible to begin with.
Fix#103155.
When an associated type with GATs isn't specified in a `dyn Trait`, emit
an object safety error instead of only complaining about the missing
associated type, as it will lead the user down a path of three different
errors before letting them know that what they were trying to do is
impossible to begin with.
Fix#103155.
Rollup of 7 pull requests
Successful merges:
- #116862 (Detect when trait is implemented for type and suggest importing it)
- #117389 (Some diagnostics improvements of `gen` blocks)
- #117396 (Don't treat closures/coroutine types as part of the public API)
- #117398 (Correctly handle nested or-patterns in exhaustiveness)
- #117403 (Poison check_well_formed if method receivers are invalid to prevent typeck from running on it)
- #117411 (Improve some diagnostics around `?Trait` bounds)
- #117414 (Don't normalize to an un-revealed opaque when we hit the recursion limit)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't normalize to an un-revealed opaque when we hit the recursion limit
Currently, we will normalize `Opaque := Option<&Opaque>` to something like `Option<&Option<&Option<&...Opaque>>>`, hitting a limit and bottoming out in an unnormalized opaque after the recursion limit gets hit.
Unfortunately, during `layout_of`, we'll simply recurse and try again if the type normalizes to something different than the type:
e6e931dda5/compiler/rustc_ty_utils/src/layout.rs (L58-L60)
That means then we'll try to normalize `Option<&Option<&Option<&...Opaque>>>` again, substituting `Opaque` into itself even deeper. Eventually this will get to the point that we're just stack-overflowing on a really deep type before even hitting an opaque again.
To fix this, we just bottom out into `ty::Error` instead of the unrevealed opaque type.
Fixes#117412
r? `@oli-obk`
Improve some diagnostics around `?Trait` bounds
* uses better spans
* clarifies a message that was only talking about generic params, but applies to `dyn ?Trait` and `impl ?Trait` as well
Poison check_well_formed if method receivers are invalid to prevent typeck from running on it
fixes#117379
Though if some code invokes typeck without having first invoked `check_well_formed` then we'll encounter this ICE again. This can happen in const and const fn bodies if they are evaluated due to other `check_well_formed` checks or similar
Correctly handle nested or-patterns in exhaustiveness
I had assumed nested or-patterns were flattened, and they mostly are but not always.
Fixes https://github.com/rust-lang/rust/issues/117378
Fix missing leading space in suggestion
For a local pattern with no space between `let` and `(` e.g.:
```rust
let(_a) = 3;
```
we were previously suggesting this illegal code:
```rust
let_a = 3;
```
After this change the suggestion will instead be:
```rust
let _a = 3;
```
Fixes#117380
C-variadic error improvements
A couple improvements for c-variadic errors:
1. Fix the bad-c-variadic error being emitted multiple times. If a function incorrectly contains multiple `...` args, and is also not foreign or `unsafe extern "C"`, only emit the latter error once rather than once per `...`.
2. Explicitly reject `const` C-variadic functions. Trying to use C-variadics in a const function would previously fail with an error like "destructor of `VaListImpl<'_>` cannot be evaluated at compile-time". Add an explicit check for const C-variadics to provide a clearer error: "functions cannot be both `const` and C-variadic". This also addresses one of the concerns in https://github.com/rust-lang/rust/issues/44930: "Ensure that even when this gets stabilized for regular functions, it is still rejected on const fn."
On object safety error, mention new enum as alternative
When we encounter a `dyn Trait` that isn't object safe, look for its implementors. If there's one, mention using it directly If there are less than 9, mention the possibility of creating a new enum and using that instead.
Fix#80194.
rustdoc: elide cross-crate default generic arguments
Elide cross-crate generic arguments if they coincide with their default.
TL;DR: Most notably, no more `Box<…, Global>` in `std`'s docs, just `Box<…>` from now on.
Fixes#80379.
Also helps with #44306. Follow-up to #103885, #107637.
r? ``@ghost``
