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

Stabilise inline_const #104087

Merged
merged 5 commits into from
Apr 24, 2024
Merged

Stabilise inline_const #104087

merged 5 commits into from
Apr 24, 2024

Conversation

nbdd0121
Copy link
Contributor

@nbdd0121 nbdd0121 commented Nov 7, 2022

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:

foo(const { 1   1 })

which is roughly desugared into

struct Foo;
impl Foo {
    const FOO: i32 = 1   1;
}
foo(Foo::FOO)

This feature is from rust-lang/rfcs#2920 and is tracked in #76001 (the tracking issue should not be closed as it needs to track inline const in pattern position). The initial implementation is done in #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. #89964). The inference is implemented in #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:

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 #96557.

This allows code like:

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:

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:

Tests

There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const

@rustbot
Copy link
Collaborator

rustbot commented Nov 7, 2022

r? @JohnTitor

(rustbot has picked a reviewer for you, use r? to override)

@rustbot 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. labels Nov 7, 2022
@rustbot
Copy link
Collaborator

rustbot commented Nov 7, 2022

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

@rust-log-analyzer

This comment has been minimized.

@JohnTitor JohnTitor added the needs-fcp This change is insta-stable, so needs a completed FCP to proceed. label Nov 7, 2022
@JohnTitor
Copy link
Member

I think this needs FCP, cc @rust-lang/lang

@nbdd0121
Copy link
Contributor Author

nbdd0121 commented Nov 15, 2022

@rustbot label: -T-libs T-lang I-lang-nominated

@rustbot rustbot added I-lang-nominated The issue / PR has been nominated for discussion during a lang team meeting. T-lang Relevant to the language team, which will review and decide on the PR/issue. and removed T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Nov 15, 2022
@scottmcm

This comment was marked as outdated.

@rfcbot

This comment was marked as outdated.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Nov 15, 2022
@scottmcm

This comment was marked as outdated.

@rfcbot

This comment was marked as outdated.

@rfcbot rfcbot removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Nov 15, 2022
@scottmcm scottmcm removed the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Nov 15, 2022
@scottmcm
Copy link
Member

scottmcm commented Nov 15, 2022

Thanks for the report! It looks like the current state is enough to allow this to work:

pub fn create_none_array<T, const N: usize>() -> [Option<T>; N] {
    [const { None }; N]
}

which is the use that keeps coming up on URLO. And this also keeps coming up (1 2) on IRLO as needed (or at least wanted) for various things.

So let's do it!

@rfcbot fcp merge

cc Tracking Issue #76001, which also covers patterns so isn't closed by this PR.

@rfcbot

This comment was marked as outdated.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Nov 15, 2022
@scottmcm
Copy link
Member

(Sorry, compiler folks. One day I'll remember to check the labels before kicking off an FCP.)

@bors bors added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Apr 24, 2024
@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

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

@bors
Copy link
Contributor

bors commented Apr 24, 2024

⌛ Testing commit 8169c4c with merge 7bb4f08...

@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

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

@bors
Copy link
Contributor

bors commented Apr 24, 2024

☀️ Test successful - checks-actions
Approved by: scottmcm
Pushing 7bb4f08 to master...

1 similar comment
@bors
Copy link
Contributor

bors commented Apr 24, 2024

☀️ Test successful - checks-actions
Approved by: scottmcm
Pushing 7bb4f08 to master...

@bors bors added merged-by-bors This PR was explicitly merged by bors. labels Apr 24, 2024
@bors bors merged commit 7bb4f08 into rust-lang:master Apr 24, 2024
31 checks passed
@rustbot rustbot added this to the 1.79.0 milestone Apr 24, 2024
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (7bb4f08): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-2.0% [-2.0%, -2.0%] 1
Improvements ✅
(secondary)
-2.9% [-3.3%, -2.5%] 3
All ❌✅ (primary) -2.0% [-2.0%, -2.0%] 1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 674.062s -> 672.117s (-0.29%)
Artifact size: 316.12 MiB -> 316.14 MiB (0.01%)

@joshlf joshlf mentioned this pull request Apr 24, 2024
38 tasks
@nbdd0121 nbdd0121 deleted the const branch April 24, 2024 23:02
@nbdd0121
Copy link
Contributor Author

@rustbot label relnotes

@rustbot rustbot added the relnotes Marks issues that should be documented in the release notes of the next release. label Apr 29, 2024
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Apr 29, 2024
fmease added a commit to fmease/rust that referenced this pull request Jun 4, 2024
…trieb

Use inline const blocks to create arrays of `MaybeUninit`.

This PR contains 2 changes enabled by the fact that [`inline_const` is now stable](rust-lang#104087), and was split out of rust-lang#125082.

1. Use inline const instead of `unsafe` to construct arrays in `MaybeUninit` examples.

   Rationale: Demonstrate good practice of avoiding `unsafe` code where it is not strictly necessary.

4. Use inline const instead of `unsafe` to implement `MaybeUninit::uninit_array()`.

    This is arguably giving the compiler more work to do, in exchange for eliminating just one single internal unsafe block, so it's less certain that this is good on net.

r​? `@Nilstrieb`
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Jun 5, 2024
…trieb

Use inline const blocks to create arrays of `MaybeUninit`.

This PR contains 2 changes enabled by the fact that [`inline_const` is now stable](rust-lang#104087), and was split out of rust-lang#125082.

1. Use inline const instead of `unsafe` to construct arrays in `MaybeUninit` examples.

   Rationale: Demonstrate good practice of avoiding `unsafe` code where it is not strictly necessary.

4. Use inline const instead of `unsafe` to implement `MaybeUninit::uninit_array()`.

    This is arguably giving the compiler more work to do, in exchange for eliminating just one single internal unsafe block, so it's less certain that this is good on net.

r​? `@Nilstrieb`
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Jun 5, 2024
Rollup merge of rust-lang#125995 - kpreid:const-uninit-stable, r=Nilstrieb

Use inline const blocks to create arrays of `MaybeUninit`.

This PR contains 2 changes enabled by the fact that [`inline_const` is now stable](rust-lang#104087), and was split out of rust-lang#125082.

1. Use inline const instead of `unsafe` to construct arrays in `MaybeUninit` examples.

   Rationale: Demonstrate good practice of avoiding `unsafe` code where it is not strictly necessary.

4. Use inline const instead of `unsafe` to implement `MaybeUninit::uninit_array()`.

    This is arguably giving the compiler more work to do, in exchange for eliminating just one single internal unsafe block, so it's less certain that this is good on net.

r​? `@Nilstrieb`
flip1995 pushed a commit to flip1995/rust-clippy that referenced this pull request Jun 28, 2024
Use inline const blocks to create arrays of `MaybeUninit`.

This PR contains 2 changes enabled by the fact that [`inline_const` is now stable](rust-lang/rust#104087), and was split out of #125082.

1. Use inline const instead of `unsafe` to construct arrays in `MaybeUninit` examples.

   Rationale: Demonstrate good practice of avoiding `unsafe` code where it is not strictly necessary.

4. Use inline const instead of `unsafe` to implement `MaybeUninit::uninit_array()`.

    This is arguably giving the compiler more work to do, in exchange for eliminating just one single internal unsafe block, so it's less certain that this is good on net.

r​? `@Nilstrieb`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. F-inline_const Inline constants (aka: const blocks, const expressions, anonymous constants) finished-final-comment-period The final comment period is finished for this PR / Issue. merged-by-bors This PR was explicitly merged by bors. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. PG-exploit-mitigations Project group: Exploit mitigations relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet