-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 5 pull requests #124258
Closed
Closed
Rollup of 5 pull requests #124258
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
…ing `yield` expressions
And suggest adding the `#[coroutine]` to the closure
Stabilise inline_const # Stabilisation Report ## Summary This PR will stabilise `inline_const` feature in expression position. `inline_const_pat` is still unstable and will *not* be stabilised. The feature will allow code like this: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from rust-lang/rfcs#2920 and is tracked in rust-lang#76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in rust-lang#77124. ## Difference from RFC There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content *within* it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. rust-lang#89964). The inference is implemented in rust-lang#89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body. This allows code like: ```rust let v: Vec<i32> = const { Vec::new() }; ``` Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in rust-lang#96557. This allows code like: ```rust fn create_none_array<T, const N: usize>() -> [Option<T>; N] { [const { None::<T> }; N] } ``` This enhancement also makes inline const usable as static asserts: ```rust fn require_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) } } ``` ## Documentation Reference: rust-lang/reference#1295 ## Unresolved issues We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation: * expr fragment specifier issue: rust-lang#86730 * ~~`const {}` behaves similar to `async {}` but not to `{}` and `unsafe {}` (they are treated as `ExpressionWithoutBlock` rather than `ExpressionWithBlock`): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453~~ ## Tests There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const
…iler-errors Require explicitly marking closures as coroutines instead of relying on patching up the closure to be a coroutine if it happens to contain a `yield` expression. I only do this in the 2024 edition, as the `gen` keyword is only available there.
…=compiler-errors Fix ICE when ADT tail has type error Fixes rust-lang#124031
…-obk [cleanup] [llvm backend] Prevent creating the same `Instance::mono` multiple times Just a little thing I came across while going through the code. r? `@oli-obk`
…=oli-obk Miri: detect wrong vtables in wide pointers Fixes rust-lang/miri#3497. Needed to catch the UB that rust-lang#123572 will start exploiting. r? `@oli-obk`
rustbot
added
PG-exploit-mitigations
Project group: Exploit mitigations
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.
rollup
A PR which is a rollup
labels
Apr 22, 2024
@bors r+ p=5 rollup=never |
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
Apr 22, 2024
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 22, 2024
…llaumeGomez Rollup of 5 pull requests Successful merges: - rust-lang#104087 (Stabilise inline_const) - rust-lang#123792 (Require explicitly marking closures as coroutines) - rust-lang#124057 (Fix ICE when ADT tail has type error) - rust-lang#124178 ([cleanup] [llvm backend] Prevent creating the same `Instance::mono` multiple times) - rust-lang#124220 (Miri: detect wrong vtables in wide pointers) r? `@ghost` `@rustbot` modify labels: rollup
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Apr 22, 2024
@GuillaumeGomez: It would be useful if you ping the PR that causes the issue and r- it, rather than just reopening a new one without the PR you're suspicious of |
I am still going through the suspicious ones, hence why I didn't comment yet. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
PG-exploit-mitigations
Project group: Exploit mitigations
rollup
A PR which is a rollup
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.
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:
Instance::mono
multiple times #124178 ([cleanup] [llvm backend] Prevent creating the sameInstance::mono
multiple times)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup