-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 14 pull requests #122711
Closed
Closed
Rollup of 14 pull requests #122711
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
when it is the default value of a generic param
A bit of an inelegant fix but given that the error is created only after call to `const_eval_poly()` and that the calling function cannot propagate the error anywhere else, the error has to be explicitly handled inside `mono_item.rs`.
Co-authored-by: Mateusz Mikuła <[email protected]>
They match on almost the same patterns, which is fishy. Also turn `associated_body` into a method and do some cleanups nearby the call sites
…le times There already were inconsistencies, so this ensures we don't introduce subtle surprising bugs
…y-generic-tys, r=compiler-errors Reject overly generic assoc const binding types Split off from rust-lang#119385 to make rust-lang#119385 easier to review. --- In the *instantiated* type of assoc const bindings 1. reject **early-bound generic params** * Provide a rich error message instead of ICE'ing ([rust-lang#108271](rust-lang#108271)). * This is a temporary and semi-artificial restriction until the arrival of *generic const generics*. * It's quite possible that rustc could already perfectly support this subset of generic const generics if we just removed some checks (some `.no_bound_vars().expect(…)`) but even if that was the case, I'd rather gate it behind a new feature flag. Reporting an error instead of ICE'ing is a good first step towards an eventual feature gate error. 2. reject **escaping late-bound generic params** * They lead to ICEs before & I'm pretty sure that they remain incorrect even in a world with *generic const generics* --- Together with rust-lang#118668 & rust-lang#119385, this supersedes rust-lang#118360. Fixes rust-lang#108271.
…piler-errors Use hir::Node helper methods instead of repeating the same impl multiple times I wanted to do something entirely different and stumbled upon a bunch of cleanups
…li-obk Stabilize associated type bounds (RFC 2289) This PR stabilizes associated type bounds, which were laid out in [RFC 2289]. This gives us a shorthand to express nested type bounds that would otherwise need to be expressed with nested `impl Trait` or broken into several `where` clauses. ### What are we stabilizing? We're stabilizing the associated item bounds syntax, which allows us to put bounds in associated type position within other bounds, i.e. `T: Trait<Assoc: Bounds...>`. See [RFC 2289] for motivation. In all position, the associated type bound syntax expands into a set of two (or more) bounds, and never anything else (see "How does this differ[...]" section for more info). Associated type bounds are stabilized in four positions: * **`where` clauses (and APIT)** - This is equivalent to breaking up the bound into two (or more) `where` clauses. For example, `where T: Trait<Assoc: Bound>` is equivalent to `where T: Trait, <T as Trait>::Assoc: Bound`. * **Supertraits** - Similar to above, `trait CopyIterator: Iterator<Item: Copy> {}`. This is almost equivalent to breaking up the bound into two (or more) `where` clauses; however, the bound on the associated item is implied whenever the trait is used. See rust-lang#112573/rust-lang#112629. * **Associated type item bounds** - This allows constraining the *nested* rigid projections that are associated with a trait's associated types. e.g. `trait Trait { type Assoc: Trait2<Assoc2: Copy>; }`. * **opaque item bounds (RPIT, TAIT)** - This allows constraining associated types that are associated with the opaque without having to *name* the opaque. For example, `impl Iterator<Item: Copy>` defines an iterator whose item is `Copy` without having to actually name that item bound. The latter three are not expressible in surface Rust (though for associated type item bounds, this will change in rust-lang#120752, which I don't believe should block this PR), so this does represent a slight expansion of what can be expressed in trait bounds. ### How does this differ from the RFC? Compared to the RFC, the current implementation *always* desugars associated type bounds to sets of `ty::Clause`s internally. Specifically, it does *not* introduce a position-dependent desugaring as laid out in [RFC 2289], and in particular: * It does *not* desugar to anonymous associated items in associated type item bounds. * It does *not* desugar to nested RPITs in RPIT bounds, nor nested TAITs in TAIT bounds. This position-dependent desugaring laid out in the RFC existed simply to side-step limitations of the trait solver, which have mostly been fixed in rust-lang#120584. The desugaring laid out in the RFC also added unnecessary complication to the design of the feature, and introduces its own limitations to, for example: * Conditionally lowering to nested `impl Trait` in certain positions such as RPIT and TAIT means that we inherit the limitations of RPIT/TAIT, namely lack of support for higher-ranked opaque inference. See this code example: rust-lang#120752 (comment). * Introducing anonymous associated types makes traits no longer object safe, since anonymous associated types are not nameable, and all associated types must be named in `dyn` types. This last point motivates why this PR is *not* stabilizing support for associated type bounds in `dyn` types, e.g, `dyn Assoc<Item: Bound>`. Why? Because `dyn` types need to have *concrete* types for all associated items, this would necessitate a distinct lowering for associated type bounds, which seems both complicated and unnecessary compared to just requiring the user to write `impl Trait` themselves. See rust-lang#120719. ### Implementation history: Limited to the significant behavioral changes and fixes and relevant PRs, ping me if I left something out-- * rust-lang#57428 * rust-lang#108063 * rust-lang#110512 * rust-lang#112629 * rust-lang#120719 * rust-lang#120584 Closes rust-lang#52662 [RFC 2289]: https://rust-lang.github.io/rfcs/2289-associated-type-bounds.html
… r=lcnr Stabilize `imported_main` FCP: rust-lang#28937 (comment) Docs: rust-lang/reference#1461
…r=davidtwco Gracefully handle `AnonConst` in `diagnostic_hir_wf_check()` Instead of running the WF check on the `AnonConst` itself we run it on the `ty` of the generic param of which the `AnonConst` is the default value. Fixes rust-lang#122199
misc cleanups from debugging something rename `instantiate_canonical_with_fresh_inference_vars` to `instantiate_canonical` the substs for the canonical are not solely infer vars as that would be wildly wrong and it is rather confusing to see this method called and think that the entire canonicalization setup is completely broken when it is not 👍 also update region debug printing to be more like the custom impls for Ty/Const, right now regions in debug output are horribly verbose and make it incredibly hard to read but with this atleast boundvars and placeholders when debugging the new solver do not take up excessive amounts of space. r? `@lcnr`
…p_remove, r=Amanieu Improve wording of `Vec::swap_remove` This improve the wording for `Vec::swap_remove`.
core: document default attribute stabilization As of now, the first release which stabilized the `#[default]` macro for the deriving the `Default` trait for enus is not documented. I have had to search the [`RELEASES.md`](https://github.com/rust-lang/rust/blob/master/RELEASES.md) when making sure my code would be accepted by an older Rust compiler. I just added a line in the doc comment since, as far as I know, there's no option to pass to the `#[stable()]` attribute. I am open to improvements in the wording.
…ls, r=compiler-errors `NormalizesTo`: return nested goals to caller Fixes the regression of `paperclip-core`. see https://hackmd.io/IsVAafiOTAaPIFcUxRJufw for more details. r? `@compiler-errors`
…manieu Fix ICE: `global_asm!()` Don't Panic When Unable to Evaluate Constant Fixes rust-lang#121099 A bit of an inelegant fix but given that the error is created only after call to `const_eval_poly()` and that the calling function cannot propagate the error anywhere else, the error has to be explicitly handled inside `mono_item.rs`. r? `@Amanieu`
…Gomez Fix heading anchors in doc pages. This fixes the heading anchors on the standalone doc pages (the index, releases, etc.) so that the § symbol is only shown when the user hovers over the heading. This was changed in rust-lang#117662, but this CSS was not updated.
Fix a typo in the 1.77.0 relnotes
…jubilee Remove redundant files, rename base riscv32 file Fixes a mistake I made in rust-lang#117874.
… r=oli-obk Detect allocator for box in `must_not_suspend` lint I don't expect this to happen in practice, but better to check than not. Fixes rust-lang#122643
rustbot
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
T-release
Relevant to the release subteam, which will review and decide on the PR/issue.
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
WG-trait-system-refactor
The Rustc Trait System Refactor Initiative (-Znext-solver)
rollup
A PR which is a rollup
labels
Mar 18, 2024
@bors r+ rollup=never p=14 |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Mar 18, 2024
The job Click to see the possible cause of the failure (guessed by this bot)
|
@bors r- |
bors
added
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Mar 18, 2024
proly #122370 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
rollup
A PR which is a rollup
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
T-release
Relevant to the release subteam, which will review and decide on the PR/issue.
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
WG-trait-system-refactor
The Rustc Trait System Refactor Initiative (-Znext-solver)
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:
imported_main
#122060 (Stabilizeimported_main
)AnonConst
indiagnostic_hir_wf_check()
#122370 (Gracefully handleAnonConst
indiagnostic_hir_wf_check()
)Vec::swap_remove
#122642 (Improve wording ofVec::swap_remove
)NormalizesTo
: return nested goals to caller #122687 (NormalizesTo
: return nested goals to caller)global_asm!()
Don't Panic When Unable to Evaluate Constant #122691 (Fix ICE:global_asm!()
Don't Panic When Unable to Evaluate Constant)must_not_suspend
lint #122701 (Detect allocator for box inmust_not_suspend
lint)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup