-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Stop using Reveal::All
before borrowck
#101478
Conversation
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri |
== "Sorts(ExpectedFound { expected: impl std::iter::Iterator<Item = ()>, found: std::iter::FlatMap<std::option::IntoIter<()>, std::vec::Vec<()>, [closure@src/main.rs:8:35: 8:38]> })" | ||
{ | ||
bug!() | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
woops, debug code 😁
@bors try |
⌛ Trying commit 734d9d3 with merge 9b4fd9cf46c3c08bce1c5ed60b929af1c4aaed01... |
This comment has been minimized.
This comment has been minimized.
ctfe returing |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
span, | ||
format!("Missing value for constant, but no error reported?"), | ||
format!("unable to use constant with a hidden value in the type system"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's a "constant with a hidden value"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that error message is bad but i wasn't able to think of a better one.
This can be hit in two cases:
- when encountering an opaque type during ctfe
- when encountering a default associated item (with
feature(specialization)
)
we should definitely change that message before merging this PR but I am not yet sure about the best way to do so
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 41066e2 with merge 0004f98fdd309b1940390200ae28913f7fbd736f... |
☀️ Try build successful - checks-actions |
Queued 0004f98fdd309b1940390200ae28913f7fbd736f with parent 0568b0a, future comparison URL. |
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri |
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
@rfcbot fcp cancel |
@lcnr proposal cancelled. |
I lowered some of the changes to a future compat lint which should hopefully allow us to merge this PR quickly without figuring out our exact goals for opaque types. This pull request changes the compiler to stop using
In cases where this is known to break existing code, we retry the failing code with This PR is necessary as using A crater run found 2 impacted crates:
|
Team member @lcnr has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
The job Click to see the possible cause of the failure (guessed by this bot)
|
☔ The latest upstream changes (presumably #98588) made this pull request unmergeable. Please resolve the merge conflicts. |
Wasn't the plan to allow querying the size of an opaque type during CTFE? Or does that not work / lead to the same query cycles?
I am trying to understand why this is non-wf. We have a |
Yes, but I am not comfortable with that change because it requires
(talking about this example) Yeah, that should actually be fine, bad example 😅 this currently causes an ICE because Only revealing the opaque type in the value - and not the Doing that with opaque types in where-bounds does result in non-wf types like this previous example. |
You'll have to spell this out in more detail for me, I don't see it.^^ (Also is there a better place to discuss this?) In a context where
I don't know what makes a bound trivial, but if that includes trivially false bounds like FWIW this does sound like the kind of conceptual question that I mentioned in our discussion a month or so ago, the kind of question that would benefit from some theory formalization and drafting. |
jup, trivially false bounds are the ones which are dangerous to drop. We currently drop all global ones I think, i.e. bounds which don't refer to any generic parameters 🤔 |
moved this to zulip: https://rust-lang.zulipchat.com/#narrow/stream/144729-t-types/topic/.60Reveal.3A.3AAll.60.20borrowck.20yeet |
talked about this with @nikomatsakis and @oli-obk in a recent meeting and we're still unhappy with the current solution. Going to experiment with a different approach where we lazily reveal opaque types on use and will open a new PR for that. |
Always use RevealAll for const eval queries implements what is described in rust-lang#116803 (comment) Using `UserFacing` for const eval does not make sense anymore, unless we significantly change things like avoiding revealing opaque types. New tests are copied from rust-lang#101478
Always use RevealAll for const eval queries implements what is described in rust-lang/rust#116803 (comment) Using `UserFacing` for const eval does not make sense anymore, unless we significantly change things like avoiding revealing opaque types. New tests are copied from rust-lang/rust#101478
Always use RevealAll for const eval queries implements what is described in rust-lang/rust#116803 (comment) Using `UserFacing` for const eval does not make sense anymore, unless we significantly change things like avoiding revealing opaque types. New tests are copied from rust-lang/rust#101478
Always use RevealAll for const eval queries implements what is described in rust-lang/rust#116803 (comment) Using `UserFacing` for const eval does not make sense anymore, unless we significantly change things like avoiding revealing opaque types. New tests are copied from rust-lang/rust#101478
Using
Reveal::All
before borrowck is incorrect, both because that means that we peek into opaque types at a point which is still observable by the user, and more importantly, because peaking into opaque types causes query cycles if it happens this early.I completely remove
param_env.with_reveal_all_normalized
. This function changes the context of a param env from "I am used for userfacing stuff" to "nm, actually I am not", which should always be incorrect or at least dubious enough to require an explicit impl with its own comment.This is a breaking change in a few subtle ways, so it definitely needs a crater run. Still have to add some more tests where this is impactful.
r? @rust-lang/types @rust-lang/wg-const-eval