Consider fields to be inhabited if they are unstable #133889

compiler-errors · 2024-12-05T04:04:19Z

Fixes #133885 with a simple heuristic

r? Nadrieril

Not totally certain if this needs T-lang approval or a crater run.

compiler-errors · 2024-12-05T04:04:52Z

(to prepare a try-build for crater if necessary, and to gauge the impact of the stability lookup which ideally should be pretty cheap)

Consider fields to be inhabited if they are unstable Fixes rust-lang#133885 with a simple heuristic r? Nadrieril Not totally certain if this needs T-lang approval or a crater run.

bors · 2024-12-05T04:06:03Z

⌛ Trying commit ee9f838 with merge 8e0d53a...

bors · 2024-12-05T04:22:58Z

💔 Test failed - checks-actions

compiler-errors · 2024-12-05T05:02:52Z

@bors try @rust-timer queue

bors · 2024-12-05T05:04:03Z

⌛ Trying commit cf82347 with merge c9f0231...

Consider fields to be inhabited if they are unstable Fixes rust-lang#133885 with a simple heuristic r? Nadrieril Not totally certain if this needs T-lang approval or a crater run.

bors · 2024-12-05T06:49:12Z

☀️ Try build successful - checks-actions
Build commit: c9f0231 (c9f0231718f963060e42a8aabbcf3897585cc274)

rust-timer · 2024-12-05T11:52:04Z

Finished benchmarking commit (c9f0231): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.1%, 0.2%]	2
Regressions ❌ (secondary)	0.9%	[0.4%, 1.7%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.6%	[-1.8%, -0.6%]	7
All ❌✅ (primary)	0.2%	[0.1%, 0.2%]	2

Max RSS (memory usage)

Results (secondary 1.6%)

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)	3.3%	[1.9%, 4.3%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.1%	[-5.1%, -5.1%]	1
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary -2.9%)

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)	-	-	0
Improvements ✅ (secondary)	-2.9%	[-3.2%, -2.5%]	2
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 769.678s -> 768.797s (-0.11%)
Artifact size: 330.86 MiB -> 330.89 MiB (0.01%)

Nadrieril · 2024-12-06T18:07:10Z

Hmm, this fixes the issue for Pin but not user-defined types with a similar use of public-but-hidden types. And there's no way to say "really don't notice this is empty plz" in a case like that. This feels a bit ridiculous but: could we also exclude doc(hidden) fields from inhabitedness considerations?

Nadrieril · 2024-12-06T18:10:43Z

That'd be a bigger breaking change though, we can fix this first. I'm ok with this PR and I also don't know how to proceed here. Are there any other structs in std that could be affected by this? They'd need to be unstable, public, and directly depend on a generic parameter.

Nadrieril · 2024-12-06T18:15:29Z

On second thought, we should also ignore unstable fields here:

rust/compiler/rustc_pattern_analysis/src/rustc.rs

Line 238 in bc145ce

let skip = is_uninhabited && !is_visible;

so that a pattern like Pin { .. } isn't linted as unreachable.

compiler-errors · 2024-12-06T19:21:03Z

On second thought, we should also ignore unstable fields here:

Good point.

Are there any other structs in std that could be affected by this? They'd need to be unstable, public, and directly depend on a generic parameter.

Not from a cursory search. The only types that seem to be affected are the new range types (that are themselves not stable): https://doc.rust-lang.org/nightly/core/range/

This feels a bit ridiculous but: could we also exclude doc(hidden) fields from inhabitedness considerations?

I kinda wish that exhaustiveness was opt-in rather than opt-out. This seems really weird to make doc(hidden) affect semantics, in a way that unstable does not, given that it's already affecting privacy checks.

Nadrieril · 2024-12-06T19:37:22Z

Thanks for looking into it!

I kinda wish that exhaustiveness was opt-in rather than opt-out. This seems really weird to make doc(hidden) affect semantics, in a way that unstable does not, given that it's already affecting privacy checks.

Oh yeah, I was thinking we should take both into account.

And yeah having doc(hidden) affect semantics is weird. I'm noting that if we don't then do that changing a doc(hidden) field from public to private is a breaking change, which I think is not otherwise considered to be the case.

compiler-errors · 2024-12-06T19:46:44Z

I'm noting that if we don't then do that changing a doc(hidden) field from public to private is a breaking change, which I think is not otherwise considered to be the case.

@Nadrieril: Making a field public to private, even if it's doc(hidden), is already breaking today. A user can still access that field if it's doc(hidden). It's just not documented.

Nadrieril · 2024-12-06T19:56:45Z

It is technically breaking in that it can break code that compiles, but cargo-semver-checks would consider that non-breaking I believe (they have clever handling of doc(hidden)), so I'm inclined to follow their lead.

steffahn · 2024-12-07T04:37:51Z

If an unihabitedness determination relies exclusively on doc(hidden) field(s), then it could produce a deny-by-default lint instead of hard error?

compiler-errors · 2025-02-24T19:31:37Z

@Nadrieril:

I actually don't know what you're asking for here. Specifically,

"...also ignore unstable fields here..." Can you actually make a test where this makes an observable difference on top of the inhabitedness check we have? Or is this just a theoretical thing?
What do you mean by a test involving _: Pin<Void>? In param position? I'd appreciate if you write it out, because I think the test I added is sufficient.

@rustbot ready

compiler-errors · 2025-03-07T17:53:20Z

ping @Nadrieril

Nadrieril · 2025-03-18T17:29:38Z

1. "...also ignore unstable fields here..." Can you actually make a test where this makes an observable difference on top of the inhabitedness check we have? Or is this just a theoretical thing?

This is not theoretical: the code in exhaustiveness must be kept in sync with what we consider inhabited else there will be weird discrepancies. The tests I suggested (specifically Pin { .. }) is an attempt at exercising these code paths. I haven't tested but I expect this still warns unreachable with your PR:

#[deny(unreachable)]
fn foo(x: Pin<Void>) {
    match x {
        Pin { .. } => {}
    }
}

Don't remember why I asked for a match x { _ => {} } case but doesn't hurt to add it.

@rustbot author

…-if-unmarked to be uninhabited

rustbot · 2025-03-18T18:25:16Z

Some changes occurred in exhaustiveness checking

cc @Nadrieril

rust-log-analyzer · 2025-03-18T19:01:32Z

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

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

compiler-errors · 2025-03-19T00:08:03Z

@rustbot ready

Nadrieril · 2025-03-19T08:48:59Z

Ty!

@bors r+

bors · 2025-03-19T08:49:03Z

📌 Commit 0a6a0e4 has been approved by Nadrieril

It is now in the queue for this repository.

bors · 2025-03-19T08:49:04Z

🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened.

bors · 2025-03-20T14:31:38Z

⌛ Testing commit 0a6a0e4 with merge d8e44b7...

bors · 2025-03-20T17:40:36Z

☀️ Test successful - checks-actions
Approved by: Nadrieril
Pushing d8e44b7 to master...

github-actions · 2025-03-20T17:42:10Z

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 87e60a7 (parent) -> d8e44b7 (this PR)

Test differences

Show 11 test diffs

[ui] tests/ui/uninhabited/uninhabited-pin-field.rs (stage 2): [missing] -> pass (J0)
[ui] tests/ui/uninhabited/uninhabited-unstable-field.rs#current (stage 2): [missing] -> pass (J0)
[ui] tests/ui/uninhabited/uninhabited-unstable-field.rs#exhaustive (stage 2): [missing] -> pass (J0)
[ui] tests/ui/uninhabited/uninhabited-pin-field.rs (stage 1): [missing] -> pass (J1)
[ui] tests/ui/uninhabited/uninhabited-unstable-field.rs#current (stage 1): [missing] -> pass (J1)
[ui] tests/ui/uninhabited/uninhabited-unstable-field.rs#exhaustive (stage 1): [missing] -> pass (J1)
[run-make] tests/run-make/compressed-debuginfo-zstd (stage 2): ignore (ignored if LLVM wasn't build with zstd for ELF section compression (we want LLVM/LLD to be built with zstd support)) -> pass (J2)

Additionally, 4 doctest diffs were found. These are ignored, as they are noisy.

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
J2: x86_64-gnu-nopt

rust-timer · 2025-03-20T19:59:07Z

Finished benchmarking commit (d8e44b7): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

If the regression was expected or you think it can be justified,
please write a comment with sufficient written justification, and add
@rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
If you think that you know of a way to resolve the regression, try to create
a new PR with a fix for the regression.
If you do not understand the regression or you think that it is just noise,
you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.2%, 0.2%]	3
Regressions ❌ (secondary)	1.4%	[0.3%, 1.9%]	11
Improvements ✅ (primary)	-0.0%	[-0.0%, -0.0%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[-0.0%, 0.2%]	4

Max RSS (memory usage)

Results (primary 1.3%, secondary -1.0%)

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.3%	[0.8%, 1.8%]	2
Regressions ❌ (secondary)	2.9%	[2.9%, 2.9%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.0%	[-5.0%, -5.0%]	1
All ❌✅ (primary)	1.3%	[0.8%, 1.8%]	2

Cycles

Results (secondary 2.1%)

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)	2.1%	[2.0%, 2.2%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 773.84s -> 775.297s (0.19%)
Artifact size: 365.50 MiB -> 365.52 MiB (0.00%)

rustbot assigned Nadrieril Dec 5, 2024

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. labels Dec 5, 2024

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 5, 2024

This comment has been minimized.

Sign in to view

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 5, 2024

This comment has been minimized.

Sign in to view

rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Dec 5, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 24, 2025

compiler-errors force-pushed the inh-unstable branch from bacd80b to 4709b18 Compare February 24, 2025 19:34

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 18, 2025

compiler-errors added 2 commits March 18, 2025 18:23

Consider fields to be inhabited if they are unstable

f6107ca

Dont consider fields that are forced unstable due to -Zforce-unstable…

0a6a0e4

…-if-unmarked to be uninhabited

compiler-errors force-pushed the inh-unstable branch from 4709b18 to 0a6a0e4 Compare March 18, 2025 18:25

compiler-errors closed this Mar 18, 2025

compiler-errors reopened this Mar 18, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 19, 2025

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

bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 20, 2025

bors merged commit d8e44b7 into rust-lang:master Mar 20, 2025
10 of 13 checks passed

rustbot added this to the 1.87.0 milestone Mar 20, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Consider fields to be inhabited if they are unstable #133889

Consider fields to be inhabited if they are unstable #133889

compiler-errors commented Dec 5, 2024

compiler-errors commented Dec 5, 2024

This comment has been minimized.

bors commented Dec 5, 2024

This comment has been minimized.

bors commented Dec 5, 2024

This comment has been minimized.

compiler-errors commented Dec 5, 2024

This comment has been minimized.

bors commented Dec 5, 2024

bors commented Dec 5, 2024

This comment has been minimized.

rust-timer commented Dec 5, 2024

Nadrieril commented Dec 6, 2024

Nadrieril commented Dec 6, 2024

Nadrieril commented Dec 6, 2024

compiler-errors commented Dec 6, 2024

Nadrieril commented Dec 6, 2024 •

edited

Loading

compiler-errors commented Dec 6, 2024

Nadrieril commented Dec 6, 2024

steffahn commented Dec 7, 2024

compiler-errors commented Feb 24, 2025

compiler-errors commented Mar 7, 2025

Nadrieril commented Mar 18, 2025

rustbot commented Mar 18, 2025

rust-log-analyzer commented Mar 18, 2025

compiler-errors commented Mar 19, 2025

Nadrieril commented Mar 19, 2025

bors commented Mar 19, 2025

bors commented Mar 19, 2025

bors commented Mar 20, 2025

bors commented Mar 20, 2025

github-actions bot commented Mar 20, 2025

rust-timer commented Mar 20, 2025

Consider fields to be inhabited if they are unstable #133889

Consider fields to be inhabited if they are unstable #133889

Conversation

compiler-errors commented Dec 5, 2024

compiler-errors commented Dec 5, 2024

This comment has been minimized.

bors commented Dec 5, 2024

This comment has been minimized.

bors commented Dec 5, 2024

This comment has been minimized.

compiler-errors commented Dec 5, 2024

This comment has been minimized.

bors commented Dec 5, 2024

bors commented Dec 5, 2024

This comment has been minimized.

rust-timer commented Dec 5, 2024

Overall result: ❌✅ regressions and improvements - please read the text below

Nadrieril commented Dec 6, 2024

Nadrieril commented Dec 6, 2024

Nadrieril commented Dec 6, 2024

compiler-errors commented Dec 6, 2024

Nadrieril commented Dec 6, 2024 • edited Loading

compiler-errors commented Dec 6, 2024

Nadrieril commented Dec 6, 2024

steffahn commented Dec 7, 2024

compiler-errors commented Feb 24, 2025

compiler-errors commented Mar 7, 2025

Nadrieril commented Mar 18, 2025

rustbot commented Mar 18, 2025

rust-log-analyzer commented Mar 18, 2025

compiler-errors commented Mar 19, 2025

Nadrieril commented Mar 19, 2025

bors commented Mar 19, 2025

bors commented Mar 19, 2025

bors commented Mar 20, 2025

bors commented Mar 20, 2025

github-actions bot commented Mar 20, 2025

Test differences

rust-timer commented Mar 20, 2025

Overall result: ❌✅ regressions and improvements - please read the text below

Nadrieril commented Dec 6, 2024 •

edited

Loading