Better error for HRTB error from generator interior
cc #100013
This is just a first pass at an error. It could be better, and shouldn't really be emitted in the first place. But this is better than what was being emitted before.
Make InferCtxtExt use a FxIndexMap
This should be faster, because the map is only being used to iterate,
which is supposed to be faster with the IndexMap
Make the user_computed_preds use an IndexMap
It is being used mostly for iteration, so the change shouldn't result in
a perf hit
Make the RegionDeps fields use an IndexMap
This change could be a perf hit. Both `larger` and `smaller` are used
for iteration, but they are also used for insertions.
Make types_without_default_bounds use an IndexMap
It uses extend, but it also iterates and removes items. Not sure if
this will be a perf hit.
Make InferTtxt.reported_trait_errors use an IndexMap
This change brought a lot of other changes. The map seems to have been
mostly used for iteration, so the performance shouldn't suffer.
Add FIXME to change ProvisionalEvaluationCache.map to use an IndexMap
Right now this results in a perf hit. IndexMap doesn't have
the `drain_filter` API, so in `on_completion` we now need to iterate two
times over the map.
Implement `std::marker::Tuple`, use it in `extern "rust-call"` and `Fn`-family traits
Implements rust-lang/compiler-team#537
I made a few opinionated decisions in this implementation, specifically:
1. Enforcing `extern "rust-call"` on fn items during wfcheck,
2. Enforcing this for all functions (not just ones that have bodies),
3. Gating this `Tuple` marker trait behind its own feature, instead of grouping it into (e.g.) `unboxed_closures`.
Still needing to be done:
1. Enforce that `extern "rust-call"` `fn`-ptrs are well-formed only if they have 1/2 args and the second one implements `Tuple`. (Doing this would fix ICE in #66696.)
2. Deny all explicit/user `impl`s of the `Tuple` trait, kinda like `Sized`.
3. Fixing `Tuple` trait built-in impl for chalk, so that chalkification tests are un-broken.
Open questions:
1. Does this need t-lang or t-libs signoff?
Fixes#99820
Fix late-bound lifetime closure ICEs in HIR typeck and MIR borrowck
During HIR typeck, we need to teach astconv to treat late-bound regions within a closure body as free, fixing escaping bound vars ICEs in both of the issues below.
However, this then gets us to MIR borrowck, which itself needs to be taught how to instantiate free region vids for late-bound regions that come from items that _aren't_ the typeck root (for now, just closures).
Fixes#103771Fixes#103736
fix(generic_const_exprs): Fix predicate inheritance for children of opaque types
Fixes#99705
We currently have a special case to perform predicate inheritance when the const item is in the generics. I think we're also going to need this for opaque return types. When evaluating the predicates applied to the associated item, it'll inherit from its parent, the opaque type, which will never have predicates applied. This PR bypass the opaque typed parent and inherit predicates directly from the function itself.
Change #[suggestion_*] attributes to use style="..."
As discussed [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/.23100717.20tool_only_span_suggestion), this changes `#[(multipart_)suggestion_{short,verbose,hidden}(...)]` attributes to plain `#[(multipart_)suggestion(...)]` attributes with a `style = "{short,verbose,hidden}"` parameter.
It also adds a new style, `tool-only`, that corresponds to `tool_only_span_suggestion`/`tool_only_multipart_suggestion` and causes the suggestion to not be shown in human-readable output at all.
Best reviewed commit-by-commit, there's a bit of noise in there.
cc #100717 `@compiler-errors`
r? `@davidtwco`
Track where diagnostics were created.
This implements the `-Ztrack-diagnostics` flag, which uses `#[track_caller]` to track where diagnostics are created. It is meant as a debugging tool much like `-Ztreat-err-as-bug`.
For example, the following code...
```rust
struct A;
struct B;
fn main(){
let _: A = B;
}
```
...now emits the following error message:
```
error[E0308]: mismatched types
--> src\main.rs:5:16
|
5 | let _: A = B;
| - ^ expected struct `A`, found struct `B`
| |
| expected due to this
-Ztrack-diagnostics: created at compiler\rustc_infer\src\infer\error_reporting\mod.rs:2275:31
```
(almost) Always use `ObligationCtxt` when dealing with canonical queries
Hope this is a step in the right direction. cc rust-lang/types-team#50.
r? `@lcnr`
Enable varargs support for calling conventions other than C or cdecl
This patch makes it possible to use varargs for calling conventions,
which are either based on C (efiapi) or C is based on them (sysv64 and win64).
Also pinging ``@phlopsi,`` because he noticed first this oversight when writing a library for UEFI.
Accept `TyCtxt` instead of `TyCtxtAt` in `Ty::is_*` functions
Functions in answer:
- `Ty::is_freeze`
- `Ty::is_sized`
- `Ty::is_unpin`
- `Ty::is_copy_modulo_regions`
This allows to remove a lot of useless `.at(DUMMY_SP)`, making the code a bit nicer :3
r? `@compiler-errors`
Rename some `OwnerId` fields.
`@spastorino` noticed some silly expressions like `item_id.def_id.def_id`.
This commit renames several `def_id: OwnerId` fields as `owner_id`, so those expressions become `item_id.owner_id.def_id`.
`item_id.owner_id.local_def_id` would be even clearer, but the use of `def_id` for values of type `LocalDefId` is *very* widespread, so I left that alone.
r? `@compiler-errors`
spastorino noticed some silly expressions like `item_id.def_id.def_id`.
This commit renames several `def_id: OwnerId` fields as `owner_id`, so
those expressions become `item_id.owner_id.def_id`.
`item_id.owner_id.local_def_id` would be even clearer, but the use of
`def_id` for values of type `LocalDefId` is *very* widespread, so I left
that alone.
Note scope of TAIT more accurately
This maybe explains why the person was confused in #101897, since we say "same module" but really should've said "same impl".
r? ``@oli-obk``
Introduce UnordMap, UnordSet, and UnordBag (MCP 533)
This is the start of implementing [MCP 533](https://github.com/rust-lang/compiler-team/issues/533).
I followed `@eddyb's` suggestion of naming the collection types `Unord(Map/Set/Bag)` which is a bit easier to type than `Unordered(Map/Set/Bag)`
r? `@eddyb`
Emit a nicer error on `impl Self {`
currently it emits a "cycle detected error" but this PR makes it emit a more user friendly error specifically saying that `Self` is disallowed in that position. this is a pretty hacky fix so i dont expect this to be merged (I basically only made this PR because i wanted to see if CI passes)
r? ``@compiler-errors``
Remap early bound lifetimes in return-position `impl Trait` in traits too
Fixes part of #103457
r? ``@cjgillot,`` though feel free to reassign, just thought you'd have sufficient context to review.
Add suggestions for unsafe impl error codes
Adds suggestions for users to add `unsafe` to trait impls that should be `unsafe`, and remove `unsafe` from trait impls that do not require `unsafe`
With the folllowing code:
```rust
struct Foo {}
struct Bar {}
trait Safe {}
unsafe trait Unsafe {}
impl Safe for Foo {} // ok
impl Unsafe for Foo {} // E0200
unsafe impl Safe for Bar {} // E0199
unsafe impl Unsafe for Bar {} // ok
// omitted empty main fn
```
The current rustc output is:
```
error[E0199]: implementing the trait `Safe` is not unsafe
--> e0200.rs:13:1
|
13 | unsafe impl Safe for Bar {} // E0199
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
error[E0200]: the trait `Unsafe` requires an `unsafe impl` declaration
--> e0200.rs:11:1
|
11 | impl Unsafe for Foo {} // E0200
| ^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0199, E0200.
For more information about an error, try `rustc --explain E0199`.
```
With this PR, the future rustc output would be:
```
error[E0199]: implementing the trait `Safe` is not unsafe
--> ../../temp/e0200.rs:13:1
|
13 | unsafe impl Safe for Bar {} // E0199
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
help: remove `unsafe` from this trait implementation
|
13 - unsafe impl Safe for Bar {} // E0199
13 + impl Safe for Bar {} // E0199
|
error[E0200]: the trait `Unsafe` requires an `unsafe impl` declaration
--> ../../temp/e0200.rs:11:1
|
11 | impl Unsafe for Foo {} // E0200
| ^^^^^^^^^^^^^^^^^^^^^^
|
= note: the trait `Unsafe` enforces invariants that the compiler can't check. Review the trait documentation and make sure this implementation upholds those invariants before adding the `unsafe` keyword
help: add `unsafe` to this trait implementation
|
11 | unsafe impl Unsafe for Foo {} // E0200
| ++++++
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0199, E0200.
For more information about an error, try `rustc --explain E0199`.
```
``@rustbot`` label +T-compiler +A-diagnostics +A-suggestion-diagnostics
This patch makes it possible to use varargs for calling conventions,
which are either based on C (like efiapi) or C is based
on them (for example sysv64 and win64).
Flatten diagnostic slug modules
This makes it easier to grep for the slugs in the code.
See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Localization.20infra.20interferes.20with.20grepping.20for.20error for more discussion about it.
This was mostly done with a few regexes and a bunch of manual work. This also exposes a pretty annoying inconsistency for the extra labels. Some of the extra labels are defined as additional properties in the fluent message (which makes them not prefixed with the crate name) and some of them are new fluent messages themselves (which makes them prefixed with the crate name). I don't know whether we want to clean this up at some point but it's useful to know.
r? `@davidtwco`
Introduce `subst_iter` and `subst_iter_copied` on `EarlyBinder`
Makes working with bounds lists a bit easier, which I seem to do a lot.
Specifically, means that we don't need to do `.transpose_iter().map(|(pred, _)| *pred)` every time we want to iterate through an `EarlyBinder<&'tcx [(Predicate, Span)]>` (and even then, still have to call `subst` later), which was a very awkward idiom imo.
stop using `ty::UnevaluatedConst` directly
best reviewed commit by commit.
simplifies #99798 because we now don't have to expand `ty::UnevaluatedConst` to `ty::Const`.
I also remember some other places where using `ty::UnevaluatedConst` directly was annoying and caused issues, though I don't quite remember what they were rn '^^
r? `@oli-obk` cc `@JulianKnodt`
Rollup of 6 pull requests
Successful merges:
- #102287 (Elaborate supertrait bounds when triggering `unused_must_use` on `impl Trait`)
- #102922 (Filtering spans when emitting json)
- #103051 (translation: doc comments with derives, subdiagnostic-less enum variants, more derive use)
- #103111 (Account for hygiene in typo suggestions, and use them to point to shadowed names)
- #103260 (Fixup a few tests needing asm support)
- #103321 (rustdoc: improve appearance of source page navigation bar)
Failed merges:
- #103209 (Diagnostic derives: allow specifying multiple alternative suggestions)
r? `@ghost`
`@rustbot` modify labels: rollup
Use already checked RHS ty for LHS deref suggestions
There's no reason to do the `check_lhs_assignable` and RHS `check_expr_with_hint` in that order, so invert them and use the typeck results to avoid exponential blowup on error.
Fixes#103219
Let expressions on RHS shouldn't be terminating scopes
Fixes#100276.
Before this PR, we were unconditionally marking the RHS of short-circuiting binary expressions as a terminating scope.
In the case of a let chain where the `let` expression was on the RHS, this meant that temporaries within the `let` expr would only live until the end of the expression. Since this only affected the RHS, this led to surprising behavior ([example](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=d1b0a5d1f01882f9c89c2194a75eb19f)).
After this PR, we only mark the RHS as a terminating scope if it is not a `let` expression.
