-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Remove SymbolStr
#91957
Remove SymbolStr
#91957
Conversation
By changing `as_str()` to take `&self` instead of `self`, we can just return `&str`. We're still lying about lifetimes, but it's a smaller lie than before, where `SymbolStr` contained a (fake) `&'static str`!
Some changes occured to rustc_codegen_cranelift cc @bjorn3 Some changes occurred in src/tools/rustfmt. Some changes occurred in cc @camelid Some changes occured to the CTFE / Miri engine cc @rust-lang/miri Some changes occurred in intra-doc-links. cc @jyn514 Some changes occurred in src/tools/clippy. cc @rust-lang/clippy Some changes occured to rustc_codegen_gcc cc @antoyo |
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @oli-obk (or someone else) soon. Please see the contribution instructions for more information. |
/// as `&self`, but actually tied to the lifetime of the underlying | ||
/// interner. Interners are long-lived, and there are very few of them, and | ||
/// this function is typically used for short-lived things, so in practice | ||
/// it works out ok. |
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 would be happy to see a better description than this, if anyone has one to offer.
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit b1c934e with merge 2b0871127a9ec9258077c392af12778176772fa1... |
☀️ Try build successful - checks-actions |
Queued 2b0871127a9ec9258077c392af12778176772fa1 with parent 3ee016a, future comparison URL. |
/// Note that the lifetime of the return value is a lie. It's not the same | ||
/// as `&self`, but actually tied to the lifetime of the underlying | ||
/// interner. Interners are long-lived, and there are very few of them, and | ||
/// this function is typically used for short-lived things, so in practice | ||
/// it works out ok. |
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 made a few edits. Feel free to apply none, some, or all:
/// Note that the lifetime of the return value is a lie. It's not the same | |
/// as `&self`, but actually tied to the lifetime of the underlying | |
/// interner. Interners are long-lived, and there are very few of them, and | |
/// this function is typically used for short-lived things, so in practice | |
/// it works out ok. | |
/// Note that the lifetime of the return value is a lie, so this function | |
/// is unsound. The runtime lifetime is not the same as `&self`; | |
/// it's actually tied to the lifetime of the underlying interner. | |
/// Interners are long-lived, there are very few of them, and | |
/// this function is typically used for short-lived things; so in practice | |
/// it works out ok. |
Finished benchmarking commit (2b0871127a9ec9258077c392af12778176772fa1): comparison url. Summary: This change led to very large relevant mixed results 🤷 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never |
/// requires locking the symbol interner. | ||
/// | ||
/// Note that the lifetime of the return value is a lie. See | ||
/// `Symbol::as_str()` for details. |
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.
Uh, do we really want to have unsound functions in widely used crate-public APIs?
I very strongly feel that the answer is "no"...
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.
FWIW, the API was already unsound before this, the comment just makes it slightly more obvious.
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.
OTOH If anything this allows less code than the previous API (since the old return type outlived 'static
), so I am confused why new warnings about unsoundness are coming up now.
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.
Ah I found #91957 (comment), it was collapsed.
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.
well, we already had unsound functions in widely used rustc internal APIs. This PR just makes it less easy to abuse, so the PR by itself is not making the situation worse.
The only real way to fix this is to start tracking lifetimes for it everywhere, which is a much bigger change.
If we got rid of the use case of running a compiler twice in the same process we could probably just never drop the interner and then everything would be sound?
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 don't get this argument. as_str
now produces something that you can't really pass around at all, where SymbolStr
had no lifetime binding it to Symbol
. Sure you can send Symbol
around, but you could do that before?
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.
The &str
is Send
and Sync
either way.
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.
The
&str
isSend
andSync
either way.
Hm yeah that is fair. One could even implement the new API based on the old one in safe code (by leaking some memory), as you showed.
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 think the only potential downside of the new API is that it makes it more annoying to unsoundly use it. Before, you would have had to store all the SymbolStrs somewhere, but now you just need the Symbols to come from a long-lived source.
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 think the only potential downside of the new API is that it makes it more annoying to unsoundly use it
Is that a downside? Sounds like a good thing to me 😄
I looked at this a while back. There are several hundred uses of
But there are plenty of uses where a local |
Can we add a lifetime to |
I expect that to be painful as |
What do you mean? Symbols can't be used before the interner is constructed or intern() will panic. |
Currently no context that could contain a reference to the interner is passed around at a lot of places. Instead the TLS is used to obain the interner. Adding a lifetime to |
@bors r+ Let's move this along, it's a strict improvement, even if it doesn't fix the unsoundness |
📌 Commit b1c934e has been approved by |
☀️ Test successful - checks-actions |
Tested on commit rust-lang/rust@a41a692. Direct link to PR: <rust-lang/rust#91957> 💔 miri on windows: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb). 💔 miri on linux: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb).
Finished benchmarking commit (a41a692): comparison url. Summary: This change led to moderate relevant mixed results 🤷 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression |
|
fn to_stable_hash_key(&self, _: &CTX) -> SymbolStr { | ||
self.as_str() | ||
fn to_stable_hash_key(&self, _: &CTX) -> String { | ||
self.as_str().to_string() |
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.
We could return &'static str
here. It would propagate the lifetime lie, but basically the same as before.
Remove `SymbolStr` This was originally proposed in rust-lang#74554 (comment). As well as removing the icky `SymbolStr` type, it allows the removal of a lot of `&` and `*` occurrences. Best reviewed one commit at a time. r? `@oli-obk`
This seems likely to be noise as a result of the issue tracked in rust-lang/rustc-perf#1126 -- marking as triaged, not something we should address directly. @rustbot label +perf-regression-triaged |
Remove `SymbolStr` This was originally proposed in rust-lang#74554 (comment). As well as removing the icky `SymbolStr` type, it allows the removal of a lot of `&` and `*` occurrences. Best reviewed one commit at a time. r? `@oli-obk`
Remove `SymbolStr` This was originally proposed in rust-lang#74554 (comment). As well as removing the icky `SymbolStr` type, it allows the removal of a lot of `&` and `*` occurrences. Best reviewed one commit at a time. r? `@oli-obk`
This was originally proposed in #74554 (comment). As well as removing the icky
SymbolStr
type, it allows the removal of a lot of&
and*
occurrences.Best reviewed one commit at a time.
r? @oli-obk