Skip to content
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
wants to merge 15 commits into from

Conversation

GuillaumeGomez
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

oli-obk and others added 15 commits April 19, 2024 15:06
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 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
@GuillaumeGomez
Copy link
Member Author

@bors r+ p=5 rollup=never

@bors
Copy link
Contributor

bors commented Apr 22, 2024

📌 Commit 23e24c7 has been approved by GuillaumeGomez

It is now in the queue for this repository.

@bors 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
Copy link
Contributor

bors commented Apr 22, 2024

⌛ Testing commit 23e24c7 with merge 7037eae...

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
@rust-log-analyzer
Copy link
Collaborator

The job aarch64-gnu failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

---- [coverage-run] tests/coverage/coroutine.rs stdout ----
diff of coverage:

-    LL|       |#![feature(coroutines, coroutine_trait)]
+    LL|       |#![feature(coroutines, coroutine_trait, stmt_expr_attributes)]
2    LL|       |
3    LL|       |use std::ops::{Coroutine, CoroutineState};
4    LL|       |use std::pin::Pin;
18    LL|       |
18    LL|       |
19    LL|      1|fn main() {

@bors
Copy link
Contributor

bors commented Apr 22, 2024

💔 Test failed - checks-actions

@bors 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
@compiler-errors
Copy link
Member

@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

@GuillaumeGomez
Copy link
Member Author

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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants