Type inference for inline consts #89561

nbdd0121 · 2021-10-05T15:48:55Z

Fixes #78132
Fixes #78174
Fixes #81857
Fixes #89964

Perform type checking/inference of inline consts in the same context as the outer def, similar to what is currently done to closure.

Doing so would require closure_base_def_id of the inline const to return the outer def, and since closure_base_def_id can be called on non-local crate (and thus have no HIR available), a new DefKind is created for inline consts.

The type of the generated anon const can capture lifetime of outer def, so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue, and it uses extra type params CK, CS, U to capture closure kind, input/output signature and upvars. I use a similar approach for inline consts, letting it have an extra type param R, and then typeof(InlineConst<[paremt generics], R>) would just be R. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure.

With this PR, inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME.

Some disucssions can be found on this Zulip thread.
cc @spastorino @lcnr
r? @nikomatsakis

@rustbot label A-inference F-inline_const T-compiler

rust-highfive · 2021-10-05T15:48:58Z

Some changes occurred in intra-doc-links.

cc @jyn514

Some changes occurred in src/tools/clippy.

cc @rust-lang/clippy

jyn514 · 2021-10-05T16:00:10Z

src/librustdoc/passes/collect_intra_doc_links.rs

@@ -1938,7 1938,8 @@ fn resolution_failure(
 | Use
 | LifetimeParam
 | Ctor(_, _)
- | AnonConst => {
+ | AnonConst
+ | InlineConst => {


These should probably just be unreachable! ... but this change is fine, it should never be hit in practice.

lcnr

skimmed over this and it looks really nice, good job 👍 ❤️

compiler/rustc_middle/src/ty/util.rs

lcnr · 2021-10-05T16:14:59Z

compiler/rustc_typeck/src/check/regionck.rs

+ // Save state of current function. We will restore afterwards.
+ let old_body_id = self.body_id;
+ let old_body_owner = self.body_owner;
+ let env_snapshot = self.outlives_environment.push_snapshot_pre_closure();


same here, push_snapshot_pre_closure is somewhat badly named now

Renamed to push_snapshot_pre_typeck_child. Feel free to suggest a better name :)

nikomatsakis · 2021-10-06T20:27:29Z

Ah, very cool!

bors · 2021-10-23T12:29:54Z

☔ The latest upstream changes (presumably #90065) made this pull request unmergeable. Please resolve the merge conflicts.

spastorino

This seems great to me. Anyway, leaving this up to @nikomatsakis.

compiler/rustc_middle/src/ty/consts.rs

compiler/rustc_middle/src/ty/util.rs

nikomatsakis

r=me modulo nits

nikomatsakis · 2021-11-04T18:36:03Z

compiler/rustc_middle/src/ty/consts.rs

+ let parent_substs =
+ tcx.erase_regions(InternalSubsts::identity_for_item(tcx, outer_def_id));
+ let substs =
+ InlineConstSubsts::new(tcx, InlineConstSubstsParts { parent_substs, ty })


seems weird to erase regions above, given that ty is not erased here -- it'd be better to erase everything or nothing.

ty is from typeck().node_type() and is already erased.

compiler/rustc_middle/src/ty/consts.rs

compiler/rustc_borrowck/src/region_infer/mod.rs

compiler/rustc_borrowck/src/universal_regions.rs

nikomatsakis · 2021-11-04T18:56:35Z

compiler/rustc_borrowck/src/type_check/mod.rs

- UniversalRegions { defining_ty: DefiningTy::Const(def_id, _), .. },
+ UniversalRegions {
+ defining_ty:
+ DefiningTy::Const(def_id, _)


can we extract this into a method, so that we write

defining_ty.is_any_const()

?

There is is_const that does this, but this one needs to match def_id. I'll split it into a is_const call followed by a def_id call.

bors · 2021-11-07T02:07:47Z

☔ The latest upstream changes (presumably #90661) made this pull request unmergeable. Please resolve the merge conflicts.

In most cases it is handled in the same way as closures.

nikomatsakis · 2021-11-08T15:57:25Z

@bors r

bors · 2021-11-08T15:57:27Z

📌 Commit c4103d4 has been approved by nikomatsakis

Type inference for inline consts Fixes rust-lang#78132 Fixes rust-lang#78174 Fixes rust-lang#81857 Fixes rust-lang#89964 Perform type checking/inference of inline consts in the same context as the outer def, similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def, and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available), a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def, so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue, and it uses extra type params `CK, CS, U` to capture closure kind, input/output signature and upvars. I use a similar approach for inline consts, letting it have an extra type param `R`, and then `typeof(InlineConst<[paremt generics], R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR, inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc ``@spastorino`` ``@lcnr`` r? ``@nikomatsakis`` ``@rustbot`` label A-inference F-inline_const T-compiler

Type inference for inline consts Fixes rust-lang#78132 Fixes rust-lang#78174 Fixes rust-lang#81857 Fixes rust-lang#89964 Perform type checking/inference of inline consts in the same context as the outer def, similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def, and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available), a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def, so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue, and it uses extra type params `CK, CS, U` to capture closure kind, input/output signature and upvars. I use a similar approach for inline consts, letting it have an extra type param `R`, and then `typeof(InlineConst<[paremt generics], R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR, inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc ```@spastorino``` ```@lcnr``` r? ```@nikomatsakis``` ```@rustbot``` label A-inference F-inline_const T-compiler

Type inference for inline consts Fixes rust-lang#78132 Fixes rust-lang#78174 Fixes rust-lang#81857 Fixes rust-lang#89964 Perform type checking/inference of inline consts in the same context as the outer def, similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def, and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available), a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def, so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue, and it uses extra type params `CK, CS, U` to capture closure kind, input/output signature and upvars. I use a similar approach for inline consts, letting it have an extra type param `R`, and then `typeof(InlineConst<[paremt generics], R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR, inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc ````@spastorino```` ````@lcnr```` r? ````@nikomatsakis```` ````@rustbot```` label A-inference F-inline_const T-compiler

…askrgr Rollup of 7 pull requests Successful merges: - rust-lang#89561 (Type inference for inline consts) - rust-lang#90035 (implement rfc-2528 type_changing-struct-update) - rust-lang#90613 (Allow to run a specific rustdoc-js* test) - rust-lang#90683 (Make `compiler-docs` only control the default instead of being a hard off-switch) - rust-lang#90685 (x.py: remove fixme by deleting code) - rust-lang#90701 (Record more artifact sizes during self-profiling.) - rust-lang#90723 (Better document `Box` and `alloc::alloc::box_free` connection) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

Type inference for inline consts Fixes rust-lang#78132 Fixes rust-lang#78174 Fixes rust-lang#81857 Fixes rust-lang#89964 Perform type checking/inference of inline consts in the same context as the outer def, similar to what is currently done to closure. Doing so would require `closure_base_def_id` of the inline const to return the outer def, and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available), a new `DefKind` is created for inline consts. The type of the generated anon const can capture lifetime of outer def, so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue, and it uses extra type params `CK, CS, U` to capture closure kind, input/output signature and upvars. I use a similar approach for inline consts, letting it have an extra type param `R`, and then `typeof(InlineConst<[paremt generics], R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure. With this PR, inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME. Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck). cc `````@spastorino````` `````@lcnr````` r? `````@nikomatsakis````` `````@rustbot````` label A-inference F-inline_const T-compiler

Split inline const to two feature gates and mark expression position inline const complete This PR splits inline const in pattern position into its own `#![feature(inline_const_pat)]` feature gate, and make the usage in expression position complete. I think I have resolved most outstanding issues related to `inline_const` with rust-lang#89561 and other PRs. The only thing left that I am aware of is rust-lang#90150 and the lack of lifetime checks when inline const is used in pattern position (FIXME in rust-lang#89561). Implementation-wise when used in pattern position it has to be lowered during MIR building while in expression position it's evaluated only when monomorphizing (just like normal consts), so it makes some sense to separate it into two feature gates so one can progress without being blocked by another. `@rustbot` label: T-compiler F-inline_const

Split inline const to two feature gates and mark expression position inline const complete This PR splits inline const in pattern position into its own `#![feature(inline_const_pat)]` feature gate, and make the usage in expression position complete. I think I have resolved most outstanding issues related to `inline_const` with rust-lang#89561 and other PRs. The only thing left that I am aware of is rust-lang#90150 and the lack of lifetime checks when inline const is used in pattern position (FIXME in rust-lang#89561). Implementation-wise when used in pattern position it has to be lowered during MIR building while in expression position it's evaluated only when monomorphizing (just like normal consts), so it makes some sense to separate it into two feature gates so one can progress without being blocked by another. ``@rustbot`` label: T-compiler F-inline_const

…-const-block, r=fee1-dead Do not fail evaluation in const blocks Evaluate const blocks with a const param-env, so we properly check `~const` trait bounds. Fixes rust-lang#92713 (I will fix the poor diagnostics in rust-lang#92713 and rust-lang#92712 in a separate PR) cc `@nbdd0121` who wrote the code this PR touches in rust-lang#89561

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

rust-highfive assigned nikomatsakis Oct 5, 2021

rustbot added A-inference Area: Type inference F-inline_const Inline constants (aka: const blocks, const expressions, anonymous constants) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 5, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 5, 2021

nbdd0121 mentioned this pull request Oct 5, 2021

Fix region issues when using inline const block #88018

Closed

jyn514 reviewed Oct 5, 2021

View reviewed changes

lcnr reviewed Oct 5, 2021

View reviewed changes

lcnr mentioned this pull request Oct 18, 2021

inline_const blocks type inference #89964

Closed

nbdd0121 force-pushed the const_typeck branch from d7c2ba6 to 67c323b Compare October 23, 2021 21:57

This comment has been minimized.

Sign in to view

spastorino reviewed Oct 25, 2021

View reviewed changes

compiler/rustc_middle/src/ty/consts.rs Outdated Show resolved Hide resolved

compiler/rustc_middle/src/ty/util.rs Outdated Show resolved Hide resolved

nikomatsakis reviewed Nov 4, 2021

View reviewed changes

nbdd0121 added 8 commits November 7, 2021 03:59

Give inline const separate DefKind

02c1774

Implement type inference for inline consts

468192a

In most cases it is handled in the same way as closures.

Add unit test for issue 78132

4acef9a

Add unit test for issue 78174

1d32b20

Ensure closure requirements are proven for inline const

ff055e2

Add a FIXME note about what's missing

4060ed7

Fix closures within inline const

d0f59f6

Rename functions reflect that inline const is also "typeck_child"

c4103d4

nbdd0121 force-pushed the const_typeck branch from fea5c19 to c4103d4 Compare November 7, 2021 04:01

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 Nov 8, 2021

matthiaskrgr mentioned this pull request Nov 8, 2021

Rollup of 4 pull requests #90707

Closed

matthiaskrgr mentioned this pull request Nov 8, 2021

Rollup of 5 pull requests #90710

Closed

matthiaskrgr mentioned this pull request Nov 8, 2021

Rollup of 9 pull requests #90712

Closed

matthiaskrgr mentioned this pull request Nov 8, 2021

Rollup of 8 pull requests #90714

Closed

matthiaskrgr mentioned this pull request Nov 9, 2021

Rollup of 7 pull requests #90734

Merged

bors merged commit fd74c93 into rust-lang:master Nov 9, 2021

rustbot added this to the 1.58.0 milestone Nov 9, 2021

nbdd0121 deleted the const_typeck branch November 9, 2021 23:25

This was referenced Nov 10, 2021

ICE: 'Index 320440878 must be in bounds of vector type u16: [0, 2)', compiler/rustc_mir/src/interpret/intrinsics.rs:419:17 #83837

Closed

ICE: compiler/rustc_mir/src/interpret/place.rs:463:18: mplace_index called on non-array type f32x3 #82926

Closed

nbdd0121 mentioned this pull request Nov 22, 2021

Split inline const to two feature gates and mark expression position inline const complete #91140

Merged

compiler-errors mentioned this pull request Jan 14, 2022

Do not fail evaluation in const blocks #92892

Merged

nbdd0121 mentioned this pull request Nov 7, 2022

Stabilise inline_const #104087

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Type inference for inline consts #89561

Type inference for inline consts #89561

nbdd0121 commented Oct 5, 2021 •

edited

Loading

rust-highfive commented Oct 5, 2021

jyn514 Oct 5, 2021

lcnr left a comment

lcnr Oct 5, 2021

nbdd0121 Nov 7, 2021

nikomatsakis commented Oct 6, 2021

bors commented Oct 23, 2021

This comment has been minimized.

spastorino left a comment

nikomatsakis left a comment

nikomatsakis Nov 4, 2021

nbdd0121 Nov 6, 2021

nikomatsakis Nov 4, 2021

nbdd0121 Nov 6, 2021

bors commented Nov 7, 2021

nikomatsakis commented Nov 8, 2021

bors commented Nov 8, 2021

Type inference for inline consts #89561

Type inference for inline consts #89561

Conversation

nbdd0121 commented Oct 5, 2021 • edited Loading

rust-highfive commented Oct 5, 2021

jyn514 Oct 5, 2021

Choose a reason for hiding this comment

lcnr left a comment

Choose a reason for hiding this comment

lcnr Oct 5, 2021

Choose a reason for hiding this comment

nbdd0121 Nov 7, 2021

Choose a reason for hiding this comment

nikomatsakis commented Oct 6, 2021

bors commented Oct 23, 2021

This comment has been minimized.

spastorino left a comment

Choose a reason for hiding this comment

nikomatsakis left a comment

Choose a reason for hiding this comment

nikomatsakis Nov 4, 2021

Choose a reason for hiding this comment

nbdd0121 Nov 6, 2021

Choose a reason for hiding this comment

nikomatsakis Nov 4, 2021

Choose a reason for hiding this comment

nbdd0121 Nov 6, 2021

Choose a reason for hiding this comment

bors commented Nov 7, 2021

nikomatsakis commented Nov 8, 2021

bors commented Nov 8, 2021

nbdd0121 commented Oct 5, 2021 •

edited

Loading