remove `feature(inline_const_pat)` #138492

lcnr · 2025-03-14T12:00:38Z

Summarizing https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/remove.20feature.28inline_const_pat.29.20and.20shared.20borrowck.

With rust-lang/types-team#129 we will start to borrowck items together with their typeck parent. This is necessary to correctly support opaque types, blocking the new solver and TAIT/ATPIT stabilization with the old one. This means that we cannot really support inline_const_pat as they are implemented right now:

we want to typeck inline consts together with their parent body to allow inference to flow both ways and to allow the const to refer to local regions of its parent.This means we also need to borrowck the inline const together with its parent as that's necessary to properly support opaque types
we want the inline const pattern to participate in exhaustiveness checking
to participate in exhaustiveness checking we need to evaluate it, which requires borrowck, which now relies on borrowck of the typeck root, which ends up checking exhaustiveness again. This is a query cycle.

There are 4 possible ways to handle this:

stop typechecking inline const patterns together with their parent
- causes inline const patterns to be different than inline const exprs
- prevents bidirectional inference, we need to either fail to compile if let const { 1 } = 1u32 or if let const { 1u32 } = 1
- region inference for inline consts will be harder, it feels non-trivial to support inline consts referencing local regions from the parent fn
inline consts no longer participate in exhaustiveness checking. Treat them like pat if pat == const { .. } instead. We then only evaluate them after borrowck
- difference between const { 1 } and const FOO: usize = 1; match x { FOO => () }. This is confusing
- do they carry their weight if they are now just equivalent to using an if-guard
delay exhaustiveness checking until after borrowck
- should be possible in theory, but is a quite involved change and may have some unexpected challenges
remove this feature for now

I believe we should either delay exhaustiveness checking or remove the feature entirely. As moving exhaustiveness checking to after borrow checking is quite complex I think the right course of action is to fully remove the feature for now and to add it again once/if we've got that implementation figured out.

const { .. }-expressions remain stable. These seem to have been the main motivation for rust-lang/rfcs#2920.

r? types

cc @rust-lang/types @rust-lang/lang #76001

rustbot · 2025-03-14T12:00:45Z

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

lcnr · 2025-03-14T14:30:15Z

https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/remove.20feature.28inline_const_pat.29.20and.20shared.20borrowck/near/505686774 coretests currently relies on inline_const_pat to avoid the lack of const PartialEq since #131707.

If we intend to go ahead with this removal, we can change this test to use named constants where necessary

TimNN · 2025-03-14T16:18:39Z

inline consts no longer participate in exhaustiveness checking

do they carry their weight if they are now just equivalent to using an if-guard

While the semantics would be equivalent to those of an if-guard, codegen for if-guards seems to be somewhat worse (at least for integers and C-like enums, I didn't check more complex types). Though I assume that the optimizer can recover this (at least for simpler cases).

What would be the cost of keeping inline const patterns around without exhaustiveness checking (as unstable for now)?

Or, alternatively, would it be feasible to optimize x if x == CONST => to CONST => before or during mir building?

(I don't have a concrete use case for const patterns right now but it seems sad/inconsistent/surprising to not have this feature).

src/tools/clippy/clippy_lints/src/matches/redundant_guards.rs

traviscross

Seems OK to me. We could always add this back if needed and after the mentioned changes were made. Clearing the way for TAIT/ATPIT is more important.

lcnr · 2025-03-18T13:07:14Z

codegen for if-guards seems to be somewhat worse (at least for integers and C-like enums, I didn't check more complex types). Though I assume that the optimizer can recover this (at least for simpler cases).

I feel like this would be desirable as an optimization regardless. Is there already an issue open for this?

What would be the cost of keeping inline const patterns around without exhaustiveness checking (as unstable for now)?

Without exhaustiveness checking seems non-trivial. It wouldn't be too involved to change their type inference behavior back to the behavior before #89561. I believe that this state would not be something we're willing to stabilize though, It won't support any region variables in the types of inline consts. const { "foo" } would ICE again (or error).

TimNN · 2025-03-18T13:32:20Z

I feel like this would be desirable as an optimization regardless. Is there already an issue open for this?

I couldn't find an existing issue, so opened #138664.

Without exhaustiveness checking seems non-trivial.

Then removing completely makes sense to me.

scottmcm · 2025-03-19T08:00:02Z

I do still think the feature makes sense, but it's just convenience, so no concerns at all about ripping it out for a while.

rustbot · 2025-03-21T08:37:56Z

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

add `TypingMode::Borrowck` Still not quite ready Based on rust-lang#138492 and rust-lang#138719 r? `@compiler-errors` `@oli-obk`

scottmcm · 2025-03-21T19:45:11Z

src/tools/rustfmt/tests/source/pattern.rs

@@ -91,7 +91,7 @@ fn issue3728() {

 fn literals() {
    match 42 {
-        const { 1 + 2 } | 4
+        1 | 2 | 4


Pondering: could consider leaving it in the parser, and just having it error semantically, since it sounds like the problem wasn't the syntax. Then rustfmt could be left as-is, for example.

(Either way is fine, though. Up to you.)

lcnr · 2025-03-28T09:32:54Z

Pondering: could consider leaving it in the parser, and just having it error semantically, since it sounds like the problem wasn't the syntax. Then rustfmt could be left as-is, for example.

I don't immediately know how to impl this while both being reasonably nice and not accidentally stabilizing anything 🤔

I mentioned this in #138492 (comment), but we could reimplement const block patterns using the old type inference/query behavior. I don't think it puts us closer towards a stabilizeable impl for const patterns so it would just be a perma-unstable feature 🤔 I would go ahead with removing this entirely but am totally open if someone else wants to (partially) readd support for this

@rustbot ready

oli-obk · 2025-03-31T14:14:05Z

@bors r+

bors · 2025-03-31T14:14:08Z

📌 Commit a3b7990 has been approved by oli-obk

It is now in the queue for this repository.

remove `feature(inline_const_pat)` Summarizing https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/remove.20feature.28inline_const_pat.29.20and.20shared.20borrowck. With rust-lang/types-team#129 we will start to borrowck items together with their typeck parent. This is necessary to correctly support opaque types, blocking the new solver and TAIT/ATPIT stabilization with the old one. This means that we cannot really support `inline_const_pat` as they are implemented right now: - we want to typeck inline consts together with their parent body to allow inference to flow both ways and to allow the const to refer to local regions of its parent.This means we also need to borrowck the inline const together with its parent as that's necessary to properly support opaque types - we want the inline const pattern to participate in exhaustiveness checking - to participate in exhaustiveness checking we need to evaluate it, which requires borrowck, which now relies on borrowck of the typeck root, which ends up checking exhaustiveness again. **This is a query cycle**. There are 4 possible ways to handle this: - stop typechecking inline const patterns together with their parent - causes inline const patterns to be different than inline const exprs - prevents bidirectional inference, we need to either fail to compile `if let const { 1 } = 1u32` or `if let const { 1u32 } = 1` - region inference for inline consts will be harder, it feels non-trivial to support inline consts referencing local regions from the parent fn - inline consts no longer participate in exhaustiveness checking. Treat them like `pat if pat == const { .. }` instead. We then only evaluate them after borrowck - difference between `const { 1 }` and `const FOO: usize = 1; match x { FOO => () }`. This is confusing - do they carry their weight if they are now just equivalent to using an if-guard - delay exhaustiveness checking until after borrowck - should be possible in theory, but is a quite involved change and may have some unexpected challenges - remove this feature for now I believe we should either delay exhaustiveness checking or remove the feature entirely. As moving exhaustiveness checking to after borrow checking is quite complex I think the right course of action is to fully remove the feature for now and to add it again once/if we've got that implementation figured out. `const { .. }`-expressions remain stable. These seem to have been the main motivation for rust-lang/rfcs#2920. r? types cc `@rust-lang/types` `@rust-lang/lang` rust-lang#76001

remove `feature(inline_const_pat)` Summarizing https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/remove.20feature.28inline_const_pat.29.20and.20shared.20borrowck. With rust-lang/types-team#129 we will start to borrowck items together with their typeck parent. This is necessary to correctly support opaque types, blocking the new solver and TAIT/ATPIT stabilization with the old one. This means that we cannot really support `inline_const_pat` as they are implemented right now: - we want to typeck inline consts together with their parent body to allow inference to flow both ways and to allow the const to refer to local regions of its parent.This means we also need to borrowck the inline const together with its parent as that's necessary to properly support opaque types - we want the inline const pattern to participate in exhaustiveness checking - to participate in exhaustiveness checking we need to evaluate it, which requires borrowck, which now relies on borrowck of the typeck root, which ends up checking exhaustiveness again. **This is a query cycle**. There are 4 possible ways to handle this: - stop typechecking inline const patterns together with their parent - causes inline const patterns to be different than inline const exprs - prevents bidirectional inference, we need to either fail to compile `if let const { 1 } = 1u32` or `if let const { 1u32 } = 1` - region inference for inline consts will be harder, it feels non-trivial to support inline consts referencing local regions from the parent fn - inline consts no longer participate in exhaustiveness checking. Treat them like `pat if pat == const { .. }` instead. We then only evaluate them after borrowck - difference between `const { 1 }` and `const FOO: usize = 1; match x { FOO => () }`. This is confusing - do they carry their weight if they are now just equivalent to using an if-guard - delay exhaustiveness checking until after borrowck - should be possible in theory, but is a quite involved change and may have some unexpected challenges - remove this feature for now I believe we should either delay exhaustiveness checking or remove the feature entirely. As moving exhaustiveness checking to after borrow checking is quite complex I think the right course of action is to fully remove the feature for now and to add it again once/if we've got that implementation figured out. `const { .. }`-expressions remain stable. These seem to have been the main motivation for rust-lang/rfcs#2920. r? types cc ``@rust-lang/types`` ``@rust-lang/lang`` rust-lang#76001

Rollup of 12 pull requests Successful merges: - rust-lang#110406 (rustdoc-json: Add test for #[automatically_derived] attribute) - rust-lang#137738 (Make slice iterator constructors unstably const) - rust-lang#138492 (remove `feature(inline_const_pat)`) - rust-lang#138928 (Fix UWP reparse point check) - rust-lang#138950 (replace extra_filename with strict version hash in metrics file names) - rust-lang#139002 (Add release notes for 1.86.0) - rust-lang#139022 (increment depth of nested obligations) - rust-lang#139060 (replace commit placeholder in vendor status with actual commit) - rust-lang#139102 (coverage: Avoid splitting spans during span extraction/refinement) - rust-lang#139129 (Add tests for slice bounds check optimization) - rust-lang#139188 (PassWrapper: adapt for llvm/llvm-project@94122d58fc77079a291a3d008914…) - rust-lang#139193 (Feed HIR for by-move coroutine body def, since the inliner tries to read its attrs) r? `@ghost` `@rustbot` modify labels: rollup

add `TypingMode::Borrowck` Still not quite ready Based on rust-lang#138492 r? `@compiler-errors` `@oli-obk`

bors · 2025-04-01T14:20:49Z

⌛ Testing commit a3b7990 with merge 0b4a81a...

bors · 2025-04-01T17:34:09Z

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 0b4a81a to master...

github-actions · 2025-04-01T17:36:31Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 8c35f4a (parent) -> 0b4a81a (this PR)

Test differences

Show 40 test diffs

Stage 1

[ui] tests/ui/consts/invalid-inline-const-in-match-arm.rs: pass -> [missing] (J1)
[ui] tests/ui/feature-gates/feature-gate-inline_const_pat.rs: pass -> [missing] (J1)
[ui] tests/ui/half-open-range-patterns/range_pat_interactions2.rs: pass -> [missing] (J1)
[ui] tests/ui/half-open-range-patterns/range_pat_interactions3.rs: pass -> [missing] (J1)
[ui] tests/ui/inline-const/collect-scopes-in-pat.rs: pass -> [missing] (J1)
[ui] tests/ui/inline-const/const-block-pat-liveness.rs: pass -> [missing] (J1)
[ui] tests/ui/inline-const/const-match-pat-generic.rs: pass -> [missing] (J1)
[ui] tests/ui/inline-const/const-match-pat-inference.rs: pass -> [missing] (J1)
[ui] tests/ui/inline-const/const-match-pat-lifetime-err.rs: pass -> [missing] (J1)
[ui] tests/ui/inline-const/const-match-pat-lifetime.rs: pass -> [missing] (J1)
[ui] tests/ui/inline-const/const-match-pat-range.rs: pass -> [missing] (J1)
[ui] tests/ui/inline-const/const-match-pat.rs: pass -> [missing] (J1)
[ui] tests/ui/inline-const/in-pat-recovery.rs: [missing] -> pass (J1)
[ui] tests/ui/inline-const/pat-match-fndef.rs: pass -> [missing] (J1)
[ui] tests/ui/inline-const/pat-unsafe-err.rs: pass -> [missing] (J1)
[ui] tests/ui/inline-const/pat-unsafe.rs: pass -> [missing] (J1)
[ui] tests/ui/lint/dead-code/anon-const-in-pat.rs: pass -> [missing] (J1)
[ui] tests/ui/match/issue-112438.rs: pass -> [missing] (J1)
[ui] tests/ui/type/pattern_types/const_block.rs: pass -> [missing] (J1)
[ui] tests/ui/unsafe/const_pat_in_layout_restricted.rs: pass -> [missing] (J1)

Stage 2

[ui] tests/ui/consts/invalid-inline-const-in-match-arm.rs: pass -> [missing] (J0)
[ui] tests/ui/feature-gates/feature-gate-inline_const_pat.rs: pass -> [missing] (J0)
[ui] tests/ui/half-open-range-patterns/range_pat_interactions2.rs: pass -> [missing] (J0)
[ui] tests/ui/half-open-range-patterns/range_pat_interactions3.rs: pass -> [missing] (J0)
[ui] tests/ui/inline-const/collect-scopes-in-pat.rs: pass -> [missing] (J0)
[ui] tests/ui/inline-const/const-block-pat-liveness.rs: pass -> [missing] (J0)
[ui] tests/ui/inline-const/const-match-pat-generic.rs: pass -> [missing] (J0)
[ui] tests/ui/inline-const/const-match-pat-inference.rs: pass -> [missing] (J0)
[ui] tests/ui/inline-const/const-match-pat-lifetime-err.rs: pass -> [missing] (J0)
[ui] tests/ui/inline-const/const-match-pat-lifetime.rs: pass -> [missing] (J0)
[ui] tests/ui/inline-const/const-match-pat-range.rs: pass -> [missing] (J0)
[ui] tests/ui/inline-const/const-match-pat.rs: pass -> [missing] (J0)
[ui] tests/ui/inline-const/in-pat-recovery.rs: [missing] -> pass (J0)
[ui] tests/ui/inline-const/pat-match-fndef.rs: pass -> [missing] (J0)
[ui] tests/ui/inline-const/pat-unsafe-err.rs: pass -> [missing] (J0)
[ui] tests/ui/inline-const/pat-unsafe.rs: pass -> [missing] (J0)
[ui] tests/ui/lint/dead-code/anon-const-in-pat.rs: pass -> [missing] (J0)
[ui] tests/ui/match/issue-112438.rs: pass -> [missing] (J0)
[ui] tests/ui/type/pattern_types/const_block.rs: pass -> [missing] (J0)
[ui] tests/ui/unsafe/const_pat_in_layout_restricted.rs: pass -> [missing] (J0)

Job group index

J0: aarch64-apple, aarch64-gnu, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1, test-various, x86_64-apple-2, x86_64-gnu, x86_64-gnu-llvm-18-1, x86_64-gnu-llvm-18-2, x86_64-gnu-llvm-19-1, x86_64-gnu-llvm-19-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1
J1: x86_64-gnu-llvm-18-3, x86_64-gnu-llvm-19-3

Job duration changes

aarch64-gnu-debug: 4000.2s -> 6348.7s (58.7%)
aarch64-gnu: 6394.6s -> 9850.9s (54.0%)
x86_64-apple-1: 7418.6s -> 10965.3s (47.8%)
aarch64-apple: 4135.9s -> 4999.2s (20.9%)
dist-apple-various: 6907.9s -> 8233.8s (19.2%)
dist-various-1: 4395.4s -> 4740.9s (7.9%)
dist-aarch64-apple: 5207.8s -> 5582.0s (7.2%)
dist-android: 2575.0s -> 2723.1s (5.8%)
i686-mingw-1: 7201.6s -> 7606.7s (5.6%)
dist-armhf-linux: 5037.4s -> 5299.4s (5.2%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2025-04-01T19:31:29Z

Finished benchmarking commit (0b4a81a): 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)

Results (primary -2.8%, secondary -2.4%)

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)	1.9%	[1.9%, 1.9%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.7%	[-4.4%, -3.1%]	5
Improvements ✅ (secondary)	-2.4%	[-4.2%, -0.7%]	47
All ❌✅ (primary)	-2.8%	[-4.4%, 1.9%]	6

Cycles

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

Binary size

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

Bootstrap: 774.818s -> 774.376s (-0.06%)
Artifact size: 365.93 MiB -> 365.93 MiB (-0.00%)

remove `feature(inline_const_pat)` Summarizing https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/remove.20feature.28inline_const_pat.29.20and.20shared.20borrowck. With rust-lang/types-team#129 we will start to borrowck items together with their typeck parent. This is necessary to correctly support opaque types, blocking the new solver and TAIT/ATPIT stabilization with the old one. This means that we cannot really support `inline_const_pat` as they are implemented right now: - we want to typeck inline consts together with their parent body to allow inference to flow both ways and to allow the const to refer to local regions of its parent.This means we also need to borrowck the inline const together with its parent as that's necessary to properly support opaque types - we want the inline const pattern to participate in exhaustiveness checking - to participate in exhaustiveness checking we need to evaluate it, which requires borrowck, which now relies on borrowck of the typeck root, which ends up checking exhaustiveness again. **This is a query cycle**. There are 4 possible ways to handle this: - stop typechecking inline const patterns together with their parent - causes inline const patterns to be different than inline const exprs - prevents bidirectional inference, we need to either fail to compile `if let const { 1 } = 1u32` or `if let const { 1u32 } = 1` - region inference for inline consts will be harder, it feels non-trivial to support inline consts referencing local regions from the parent fn - inline consts no longer participate in exhaustiveness checking. Treat them like `pat if pat == const { .. }` instead. We then only evaluate them after borrowck - difference between `const { 1 }` and `const FOO: usize = 1; match x { FOO => () }`. This is confusing - do they carry their weight if they are now just equivalent to using an if-guard - delay exhaustiveness checking until after borrowck - should be possible in theory, but is a quite involved change and may have some unexpected challenges - remove this feature for now I believe we should either delay exhaustiveness checking or remove the feature entirely. As moving exhaustiveness checking to after borrow checking is quite complex I think the right course of action is to fully remove the feature for now and to add it again once/if we've got that implementation figured out. `const { .. }`-expressions remain stable. These seem to have been the main motivation for rust-lang/rfcs#2920. r? types cc `@rust-lang/types` `@rust-lang/lang` rust-lang#76001

Nadrieril · 2025-04-06T10:29:23Z

I would go ahead with removing this entirely but am totally open if someone else wants to (partially) readd support for this

Can I rip out the hacks we use for the unsafeck of inline const pats then?

rustbot assigned oli-obk Mar 14, 2025

lcnr mentioned this pull request Mar 14, 2025

Tracking Issue for inline const patterns (RFC 2920) #76001

Open

11 tasks

This comment has been minimized.

Sign in to view

blyxyas reviewed Mar 14, 2025

View reviewed changes

src/tools/clippy/clippy_lints/src/matches/redundant_guards.rs Outdated Show resolved Hide resolved

dianne mentioned this pull request Mar 15, 2025

deref patterns: implement implicit deref patterns #138528

Open

traviscross approved these changes Mar 15, 2025

View reviewed changes

TimNN mentioned this pull request Mar 18, 2025

Optimize const pattern guards for StructuralEq types #138664

Open

lcnr force-pushed the rm-inline_const_pat branch 2 times, most recently from cb3adb7 to fdf7782 Compare March 20, 2025 14:12

This comment has been minimized.

Sign in to view

lcnr added 4 commits March 21, 2025 09:35

remove feature(inline_const_pat)

d4b8fa9

fix pretty test

7593562

coretests stop relying on inline_const_pat

8b2daac

update rustfmt test

a3b7990

lcnr force-pushed the rm-inline_const_pat branch from fdf7782 to a3b7990 Compare March 21, 2025 08:37

lcnr mentioned this pull request Mar 21, 2025

add TypingMode::Borrowck #138785

Merged

bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 21, 2025

Auto merge of rust-lang#138785 - lcnr:typing-mode-borrowck, r=<try>

7139b88

add `TypingMode::Borrowck` Still not quite ready Based on rust-lang#138492 and rust-lang#138719 r? `@compiler-errors` `@oli-obk`

scottmcm reviewed Mar 21, 2025

View reviewed changes

Zalathar mentioned this pull request Mar 30, 2025

Simplify thir::PatKind::ExpandedConstant #139108

Open

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 31, 2025

Zalathar mentioned this pull request Apr 1, 2025

Rollup of 16 pull requests #139203

Closed

Zalathar mentioned this pull request Apr 1, 2025

Rollup of 12 pull requests #139204

Closed

bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 1, 2025

Auto merge of rust-lang#138785 - lcnr:typing-mode-borrowck, r=<try>

f8ad33e

add `TypingMode::Borrowck` Still not quite ready Based on rust-lang#138492 r? `@compiler-errors` `@oli-obk`

bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 1, 2025

bors merged commit 0b4a81a into rust-lang:master Apr 1, 2025
7 checks passed

rustbot added this to the 1.88.0 milestone Apr 1, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

remove `feature(inline_const_pat)` #138492

remove `feature(inline_const_pat)` #138492

lcnr commented Mar 14, 2025 •

edited

Loading

rustbot commented Mar 14, 2025

This comment has been minimized.

lcnr commented Mar 14, 2025

This comment has been minimized.

TimNN commented Mar 14, 2025

traviscross left a comment

lcnr commented Mar 18, 2025

TimNN commented Mar 18, 2025

scottmcm commented Mar 19, 2025

This comment has been minimized.

rustbot commented Mar 21, 2025

scottmcm Mar 21, 2025

lcnr commented Mar 28, 2025 •

edited

Loading

oli-obk commented Mar 31, 2025

bors commented Mar 31, 2025

bors commented Apr 1, 2025

bors commented Apr 1, 2025

github-actions bot commented Apr 1, 2025

Stage 1

Stage 2

rust-timer commented Apr 1, 2025

Nadrieril commented Apr 6, 2025

remove feature(inline_const_pat) #138492

remove feature(inline_const_pat) #138492

Conversation

lcnr commented Mar 14, 2025 • edited Loading

rustbot commented Mar 14, 2025

This comment has been minimized.

lcnr commented Mar 14, 2025

This comment has been minimized.

TimNN commented Mar 14, 2025

traviscross left a comment

Choose a reason for hiding this comment

lcnr commented Mar 18, 2025

TimNN commented Mar 18, 2025

scottmcm commented Mar 19, 2025

This comment has been minimized.

rustbot commented Mar 21, 2025

scottmcm Mar 21, 2025

Choose a reason for hiding this comment

lcnr commented Mar 28, 2025 • edited Loading

oli-obk commented Mar 31, 2025

bors commented Mar 31, 2025

bors commented Apr 1, 2025

bors commented Apr 1, 2025

github-actions bot commented Apr 1, 2025

Test differences

Stage 1

Stage 2

Job duration changes

rust-timer commented Apr 1, 2025

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Nadrieril commented Apr 6, 2025

remove `feature(inline_const_pat)` #138492

remove `feature(inline_const_pat)` #138492

lcnr commented Mar 14, 2025 •

edited

Loading

lcnr commented Mar 28, 2025 •

edited

Loading