Rename `assert_uninit_valid` intrinsic
It's not about "uninit" anymore but about "filling with 0x01 bytes" so the name should at least try to reflect that.
This is actually not fully correct though, as it does still panic for all uninit with `-Zstrict-init-checks`. I'm not sure what the best way is to deal with that not causing confusion. I guess we could just remove the flag? I don't think having it makes a lot of sense anymore with the direction that we have chose to go. It could be relevant again if #100423 lands so removing it may be a bit over eager.
r? `@RalfJung`
Ensure async trait impls are async (or otherwise return an opaque type)
As a workaround for the full `#[refine]` semantics not being implemented
yet, forbit returning a concrete future type like `Box<dyn Future>` or a
manually implemented Future.
`-> impl Future` is still permitted; while that can also cause
accidental refinement, that's behind a different feature gate
(`return_position_impl_trait_in_trait`) and that problem exists
regardless of whether the trait method is async, so will have to be
solved more generally.
Fixes https://github.com/rust-lang/rust/issues/102745
As a workaround for the full `#[refine]` semantics not being implemented
yet, forbit returning a concrete future type like `Box<dyn Future>` or a
manually implemented Future.
`-> impl Future` is still permitted; while that can also cause
accidental refinement, that's behind a different feature gate
(`return_position_impl_trait_in_trait`) and that problem exists
regardless of whether the trait method is async, so will have to be
solved more generally.
Fixes#102745
This ensures that the error is printed even for unused variables,
as well as unifying the handling between the LLVM and GCC backends.
This also fixes unusual behavior around exported Rust-defined variables
with linkage attributes. With the previous behavior, it appears to be
impossible to define such a variable such that it can actually be imported
and used by another crate. This is because on the importing side, the
variable is required to be a pointer, but on the exporting side, the
type checker rejects static variables of pointer type because they do
not implement `Sync`. Even if it were possible to import such a type, it
appears that code generation on the importing side would add an unexpected
additional level of pointer indirection, which would break type safety.
This highlighted that the semantics of linkage on Rust-defined variables
is different to linkage on foreign items. As such, we now model the
difference with two different codegen attributes: linkage for Rust-defined
variables, and import_linkage for foreign items.
This change gives semantics to the test
src/test/ui/linkage-attr/auxiliary/def_illtyped_external.rs which was
previously expected to fail to compile. Therefore, convert it into a
test that is expected to successfully compile.
The update to the GCC backend is speculative and untested.
Rollup of 6 pull requests
Successful merges:
- #101975 (Suggest to use . instead of :: when accessing a method of an object)
- #105141 (Fix ICE on invalid variable declarations in macro calls)
- #105224 (Properly substitute inherent associated types.)
- #105236 (Add regression test for #47814)
- #105247 (Use parent function WfCheckingContext to check RPITIT.)
- #105253 (Update a couple of rustbuild deps)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
This avoids creation of a terminating scope in
chains that contain both && and ||, because
also there we know that a terminating scope is
not neccessary: all the chain members are already
in such terminating scopes.
Also add a mixed && / || test.
Previously a short circuiting && chain would drop the
first element after all the other elements, and otherwise
follow evaluation order, so code like:
f(1).g() && f(2).g() && f(3).g() && f(4).g()
would drop the temporaries in the order 2,3,4,1. This made
&& and || non-associative regarding drop order, so
adding ()'s to the expression would change drop order:
f(1).g() && (f(2).g() && f(3).g()) && f(4).g()
for example would drop in the order 3,2,4,1.
As, except for the bool result, there is no data returned
by the sub-expressions of the short circuiting binops,
we can safely discard of any temporaries created by the
sub-expr. Previously, code was already putting the rhs's
into terminating scopes, but missed it for the lhs's.
This commit addresses this "twist". In the expression,
we now also put the lhs into a terminating scope.
The drop order for the above expressions is 1,2,3,4
now.
Remove a lifetime resolution hack from `compare_predicate_entailment`
This is not needed anymore, probably due to #102334 equating the function signatures fully in `collect_trait_impl_trait_tys`. Also, the assertion in in #102903 makes sure that this is actually fixed, so I'm pretty confident this isn't needed.
Support using `Self` or projections inside an RPIT/async fn
I reuse the same idea as https://github.com/rust-lang/rust/pull/103449 to use variances to encode whether a lifetime parameter is captured by impl-trait.
The current implementation of async and RPIT replace all lifetimes from the parent generics by `'static`. This PR changes the scheme
```rust
impl<'a> Foo<'a> {
fn foo<'b, T>() -> impl Into<Self> + 'b { ... }
}
opaque Foo::<'_a>::foo::<'_b, T>::opaque<'b>: Into<Foo<'_a>> + 'b;
impl<'a> Foo<'a> {
// OLD
fn foo<'b, T>() -> Foo::<'static>::foo::<'static, T>::opaque::<'b> { ... }
^^^^^^^ the `Self` becomes `Foo<'static>`
// NEW
fn foo<'b, T>() -> Foo::<'a>::foo::<'b, T>::opaque::<'b> { ... }
^^ the `Self` stays `Foo<'a>`
}
```
There is the same issue with projections. In the example, substitute `Self` by `<T as Trait<'b>>::Assoc` in the sugared version, and `Foo<'_a>` by `<T as Trait<'_b>>::Assoc` in the desugared one.
This allows to support `Self` in impl-trait, since we do not replace lifetimes by `'static` any more. The same trick allows to use projections like `T::Assoc` where `Self` is allowed. The feature is gated behind a `impl_trait_projections` feature gate.
The implementation relies on 2 tweaking rules for opaques in 2 places:
- we only relate substs that correspond to captured lifetimes during TypeRelation;
- we only list captured lifetimes in choice region computation.
For simplicity, I encoded the "capturedness" of lifetimes as a variance, `Bivariant` vs `Invariant` for unused vs captured lifetimes. The `variances_of` query used to ICE for opaques.
Impl-trait that do not reference `Self` or projections will have their variances as:
- `o` (invariant) for each parent type or const;
- `*` (bivariant) for each parent lifetime --> will not participate in borrowck;
- `o` (invariant) for each own lifetime.
Impl-trait that does reference `Self` and/or projections will have some parent lifetimes marked as `o` (as the example above), and participate in type relation and borrowck. In the example above, `variances_of(opaque) = ['_a: o, '_b: *, T: o, 'b: o]`.
r? types
cc `@compiler-errors` , as you asked about the issue with `Self` and projections.
Improve spans for RPITIT object-safety errors
No reason why we can't point at the `impl Trait` that causes the object-safety violation.
Also [drive-by: Add is_async fn to hir::IsAsync](c4165f3a96), which touches clippy too.
nll: correctly deal with bivariance
fixes#104409
when in a bivariant context, relating stuff should always trivially succeed. Also changes the mir validator to correctly deal with higher ranked regions.
r? types cc ``@RalfJung``
Convert predicates into Predicate in the Obligation constructor
instead of having almost all callers do that.
This reduces a bit of boilerplate, and also paves the way for my work towards https://github.com/rust-lang/compiler-team/issues/531 (as it makes it easier to accept both goals and clauses where right now it only accepts predicates).
Don't remap early-bound regions for return-position `impl Trait` in trait originating from `impl`
long title 😓
We don't want to remap early-bound regions that originate from the `impl`s themselves, since they have no corresponding region in the trait. Not sure if there's a better condition than checking if the EBR's def-id's parent is the impl -- maybe we should be checking if the region comes from the method or RPITIT... 🤷
r? types
Fixes#103850
Record `LocalDefId` in HIR nodes instead of a side table
This is part of an attempt to remove the `HirId -> LocalDefId` table from HIR.
This attempt is a prerequisite to creation of `LocalDefId` after HIR lowering (https://github.com/rust-lang/rust/pull/96840), by controlling how `def_id` information is accessed.
This first part adds the information to HIR nodes themselves instead of a table.
The second part is https://github.com/rust-lang/rust/pull/103902
The third part will be to make `hir::Visitor::visit_fn` take a `LocalDefId` as last parameter.
The fourth part will be to completely remove the side table.
interpret: support for per-byte provenance
Also factors the provenance map into its own module.
The third commit does the same for the init mask. I can move it in a separate PR if you prefer.
Fixes https://github.com/rust-lang/miri/issues/2181
r? `@oli-obk`
Emit error in `collecting_trait_impl_trait_tys` on mismatched signatures
Previously, a `delay_span_bug` was isssued, failing normalization. This create a `TyKind::Error` in the signature, which caused `compare_predicate_entailment` to swallow its signature mismatch error, causing ICEs because no error was emitted.
fixes#104183
r? ``@compiler-errors``
Resolve lifetimes independently for each item-like.
Now that the heavy-lifting is done on the AST and during lowering, we do not need to perform HIR lifetime resolution on a full item at once. Instead, we can treat each item-like independently, and look at `generics_of` the parent exceptionally for associated items.
Cleanups in autoderef impl
Just something I noticed. Turns out the `overloaded_span` is not actually used separately from the main span, so I merged them.
Previously, a `delay_span_bug` was isssued, failing normalization. This
create a `TyKind::Error` in the signature, which caused
`compare_predicate_entailment` to swallow its signature mismatch error,
causing ICEs because no error was emitted.
Remove allow(rustc::potential_query_instability) in rustc_trait_selection
Related to https://github.com/rust-lang/rust/issues/84447
This PR needs to be benchmarked to check for regressions.
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.
(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`
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`
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.
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.
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`
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.
Make `dyn*` casts into a coercion, allow `dyn*` upcasting
I know that `dyn*` is likely not going to be a feature exposed to surface Rust, but this makes it slightly more ergonomic to write tests for these types anyways. ... and this was just fun to implement anyways.
1. Make `dyn*` into a coercion instead of a cast
2. Enable `dyn*` upcasting since we basically get it for free
3. Simplify some of the cast checking code since we're using the coercion path now
r? `@eholk` but feel free to reassign
cc `@nikomatsakis` and `@tmandry` who might care about making `dyn*` casts into a coercion
More dupe word typos
I only picked those changes (from the regex search) that I am pretty certain doesn't change meaning and is just a typo fix. Do correct me if any fix is undesirable and I can revert those. Thanks.
replace ReErased with fresh region vars in opaque types
See inline comments.
Prior art #102943. cc ``@compiler-errors`` ``@oli-obk``
Fixes#100267Fixes#101940Fixes#102649Fixes#102510
Support default-body trait functions with return-position `impl Trait` in traits
Introduce a new `Trait` candidate kind for the `ImplTraitInTrait` projection candidate, which just projects an RPITIT down to its opaque type form.
This is a hack until we lower RPITITs to regular associated types, after which we will need to rework how these default bodies are type-checked, so comments are left in a few places for us to clean up later.
Fixes#101665
Check representability in adt_sized_constraint
Now that representability is a query, we can use it to preemptively avoid a cycle in `adt_sized_constraint`.
I moved the representability check into `check_mod_type_wf` to avoid a scenario where rustc quits before checking all the types for representability. This also removes the check from rustdoc, which is alright AFAIK.
r? ``@cjgillot``
rename `ImplItemKind::TyAlias` to `ImplItemKind::Type`
The naming of this variant seems inconsistent given that this is not really a "type alias", and the associated type variant for `TraitItemKind` is just called `Type`.
Rewrite representability
* Improve placement of `Box` in the suggestion
* Multiple items in a cycle emit 1 error instead of an error for each item in the cycle
* Introduce `representability` query to avoid traversing an item every time it is used.
* Also introduce `params_in_repr` query to avoid traversing generic items every time it is used.
