-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Add Steal::is_stolen()
#128815
Add Steal::is_stolen()
#128815
Conversation
r? @davidtwco rustbot has assigned @davidtwco. Use |
Looks reasonable to me. I think this is fine to add since r? jieyouxu |
Sometimes people remove unused code even if it's pub, adding a comment explaining why it exists would help ensure that it's not deleted. The PR's description would work fine for this comment. |
Note that this method must not be used from inside a rustc query, as that would carry untracked information across queries. Could you add a comment and eventually tweak one of the internal lints? |
Co-authored-by: lcnr <rust@lcnr.de>
@bors r=jieyouxu,lcnr |
@bors rollup=always |
Add `Steal::is_stolen()` Writers of rustc drivers (such as myself) often encounter stealing issues. It is currently impossible to gracefully handle them. This PR adds a `Steal::is_stolen()` function for that purpose.
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#128742 (miri: make vtable addresses not globally unique) - rust-lang#128815 (Add `Steal::is_stolen()`) - rust-lang#128859 (Fix the name of signal 19 in library/std/src/sys/pal/unix/process/process_unix/tests.rs for mips/sparc linux) - rust-lang#128864 (Use `SourceMap::end_point` instead of `- BytePos(1)` in arg removal suggestion) - rust-lang#128865 (Ensure let stmt compound assignment removal suggestion respect codepoint boundaries) - rust-lang#128874 (Disable verbose bootstrap command failure logging by default) r? `@ghost` `@rustbot` modify labels: rollup
Add `Steal::is_stolen()` Writers of rustc drivers (such as myself) often encounter stealing issues. It is currently impossible to gracefully handle them. This PR adds a `Steal::is_stolen()` function for that purpose.
/// | ||
/// This should not be used within rustc as it leaks information not tracked | ||
/// by the query system, breaking incremental compilation. | ||
pub fn is_stolen(&self) -> bool { |
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.
Maybe call it untracked_is_stolen()
? We tend to prefix methods that don't properly go through the incr comp system with untracked_
.
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 didn't know that. I was in the process of adding an internal lint to warn about uses of functions like this as was suggested ^^. Do you think the lint would be worth 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.
There are probably other methods which don't have the untracked_
prefix. Either renaming those or adding a lint for them would be beneficial I think.
Add `Steal::is_stolen()` Writers of rustc drivers (such as myself) often encounter stealing issues. It is currently impossible to gracefully handle them. This PR adds a `Steal::is_stolen()` function for that purpose.
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#128815 (Add `Steal::is_stolen()`) - rust-lang#128817 (VxWorks code refactored ) - rust-lang#128822 (add `builder-config` into tarball sources) - rust-lang#128838 (rustdoc: do not run doctests with invalid langstrings) - rust-lang#128852 (use stable sort to sort multipart diagnostics) - rust-lang#128859 (Fix the name of signal 19 in library/std/src/sys/pal/unix/process/process_unix/tests.rs for mips/sparc linux) - rust-lang#128864 (Use `SourceMap::end_point` instead of `- BytePos(1)` in arg removal suggestion) - rust-lang#128865 (Ensure let stmt compound assignment removal suggestion respect codepoint boundaries) - rust-lang#128874 (Disable verbose bootstrap command failure logging by default) r? `@ghost` `@rustbot` modify labels: rollup
…llaumeGomez Rollup of 8 pull requests Successful merges: - rust-lang#128815 (Add `Steal::is_stolen()`) - rust-lang#128822 (add `builder-config` into tarball sources) - rust-lang#128838 (rustdoc: do not run doctests with invalid langstrings) - rust-lang#128852 (use stable sort to sort multipart diagnostics) - rust-lang#128859 (Fix the name of signal 19 in library/std/src/sys/pal/unix/process/process_unix/tests.rs for mips/sparc linux) - rust-lang#128864 (Use `SourceMap::end_point` instead of `- BytePos(1)` in arg removal suggestion) - rust-lang#128865 (Ensure let stmt compound assignment removal suggestion respect codepoint boundaries) - rust-lang#128874 (Disable verbose bootstrap command failure logging by default) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#128815 - Nadrieril:is_stolen, r=jieyouxu,lcnr Add `Steal::is_stolen()` Writers of rustc drivers (such as myself) often encounter stealing issues. It is currently impossible to gracefully handle them. This PR adds a `Steal::is_stolen()` function for that purpose.
…llot Add an internal lint that warns when accessing untracked data Some methods access data that is not tracked by the query system and should be used with caution. As suggested in rust-lang#128815 (comment), in this PR I propose a lint (modeled on the `potential_query_instability` lint) that warns when using some specially-annotatted functions. I can't tell myself if this lint would be that useful, compared to renaming `Steal::is_stolen` to `is_stolen_untracked`. This would depend on whether there are other functions we'd want to lint like this. So far it seems they're called `*_untracked`, which may be clear enough. r? `@oli-obk`
…llot Add an internal lint that warns when accessing untracked data Some methods access data that is not tracked by the query system and should be used with caution. As suggested in rust-lang#128815 (comment), in this PR I propose a lint (modeled on the `potential_query_instability` lint) that warns when using some specially-annotatted functions. I can't tell myself if this lint would be that useful, compared to renaming `Steal::is_stolen` to `is_stolen_untracked`. This would depend on whether there are other functions we'd want to lint like this. So far it seems they're called `*_untracked`, which may be clear enough. r? `@oli-obk`
…llot Add an internal lint that warns when accessing untracked data Some methods access data that is not tracked by the query system and should be used with caution. As suggested in rust-lang#128815 (comment), in this PR I propose a lint (modeled on the `potential_query_instability` lint) that warns when using some specially-annotatted functions. I can't tell myself if this lint would be that useful, compared to renaming `Steal::is_stolen` to `is_stolen_untracked`. This would depend on whether there are other functions we'd want to lint like this. So far it seems they're called `*_untracked`, which may be clear enough. r? ``@oli-obk``
…llot Add an internal lint that warns when accessing untracked data Some methods access data that is not tracked by the query system and should be used with caution. As suggested in rust-lang#128815 (comment), in this PR I propose a lint (modeled on the `potential_query_instability` lint) that warns when using some specially-annotatted functions. I can't tell myself if this lint would be that useful, compared to renaming `Steal::is_stolen` to `is_stolen_untracked`. This would depend on whether there are other functions we'd want to lint like this. So far it seems they're called `*_untracked`, which may be clear enough. r? ```@oli-obk```
…llot Add an internal lint that warns when accessing untracked data Some methods access data that is not tracked by the query system and should be used with caution. As suggested in rust-lang#128815 (comment), in this PR I propose a lint (modeled on the `potential_query_instability` lint) that warns when using some specially-annotatted functions. I can't tell myself if this lint would be that useful, compared to renaming `Steal::is_stolen` to `is_stolen_untracked`. This would depend on whether there are other functions we'd want to lint like this. So far it seems they're called `*_untracked`, which may be clear enough. r? `@oli-obk`
…llot Add an internal lint that warns when accessing untracked data Some methods access data that is not tracked by the query system and should be used with caution. As suggested in rust-lang#128815 (comment), in this PR I propose a lint (modeled on the `potential_query_instability` lint) that warns when using some specially-annotatted functions. I can't tell myself if this lint would be that useful, compared to renaming `Steal::is_stolen` to `is_stolen_untracked`. This would depend on whether there are other functions we'd want to lint like this. So far it seems they're called `*_untracked`, which may be clear enough. r? ``@oli-obk``
…llot Add an internal lint that warns when accessing untracked data Some methods access data that is not tracked by the query system and should be used with caution. As suggested in rust-lang#128815 (comment), in this PR I propose a lint (modeled on the `potential_query_instability` lint) that warns when using some specially-annotatted functions. I can't tell myself if this lint would be that useful, compared to renaming `Steal::is_stolen` to `is_stolen_untracked`. This would depend on whether there are other functions we'd want to lint like this. So far it seems they're called `*_untracked`, which may be clear enough. r? ```@oli-obk```
…llot Add an internal lint that warns when accessing untracked data Some methods access data that is not tracked by the query system and should be used with caution. As suggested in rust-lang#128815 (comment), in this PR I propose a lint (modeled on the `potential_query_instability` lint) that warns when using some specially-annotatted functions. I can't tell myself if this lint would be that useful, compared to renaming `Steal::is_stolen` to `is_stolen_untracked`. This would depend on whether there are other functions we'd want to lint like this. So far it seems they're called `*_untracked`, which may be clear enough. r? ````@oli-obk````
Rollup merge of rust-lang#128919 - Nadrieril:lint-query-leaks, r=cjgillot Add an internal lint that warns when accessing untracked data Some methods access data that is not tracked by the query system and should be used with caution. As suggested in rust-lang#128815 (comment), in this PR I propose a lint (modeled on the `potential_query_instability` lint) that warns when using some specially-annotatted functions. I can't tell myself if this lint would be that useful, compared to renaming `Steal::is_stolen` to `is_stolen_untracked`. This would depend on whether there are other functions we'd want to lint like this. So far it seems they're called `*_untracked`, which may be clear enough. r? ``@oli-obk``
Add an internal lint that warns when accessing untracked data Some methods access data that is not tracked by the query system and should be used with caution. As suggested in rust-lang/rust#128815 (comment), in this PR I propose a lint (modeled on the `potential_query_instability` lint) that warns when using some specially-annotatted functions. I can't tell myself if this lint would be that useful, compared to renaming `Steal::is_stolen` to `is_stolen_untracked`. This would depend on whether there are other functions we'd want to lint like this. So far it seems they're called `*_untracked`, which may be clear enough. r? ``@oli-obk``
Writers of rustc drivers (such as myself) often encounter stealing issues. It is currently impossible to gracefully handle them. This PR adds a
Steal::is_stolen()
function for that purpose.