Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Ensure
ptr::read
gets all the same LLVMload
metadata that dereferencing does #109035Ensure
ptr::read
gets all the same LLVMload
metadata that dereferencing does #109035Changes from 1 commit
b2c717f
0b96fee
1f70bb8
87696fd
e7c6ad8
dfc3377
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
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.
This confused me a bit — at first I though that
read_via_copy
only works for pointers to locals; While it seems like actually it can only be called with a pointer which is itself a local (i.e.read_via_copy(x)
✅,read_via_copy(s.f)
❎).Maybe the docs can be clarified a bit.
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.
This seems like a strange (and very syntactic) restriction? Isn't there a high risk that some other program transformation might, for instance, turn
into
?
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 can be fixed via introducing a temporary if it becomes a problem (and Jakob mentioned that on... Zulip?), but it seems the current tendency in the MIR is to aggressively desugar everything and introduce temporaries everywhere, then roll them back up in opt passes. If the implementation works and produces less MIR than the alternative, I think there's a merit in not introducing One More Temporary for the crab to claw through.
Maybe we should note why this "bug" was not "fixed", though, so that if anyone comes by and it needs to be fixed, they can immediately change it.
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.
Yes, this is about as big an optimization footgun as can exist. What saves us is that this runs before optimizations, so they don't have to care
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.
Still seems rather fragile, and needs at least a comment explaining the situation.
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.
@JakobDegen it would be super nice if this entire PR was just
Are there any plans to allow defining intrinsics with custom MIR? Maybe it's difficult because both are in
core
?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.
There's https://stdrs.dev/nightly/x86_64-unknown-linux-gnu/std/intrinsics/mir/macro.mir.html (err, which of course you know because you used it in the example 🤦), but I don't know if that's something we'd ever want to use for productized things, rather than just in tests.
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.
This does make a future-incompat warning into a hard error. Based on the comment here though, this seems to be pre-approved by T-lang. In any case, cc @RalfJung and @oli-obk for awareness
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.
Yeah, these future incompat warnings were because we wanted to make moving away from dubious const-eval patterns smoother as part of the Const UB Armistice of #99923, so that const UB doesn't immediately turn into const-break-the-build due to compiler changes. If people feel it's been enough time we can switch this off.
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.
This particular PR just affects
ptr::read()
which should definitely be fine imo. I'll leave the bikeshedding about what do to with the other cases to everyone else :)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.
IIRC, general temperature was that for these UB-in-
const
cases, a single warning stable cycle is probably sufficient, two is definitely sufficient, and that we're within rights to do no warning releases if we wanted to (i.e. warning at all is a good faith best effort to give some time to migrate).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.
Amusingly, the "see issue" is pointing at #68585, which is
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.
Purely if it was up to me: go for it.
It seems like this will be a hugely beneficial change, crates impacted were still technically "doing it wrong", we're landing this no sooner than 1.70 (so they've had 1.68 and will have 1.69 to fix it), and "const-stable since 1.63" actually means that we should cut it off sooner rather than later due to the "Lindy effect" that bad code patterns have (i.e. the longer a pattern exists, the longer it is expected to continue existing). "More time to migrate" is something we should be considering for const fn stabilizations with version numbers like 1.49
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.
Yeah this is fine, we can by now probably make that entire lint into a hard error.
What I don't understand immediately is why this PR changes behavior here though...
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.
It changes behavior because unaligned
copy_nonoverlapping
is (temporarily) allowed, but unaligned derefs are not: https://godbolt.org/z/M6f5MrjKo(and this PR changes
ptr::read
from usingcopy_nonoverlapping
to a deref)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's the thing, unaligned derefs should also be temporarily allowed...
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.
I am... confused. On playground both
*
andcopy_nonoverlapping
error: [play]. Moreover the lint fromcopy_nonoverlapping
is not actually a lint, you can't allow it: [play]. Lastly, the compiler says there are 3 errors, but only shows 2??...