Skip to content

Add #![rustc_never_type_mode = "..."] crate-level attribute to allow experimenting #122543

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

Merged
merged 2 commits into from
Mar 15, 2024

Conversation

WaffleLapkin
Copy link
Member

@WaffleLapkin WaffleLapkin commented Mar 15, 2024

Demonstrating how different approaches with the never type work is somewhat hard when you can't actually provide a runnable example. Let's add features that change the fallback behavior.

This adds #![rustc_never_type_mode = "no_fallback"] and #![rustc_never_type_mode = "fallback_to_never"], but I also plan to add others (in future PRs).

cc @traviscross
r? @compiler-errors

@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. labels Mar 15, 2024
@rust-log-analyzer

This comment has been minimized.

@rust-cloud-vms rust-cloud-vms bot force-pushed the never-flags branch 2 times, most recently from 4e02b7a to e8e4ecf Compare March 15, 2024 13:49
@WaffleLapkin WaffleLapkin changed the title Add feature(no_never_type_fallback) to allow experimenting Add feature(no_never_type_fallback) and feature(no_never_type_spontaneous_decay) to allow experimenting Mar 15, 2024
@compiler-errors
Copy link
Member

I am having trouble finding value in adding these as feature flags. I think they should just be crate-level ![rustc_never_type_fallback = ".."] flags, since I don't believe we ever expect to allow users to choose this behavior.

@compiler-errors
Copy link
Member

Especially if you plan to add more feature gates, this just seems really unmanageable.

@WaffleLapkin
Copy link
Member Author

Well, yes, this is more for testing stuff and making sure T-lang understands what is the proposal with the never type.

@compiler-errors do you have a pointer of where a crate-level attribute was added? I made this as feature(s) because it was simpler to do, but I can rewrite this as an attribute, just not sure where those are handled in rustc..

@compiler-errors
Copy link
Member

We don't really "handle" crate-level attributes anywhere centralized.

They are just checked with tcx.has_attr(CRATE_DEF_ID, ..). Check out rustc_hidden_type_of_opaques for example. I guess use get_attr so you can read the meta part of the attribute.

@WaffleLapkin
Copy link
Member Author

@compiler-errors thanks <3 made this into an attribute.

@WaffleLapkin WaffleLapkin changed the title Add feature(no_never_type_fallback) and feature(no_never_type_spontaneous_decay) to allow experimenting Add no_never_type_fallback) and feature(no_never_type_spontaneous_decay) to allow experimenting Mar 15, 2024
@WaffleLapkin WaffleLapkin changed the title Add no_never_type_fallback) and feature(no_never_type_spontaneous_decay) to allow experimenting Add #![rustc_never_type_mode = "..."] crate-level attribute to allow experimenting Mar 15, 2024
@WaffleLapkin
Copy link
Member Author

There is a place where I'm not sure what to do:

// We failed to resolve the opaque type or it
// resolves to itself. We interpret this as the
// no values of the hidden type ever being constructed,
// so we can just make the hidden type be `!`.
// For backwards compatibility reasons, we fall back to
// `()` until we the diverging default is changed.
Ty::new_diverging_default(tcx)

I have no context on what this does..

@@ -580,6 +580,13 @@ pub const BUILTIN_ATTRIBUTES: &[BuiltinAttribute] = &[
"`may_dangle` has unstable semantics and may be removed in the future",
),

rustc_attr!(
rustc_never_type_mode, Normal, template!(NameValueStr: "fallback_to_unit|fallback_to_niko|no_fallback"), ErrorFollowing,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
rustc_never_type_mode, Normal, template!(NameValueStr: "fallback_to_unit|fallback_to_niko|no_fallback"), ErrorFollowing,
rustc_never_type_mode, Normal, template!(NameValueStr: "fallback_to_unit|fallback_to_niko|fallback_to_never|no_fallback"), ErrorFollowing,

@compiler-errors
Copy link
Member

There is a place where I'm not sure what to do:

// We failed to resolve the opaque type or it
// resolves to itself. We interpret this as the
// no values of the hidden type ever being constructed,
// so we can just make the hidden type be `!`.
// For backwards compatibility reasons, we fall back to
// `()` until we the diverging default is changed.
Ty::new_diverging_default(tcx)

I have no context on what this does..

It's for when there's no opaque type inference. Consider something like:

#![feature(never_type_fallback)]

trait Uwu {}
impl Uwu for () {}

fn foo() -> impl Uwu { foo() }
//~^ ERROR the trait bound `!: Uwu` is not satisfied

Copy link
Member

@compiler-errors compiler-errors left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks waffle ❤️

this is good enough for now though we may want to figure out wtf to do with that opaque type fallback 💀

also lol @ fallback_to_niko

@compiler-errors
Copy link
Member

@bors r+

@bors
Copy link
Collaborator

bors commented Mar 15, 2024

📌 Commit adfdd27 has been approved by compiler-errors

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 Mar 15, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 15, 2024
…er-errors

Add `#![rustc_never_type_mode = "..."]` crate-level attribute to allow experimenting

Demonstrating how different approaches with the never type work is somewhat hard when you can't actually provide a runnable example. Let's add features that change the fallback behavior.

This adds `#![rustc_never_type_mode = "no_fallback"]` and `#![rustc_never_type_mode = "fallback_to_never"]`, but I also plan to add others (in future PRs).

cc `@traviscross`
r? `@compiler-errors`
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 15, 2024
…iaskrgr

Rollup of 6 pull requests

Successful merges:

 - rust-lang#122254 (Detect calls to .clone() on T: !Clone types on borrowck errors)
 - rust-lang#122495 (Visually mark 👻hidden👻 items with document-hidden-items)
 - rust-lang#122543 (Add `#![rustc_never_type_mode = "..."]` crate-level attribute to allow experimenting)
 - rust-lang#122560 (Safe Transmute: Use 'not yet supported', not 'unspecified' in errors)
 - rust-lang#122562 (Mention labelled blocks in `break` docs)
 - rust-lang#122563 (CI: cache PR CI Docker builds)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 82d5b56 into rust-lang:master Mar 15, 2024
@rustbot rustbot added this to the 1.78.0 milestone Mar 15, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Mar 15, 2024
Rollup merge of rust-lang#122543 - WaffleLapkin:never-flags, r=compiler-errors

Add `#![rustc_never_type_mode = "..."]` crate-level attribute to allow experimenting

Demonstrating how different approaches with the never type work is somewhat hard when you can't actually provide a runnable example. Let's add features that change the fallback behavior.

This adds `#![rustc_never_type_mode = "no_fallback"]` and `#![rustc_never_type_mode = "fallback_to_never"]`, but I also plan to add others (in future PRs).

cc ``@traviscross``
r? ``@compiler-errors``
@WaffleLapkin WaffleLapkin deleted the never-flags branch March 16, 2024 22:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants