Skip to content

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