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.
Pass 128-bit C-style enum enumerator values to LLVM
Pass the full 128 bits of C-style enum enumerators through to LLVM. This means that debuginfo for C-style repr128 enums is now emitted correctly for DWARF platforms (as compared to not being correctly emitted on any platform).
Tracking issue: #56071
add examples to chunks remainder methods.
add examples to chunks remainder methods.
my motivation for adding the examples was to make it very clear that the state of the iterator (in terms of where its cursor lies) has no effect on what remainder returns.
Also fixed some links to rchunk remainder methods.
rustdoc: remove unused JS IIFE from main.js
This [IIFE] made sense when it was added in deaf5e200e and there was a local variable scoped to it, but now it calls a function, but declares nothing.
[IIFE]: https://developer.mozilla.org/en-US/docs/Glossary/IIFE "immediately invoked function expression"
Add a detailed note for missing comma typo w/ FRU syntax
Thanks to `@pierwill` for working on this with me!
Fixes#104373, perhaps `@alice-i-cecile` can comment on the new error for the example provided on that issue -- feedback is welcome.
```
error[E0063]: missing field `defaulted` in initializer of `Outer`
--> $DIR/multi-line-fru-suggestion.rs:14:5
|
LL | Outer {
| ^^^^^ missing `defaulted`
|
note: this expression may have been misinterpreted as a `..` range expression
--> $DIR/multi-line-fru-suggestion.rs:16:16
|
LL | inner: Inner {
| ________________^
LL | | a: 1,
LL | | b: 2,
LL | | }
| |_________^ this expression does not end in a comma...
LL | ..Default::default()
| ^^^^^^^^^^^^^^^^^^^^ ... so this is interpreted as a `..` range expression, instead of functional record update syntax
help: to set the remaining fields from `Default::default()`, separate the last named field with a comma
|
LL | },
| +
error: aborting due to previous error
For more information about this error, try `rustc --explain E0063`.
```
Clarify and restrict when `{Arc,Rc}::get_unchecked_mut` is allowed.
(Tracking issue for `{Arc,Rc}::get_unchecked_mut`: #63292)
(I'm using `Rc` in this comment, but it applies for `Arc` all the same).
As currently documented, `Rc::get_unchecked_mut` can lead to unsoundness when multiple `Rc`/`Weak` pointers to the same allocation exist. The current documentation only requires that other `Rc`/`Weak` pointers to the same allocation "must not be dereferenced for the duration of the returned borrow". This can lead to unsoundness in (at least) two ways: variance, and `Rc<str>`/`Rc<[u8]>` aliasing. ([playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=d7e2d091c389f463d121630ab0a37320)).
This PR changes the documentation of `Rc::get_unchecked_mut` to restrict usage to when all `Rc<T>`/`Weak<T>` have the exact same `T` (including lifetimes). I believe this is sufficient to prevent unsoundness, while still allowing `get_unchecked_mut` to be called on an aliased `Rc` as long as the safety contract is upheld by the caller.
## Alternatives
* A less strict, but still sound alternative would be to say that the caller must only write values which are valid for all aliased `Rc`/`Weak` inner types. (This was [mentioned](https://github.com/rust-lang/rust/issues/63292#issuecomment-568284090) in the tracking issue). This may be too complicated to clearly express in the documentation.
* A more strict alternative would be to say that there must not be any aliased `Rc`/`Weak` pointers, i.e. it is required that get_mut would return `Some(_)`. (This was also mentioned in the tracking issue). There is at least one codebase that this would cause to become unsound ([here](be5a164d77/src/memtable.rs (L166)), where additional locking is used to ensure unique access to an aliased `Rc<T>`; I saw this because it was linked on the tracking issue).
Rollup of 6 pull requests
Successful merges:
- #104537 (fix std::thread docs are unclear regarding stack sizes)
- #104558 (Don't assume `FILE_ID_BOTH_DIR_INFO` will be aligned)
- #104564 (interpret: use Either over Result when it is not representing an error condition)
- #104568 (clarify that realloc refreshes pointer provenance even when the allocation remains in-place)
- #104611 (rustdoc: use real buttons for scrape examples controls)
- #104640 (Migrate kdb style to CSS variables)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
clarify that realloc refreshes pointer provenance even when the allocation remains in-place
This [matches what C does](https://en.cppreference.com/w/c/memory/realloc):
> The original pointer ptr is invalidated and any access to it is undefined behavior (even if reallocation was in-place).
Cc `@rust-lang/wg-allocators`
Check fat pointer metadata compatibility modulo regions
Regions don't really mean anything anyways during hir typeck.
If this `erase_regions` makes anyone nervous, it's probably equally valid to just equate the types using a type relation, but regardless we should _not_ be using strict type equality while region variables are present.
Fixes#103384
make miri-seed a regular integer, and also set layout-seed in many-seeds
This makes the seed format consistent between `-Zlayout-seed` and `-Zmiri-seed`.
