-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Reduce special treatment for zsts #67501
Conversation
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
r? @RalfJung |
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #67540) made this pull request unmergeable. Please resolve the merge conflicts. |
7979cdd
to
7674921
Compare
☔ The latest upstream changes (presumably #67596) made this pull request unmergeable. Please resolve the merge conflicts. |
This is quite clever! I am conflicted. I don't like the weird condition in The previous uses of Do you think there is any chance to also kill the other use of |
There are also two uses of |
Even if we removed OpTy::from(ImmTy::from(Scalar::zst(), layout)).try_as_mplace() So I'm not sure what we'd have gained. |
Two? I remember one, for calling This point still stands, though:
|
Two in miri, and one in the miri engine (the one for drop) |
That feels impossible to uphold and I don't see what we'd gain. Do you want to prevent |
7674921
to
e503852
Compare
We'd gain not baking these fake dangling pointers into the implemented semantics of the Abstract Machine in an observable way. Or rather, that's a property that we currently have, and I do not want to lose it. |
(Dang, looks like GH stopped sending email notifications for force-pushes. So please let me know when this is ready for review again.) |
I can poison the |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
I addressed all the review comments.
I did the audit and found no problematic cases. All cases are either |
This comment has been minimized.
This comment has been minimized.
cd0cacc
to
c9c71d1
Compare
c9c71d1
to
d0b24e5
Compare
Just a couple nits. r=me with those fixed. |
@bors r=RalfJung |
📌 Commit c5c4fa8 has been approved by |
…Jung Reduce special treatment for zsts addresses rust-lang#67467 (comment) cc @RalfJung
…Jung Reduce special treatment for zsts addresses rust-lang#67467 (comment) cc @RalfJung
Rollup of 6 pull requests Successful merges: - #66463 (Point at opaque and closure type definitions in type errors) - #67501 (Reduce special treatment for zsts) - #67820 (Parse the syntax described in RFC 2632) - #67922 (rustc_ast_lowering: misc cleanup & rustc dep reductions) - #68071 (Extend support of `_` in type parameters) - #68073 (expect `fn` after `const unsafe` / `const extern`) Failed merges: r? @ghost
@oli-obk Miri broke in a rollup containing this PR, and this seems like the likely culprit. Could you prepare a fixup PR? |
on it |
Don't try to force_ptr pointers to zsts r? @RalfJung cc @wesleywiser This is required to fix miri after #67501 broke it. The reason only miri sees this is that it uses validation on values during interpretation and not just on the final value of constants, which never contain such values.
This bug was fixed by rust-lang#67501. Closes rust-lang#69312
Add test for rust-lang#69312 This bug was fixed by rust-lang#67501. Closes rust-lang#69312
addresses #67467 (comment)
cc @RalfJung