What about: use-after-move and (maybe) use-after-drop · Issue #188 · rust-lang/unsafe-code-guidelines (original) (raw)

Skip to content

Navigation Menu

• • GitHub Copilot Write better code with AI
  • GitHub Advanced Security Find and fix vulnerabilities
  • Actions Automate any workflow
  • Codespaces Instant dev environments
  • Issues Plan and track work
  • Code Review Manage code changes
  • Discussions Collaborate outside of code
  • Code Search Find more, search less
• Explore
  • Learning Pathways
  • Events & Webinars
  • Ebooks & Whitepapers
  • Customer Stories
  • Partners
  • Executive Insights
• • GitHub Sponsors Fund open source developers
  • The ReadME Project GitHub community articles
• • Enterprise platform AI-powered developer platform
• Pricing

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sign up

Appearance settings

Description

Miri currently considers Copy and Move the same operation. There are some proposals in particular by @eddyb to make them not the same: it might be beneficial for optimizations to be able to rely on the data not being read again after a Move. This would correspond to replacing the data by Undef. It seems reasonable to do similar things for drop -- though that requires a precise definition of what is actually considered a drop (does that include just the Drop terminator or also calls to drop_in_place?).

(Miri concern: One reason why I am a bit hesitant about this is that this makes read have a side-effect, so we'd have to make all read methods in Miri take the interpreter context by &mut self. Reads already have a side-effect in Stacked Borrows but that is fairly local and we just use a RefCell there.)

@eddyb what would be such optimizations that benefit from this, where StorageDead is not happening so we need to rely on Move?

Potential blockers that would prevent deinit-on-move:

• Safe function MIR reads discriminant of moved-out local rust#91029

Reasons to do deinit-on-move:

• Semantics of MIR function calls rust#71117 (comment) (but might be solved by aliasing restrictions?)

Testcases:

• MIR: Do we allow accesing a moved place? rust#112564