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

Add Steal::is_stolen() #128815

Merged
merged 2 commits into from
Aug 9, 2024
Merged

Add Steal::is_stolen() #128815

merged 2 commits into from
Aug 9, 2024

Conversation

Nadrieril
Copy link
Member

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.

@rustbot
Copy link
Collaborator

rustbot commented Aug 8, 2024

r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 8, 2024
@jieyouxu
Copy link
Member

jieyouxu commented Aug 8, 2024

Looks reasonable to me. I think this is fine to add since rustc_data_structures is perma-unstable anyways right? Feel free to r=me after PR CI is green.

r? jieyouxu

@rustbot rustbot assigned jieyouxu and unassigned davidtwco Aug 8, 2024
@lqd
Copy link
Member

lqd commented Aug 8, 2024

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.

@cjgillot
Copy link
Contributor

cjgillot commented Aug 8, 2024

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>
@lcnr
Copy link
Contributor

lcnr commented Aug 9, 2024

@bors r=jieyouxu,lcnr

@bors
Copy link
Contributor

bors commented Aug 9, 2024

📌 Commit c966370 has been approved by jieyouxu,lcnr

It is now in the queue for this repository.

@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 Aug 9, 2024
@lcnr
Copy link
Contributor

lcnr commented Aug 9, 2024

@bors rollup=always

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Aug 9, 2024
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.
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 9, 2024
…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
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Aug 9, 2024
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 {
Copy link
Member

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_.

Copy link
Member Author

@Nadrieril Nadrieril Aug 9, 2024

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?

Copy link
Member

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.

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Aug 9, 2024
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.
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 9, 2024
…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
@bors bors merged commit 55329cc into rust-lang:master Aug 9, 2024
6 checks passed
@rustbot rustbot added this to the 1.82.0 milestone Aug 9, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 9, 2024
…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
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Aug 9, 2024
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.
@Nadrieril Nadrieril deleted the is_stolen branch August 10, 2024 10:03
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Aug 25, 2024
…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`
tgross35 added a commit to tgross35/rust that referenced this pull request Sep 5, 2024
…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`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Sep 5, 2024
…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``
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Sep 5, 2024
…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```
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Sep 5, 2024
…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`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Sep 5, 2024
…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``
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Sep 6, 2024
…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```
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Sep 6, 2024
…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````
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Sep 6, 2024
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``
lnicola pushed a commit to lnicola/rust-analyzer that referenced this pull request Sep 25, 2024
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``
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. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants