Rollup of 9 pull requests #125955
Closed
Rollup of 9 pull requests #125955
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some of the bootstrap logics should be ignored during unit tests because they either make the tests take longer or cause them to fail. Therefore we need to be able to exclude them from the bootstrap when it's called by unit tests. This change introduces a new feature called `bootstrap-self-test`, which is enabled on bootstrap unit tests by default. This allows us to keep the logic separate between compiler builds and bootstrap tests without needing messy workarounds (like checking if target names match those in the unit tests). Signed-off-by: onur-ozkan <work@onurozkan.dev>
While the semantic intent of a OnceCell/OnceLock is that it can only be written to once (upon init), the fact of the matter is that both these types offer a `take(&mut self) -> Option<T>` mechanism that, when successful, resets the cell to its initial state, thereby technically allowing it to be written to again. Despite the fact that this can only happen with a mutable reference (generally only used during the construction of the OnceCell/OnceLock), it would be incorrect to say that the type itself as a whole categorically prevents being initialized or written to more than once (since it is possible to imagine an identical type only without the `take()` method that actually fulfills that contract). To clarify, change "that cannot be.." to "that nominally cannot.." and add a note to OnceCell about what can be done with an `&mut Self` reference.
…g you see on the page.
…ference-self, r=BoxyUwU
Item bounds can reference self projections and still be object safe
### Background
Currently, we have some interesting rules about where `Self` is allowed to be mentioned in objects. Specifically, we allow mentioning `Self` behind associated types (e.g. `fn foo(&self) -> Self::Assoc`) only if that `Self` type comes from the trait we're defining or its supertraits:
```
trait Foo {
fn good() -> Self::Assoc; // GOOD :)
fn bad() -> <Self as OtherTrait>::Assoc; // BAD!
}
```
And more specifically, these `Self::Assoc` projections are *only* allowed to show up in:
* (A1) Method signatures
* (A2) Where clauses on traits, GATs and methods
But `Self::Assoc` projections are **not** allowed to show up in:
* (B1) Supertrait bounds (specifically: all *super-predicates*, which includes the projections that come from elaboration, and not just the traits themselves).
* (B2) Item bounds of associated types
The reason for (B1) is interesting: specifically, it arises from the fact that we currently eagerly elaborate all projection predicates into the object, so if we had the following code:
```
trait Sub<Assoc = Self::SuperAssoc> {}
trait Super {
type SuperAssoc;
}
```
Then given `dyn Sub<SuperAssoc = i32>` we would need to have a type that is substituted into itself an infinite number of times[^1], like `dyn Sub<SuperAssoc = i32, Assoc = <dyn Sub<SuperAssoc = i32, Assoc = <dyn Sub<SuperAssoc = i32, Assoc = <... as Super>::SuperAssoc> as Super>::SuperAssoc> as Super>::SuperAssoc>`, i.e. the fixed-point of: `type T = dyn Sub<SuperAssoc = i32, Assoc = <T as Super>::SuperAssoc>`.
Similarly for (B2), we restrict mentioning `Self::Assoc` in associated type item bounds, which is the cause for rust-lang#122798. However, there is **no reason** for us to do so, since item bounds never show up structurally in the `dyn Trait` object type.
#### What?
This PR relaxes the check for item bounds so that `Self` may be mentioned behind associated types in the same cases that they currently work for method signatures (A1) and where clauses (A2).
#### Why?
Fixes rust-lang#122798. Removes a subtle and confusing inconsistency for the code mentioned in that issue.
This is sound because we only assemble alias bounds for rigid projections, and all projections coming from an object self type are not rigid, since all associated types should be specified by the type.
This is also desirable because we can do this via supertraits already. In rust-lang#122789, it is noted that an item bound of `Eq` already works, just not `PartialEq` because of the default item bound. This is weird and should be fixed.
#### Future work
We could make the check for `Self` in super-predicates more sophisticated as well, only erroring if `Self` shows up in a projection super-predicate.
[^1]: This could be fixed by some sort of structural replacement or eager normalization, but I don't think it's necessary currently.
…, r=ehuss Add tracking issue and unstable book page for `"vectorcall"` ABI Originally added in 2015 by rust-lang#30567, the Windows `"vectorcall"` ABI didn't have a tracking issue until now. Tracking issue: rust-lang#124485
…albertlarsan68 bootstrap: implement new feature `bootstrap-self-test` Some of the bootstrap logics should be ignored during unit tests because they either make the tests take longer or cause them to fail. Therefore we need to be able to exclude them from the bootstrap when it's called by unit tests. This change introduces a new feature called `bootstrap-self-test`, which is enabled on bootstrap unit tests by default. This allows us to keep the logic separate between compiler builds and bootstrap tests without needing messy workarounds (like checking if target names match those in the unit tests). Also, resolves rust-lang#122090 (without having to create separate modules)
Change pedantically incorrect OnceCell/OnceLock wording While the semantic intent of a OnceCell/OnceLock is that it can only be written to once (upon init), the fact of the matter is that both these types offer a `take(&mut self) -> Option<T>` mechanism that, when successful, resets the cell to its initial state, thereby [technically allowing it to be written to again](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=415c023a6ae1ef35f371a2d3bb1aa735) Despite the fact that this can only happen with a mutable reference (generally only used during the construction of the OnceCell/OnceLock), it would be incorrect to say that the type itself as a whole *categorically* prevents being initialized or written to more than once (since it is possible to imagine an identical type only without the `take()` method that actually fulfills that contract). To clarify, change "that cannot be.." to "that nominally cannot.." and add a note to OnceCell about what can be done with an `&mut Self` reference. `@rustbot` label +A-rustdocs
…huss ARM Target Docs Update Updates the ARM target docs, drawing more attention to the `arm-none-eabi` target group by placing all targets *within* that group as a sub-list in the Table of Contents. Also updates the `armv4t-none-eabi` page (maintainer signoff: I'm that target's maintainer) to clarify that the page covers the arm version and the thumb version of the target, but that the target group page has the full info because there's nothing really specific to say for those targets.
Align `Term` methods with `GenericArg` methods, add `Term::expect_*` * `Term::ty` -> `Term::as_type`. * `Term::ct` -> `Term::as_const`. * Adds `Term::expect_type` and `Term::expect_const`, and uses them in favor of `.ty().unwrap()`, etc. I could also shorten these to `as_ty` and then do `GenericArg::as_ty` as well, but I do think the `as_` is important to signal that this is a conversion method, and not a getter, like `Const::ty` is. r? types
…=petrochenkov Handle no values cfgs with `--print=check-cfg` This PR fix a bug with `--print=check-cfg`, where no values cfgs where not printed since we only printed cfgs that had at least one values. The representation I choose is `CFG=`, since it doesn't correspond to any valid config, it also IMO nicely complements the `values()` (to indicate no values). Representing the absence of value by the absence of the value. So for `cfg(feature, values())` we would print `feature=`. I also added the missing tracking issue number in the doc. r? `@petrochenkov`
…ket-impls, r=GuillaumeGomez rustdoc: add a regression test for a former blanket impl synthesis ICE Fixes rust-lang#119792 (also passes in rust-lang#125907 in case you were wondering). r? rustdoc
Remove stray "this"
rustbot
added
O-unix
rustbot
added
WG-trait-system-refactor
|
r? bors |
|
amazing @bors r+ rollup=never p=9 |
bors
added
S-waiting-on-bors
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
@bors r- |
bors
added
S-waiting-on-author
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
"vectorcall"ABI #124486 (Add tracking issue and unstable book page for"vectorcall"ABI)bootstrap-self-test#125273 (bootstrap: implement new featurebootstrap-self-test)Termmethods withGenericArgmethods, addTerm::expect_*#125750 (AlignTermmethods withGenericArgmethods, addTerm::expect_*)--print=check-cfg#125818 (Handle no values cfgs with--print=check-cfg)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup