Skip to content
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

Move "mutable thing in const" check from interning to validity #78351

Merged
merged 5 commits into from
Oct 28, 2020

Conversation

RalfJung
Copy link
Member

This moves the check for mutable things (such as UnsafeCell or &mut) in aconst from interning to validity. That means we can give more targeted error messages (pointing out where the problem lies), and we can simplify interning a bit.

Also fix the interning mode used for promoteds in statics.

r? @oli-obk

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 25, 2020
@RalfJung RalfJung force-pushed the validity-unsafe-cell branch from a74e5ac to 7c7b90d Compare October 25, 2020 10:25
@oli-obk
Copy link
Contributor

oli-obk commented Oct 25, 2020

Thank you for taking pity on the interner and finally cleaning up that mess I left in there

@bors r+

@bors
Copy link
Contributor

bors commented Oct 25, 2020

📌 Commit 7c7b90d has been approved by oli-obk

@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 Oct 25, 2020
@RalfJung
Copy link
Member Author

I was complicit in creating the mess, having been the reviewer and prompting you to add more and more sanity checks. ;)

I added a comment at the top of the file explaining why interning is a bit more complicated than it might seem -- I think now wanting to make statics immutable where possible is truly all the complication that is left in this file, which is a nice separation of concerns. (Except for the "untyped pointers are not allowed in constant" error, which sticks out a bit.) Could you chck if this comment makes sense as well?

@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 25, 2020
@RalfJung
Copy link
Member Author

But this made me realize that if we used the "leftover interner" for consts and promoteds, the type-based traversal would be used only for statics, which would be a possible future simplification (if we are willing to give up that "untyped pointers are not allowed in constant" error)... just a possibility to keep in mind. ;)

@oli-obk
Copy link
Contributor

oli-obk commented Oct 25, 2020

My main worry with not handling all these pointers here is that validation doesn't care about pointers in padding, unions or anywhere else outside of typed values. So users could start putting raw pointers to mutable allocations into constants, and rightfully expect these to stay mutable (as that is fine at runtime). So we couldn't just make them immutable silently, and reporting errors on & references to mutable memory (without cells) is wrong, too.

@RalfJung
Copy link
Member Author

I think we totally can make them silently immutable. "Everything in a constant is immutable period" seems like a rule we could impose on such code.

But anyway, that's a discussion for the future. ;)

@oli-obk
Copy link
Contributor

oli-obk commented Oct 25, 2020

@bors r+

@bors
Copy link
Contributor

bors commented Oct 25, 2020

📌 Commit db01d97 has been approved by oli-obk

@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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 25, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Oct 25, 2020
…i-obk

Move "mutable thing in const" check from interning to validity

This moves the check for mutable things (such as `UnsafeCell` or `&mut`) in a`const` from interning to validity. That means we can give more targeted error messages (pointing out *where* the problem lies), and we can simplify interning a bit.

Also fix the interning mode used for promoteds in statics.

r? @oli-obk
@bors

This comment has been minimized.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 25, 2020
@RalfJung RalfJung force-pushed the validity-unsafe-cell branch from db01d97 to 744dfd8 Compare October 26, 2020 07:57
@RalfJung
Copy link
Member Author

@bors r=oli-obk

@bors
Copy link
Contributor

bors commented Oct 26, 2020

📌 Commit 744dfd8 has been approved by oli-obk

@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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 26, 2020
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 28, 2020
Rollup of 10 pull requests

Successful merges:

 - rust-lang#78152 (Separate unsized locals)
 - rust-lang#78297 (Suggest calling await on method call and field access)
 - rust-lang#78351 (Move "mutable thing in const" check from interning to validity)
 - rust-lang#78365 (check object safety of generic constants)
 - rust-lang#78379 (Tweak invalid `fn` header and body parsing)
 - rust-lang#78391 (Add const_fn in generics test)
 - rust-lang#78401 (resolve: private fields in tuple struct ctor diag)
 - rust-lang#78408 (Remove tokens from foreign items in `TokenStripper`)
 - rust-lang#78447 (Fix typo in  comment)
 - rust-lang#78453 (Fix typo in comments)

Failed merges:

r? `@ghost`
@bors bors merged commit 54ea0f9 into rust-lang:master Oct 28, 2020
@rustbot rustbot added this to the 1.49.0 milestone Oct 28, 2020
Comment on lines +8 to +12
//! is picking the right mutability for the allocations in a `static` initializer: we want to make
//! as many allocations as possible immutable so LLVM can put them into read-only memory. At the
//! same time, we need to make memory that could be mutated by the program mutable to avoid
//! incorrect compilations. To achieve this, we do a type-based traversal of the final value,
//! tracking mutable and shared references and `UnsafeCell` to determine the current mutability.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does that mean we could theoretically mark all static allocations as mutable? Is this pass slow to run, would that have any significant speedup?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's the other way around, we can just mark all allocations in constants as immutable. I'm not sure whether we'd get a speedup though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does that mean we could theoretically mark all static allocations as mutable? Is this pass slow to run, would that have any significant speedup?

For allocations in a static, yes, And then many people will complain that their read-only static are not put into read-only memory. So that's not really an option.

@RalfJung RalfJung deleted the validity-unsafe-cell branch October 28, 2020 08:30
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants