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

Make untracked incr. comp. information inaccessible #90317

Open
3 of 5 tasks
cjgillot opened this issue Oct 26, 2021 · 19 comments
Open
3 of 5 tasks

Make untracked incr. comp. information inaccessible #90317

cjgillot opened this issue Oct 26, 2021 · 19 comments
Assignees
Labels
A-incr-comp Area: Incremental compilation E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@cjgillot
Copy link
Contributor

cjgillot commented Oct 26, 2021

When iterating over a collection, be it a Vec, a HashMap or an IndexMap, the order of items influences the value of the resulting hash: [a, b] and [b, a] have different hashes.

Meanwhile, there is some information we do not want to track. This is the case of the value of LocalDefId. Inserting a function in a file will change other functions LocalDefId, but it will not change their DefPathHash.

My concern is about controlling this information flow. In order to do that ToStableHashKey trait replaces the iteration order of the collection (which for hash maps is based on the key and the allocated memory capacity and should be irrelevant to the compilation), by the order of a stable hash key (the DefPathHash when the key is LocalDefId). By sorting the vectors by stable key, we manage the information flow.

Using IndexMap, the iteration order is the insertion order. Normally, this insertion order should only depend on tracked information obtained by depending on another query. For instance, a HIR visitor will create a query dependency on hir_owner_nodes, which hashes the in-code declaration order of functions. However, and this is my concern, the order of LocalDefId is freely available without using a query and is purposely untracked.

In order to make IndexMaps safe for incr. comp., we need to ensure untracked information is inaccessible.

Known issues:

  • Stop implementing PartialOrd and Ord on DefId;
  • Stop implementing PartialOrd, Ord and Idx for LocalDefId;
  • Stop implementing PartialOrd, Ord and Idx for LocalExpnId;
  • Stop implementing PartialOrd and Ord for SyntaxContext;
  • Enforce that UNTRACKED options are not accessed within a query.

Originally posted by @cjgillot in #90253 (comment)

@cjgillot cjgillot added A-incr-comp Area: Incremental compilation E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. E-help-wanted Call for participation: Help is requested to fix this issue. labels Oct 26, 2021
@pierwill
Copy link
Member

pierwill commented Oct 29, 2021

  • Stop implementing PartialOrd and Ord on DefId...

Can these items be done one at a time?

@cjgillot
Copy link
Contributor Author

Of course!

@pierwill
Copy link
Member

Will give this a go and see what happens. @rustbot claim

@pierwill
Copy link
Member

I started experimenting with LocalDefId. I wonder if the DefId work might end up being slightly less complex. 🤔

@pierwill
Copy link
Member

pierwill commented Nov 2, 2021

I wonder if the DefId work might end up being slightly less complex. 🤔

Update: No. 😄

@pierwill
Copy link
Member

pierwill commented Nov 3, 2021

Looks like removing Ord, PartialOrd for ExpnId and LocalExpnId might require changes to the macro rustc_index::newtype_index because of this line:

#[derive(Copy, PartialEq, Eq, Hash, PartialOrd, Ord, $($derives),*)]

@bjorn3
Copy link
Member

bjorn3 commented Nov 5, 2021

Track accesses to command-line options;
Track accesses to debugging command-line options.

Most of them are already "tracked" by discarding the entire incr comp cache if they change. The ones that aren't tracked are explicitly not tracked. See the UNTRACKED mentions in https://github.com/rust-lang/rust/blob/d22dd65835190278f315e06442614142653ec98f/compiler/rustc_session/src/options.rs A couple of them should be marked as TRACKED though I think.

@pierwill

This comment has been minimized.

@pierwill
Copy link
Member

pierwill commented Nov 11, 2021

@cjgillot It looks like rustc_span::hygiene::ExpnId does not implement Ord or PartialOrd. rustc_span::hygiene::LocalExpnId does implement ordering.

(So does rustc_middle::thir::ExprId. Is that related to this issue?)

@Aaron1011
Copy link
Member

I think it would be useful to enforce that UNTRACKED options are not accessed within a query (we could add a helper function to suppress the check, to allow for things like debug printing inside a query).

@pierwill

This comment has been minimized.

@pierwill
Copy link
Member

pierwill commented Dec 9, 2021

I think it would be useful to enforce that UNTRACKED options are not accessed within a query

@Aaron1011 Did you have someplace specific in mind for where to add this check?

@bjorn3
Copy link
Member

bjorn3 commented Dec 9, 2021

The fields could be made private and instead a getter for each option could be exposed that run dep_graph.assert_ignored(). And maybe also add an _untracked variant of each getter for cases where accessing it inside a query is fine, like for debug dumps.

@pierwill
Copy link
Member

pierwill commented Dec 9, 2021

The fields could be made private...

That is, fields of rustc_session::options::Options. For example:

search_paths: Vec<SearchPath> [UNTRACKED],
identify_regions: bool = (false, parse_bool, [UNTRACKED],

JohnTitor pushed a commit to JohnTitor/rust that referenced this issue Jun 24, 2022
This moves us a step closer to removing the `PartialOrd/`Ord` impls
for `DefId`. See rust-lang#90317
JohnTitor added a commit to JohnTitor/rust that referenced this issue Jun 24, 2022
…ochenkov

Remove (transitive) reliance on sorting by DefId in pretty-printer

This moves us a step closer to removing the `PartialOrd/`Ord` impls
for `DefId`. See rust-lang#90317
JohnTitor added a commit to JohnTitor/rust that referenced this issue Jun 24, 2022
…ochenkov

Remove (transitive) reliance on sorting by DefId in pretty-printer

This moves us a step closer to removing the `PartialOrd/`Ord` impls
for `DefId`. See rust-lang#90317
pierwill added a commit to pierwill/rust that referenced this issue Jul 5, 2022
This implementation is unused.

Helps with rust-lang#90317.
@Noratrieb Noratrieb added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Apr 5, 2023
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 21, 2024
Stop sorting via `DefId`s in region resolution

hopefully maintains the perf improvement from rust-lang#118824

works towards rust-lang#90317
@oli-obk oli-obk assigned oli-obk and unassigned pierwill Mar 21, 2024
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 21, 2024
Remove `DefId`'s `Partial/Ord` impls

work towards rust-lang#90317

based on rust-lang#122824 and rust-lang#122820

r? `@michaelwoerister`
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 22, 2024
…ichaelwoerister

Stop sorting via `DefId`s in region resolution

hopefully maintains the perf improvement from rust-lang#118824

works towards rust-lang#90317
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 22, 2024
Stop using `<DefId as Ord>` in various diagnostic situations

work towards rust-lang#90317

Reverts part of rust-lang#106281, as it sorts constants and that's problematic since it can contain `ParamConst`, which contains `DefId`s
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Mar 22, 2024
Rollup merge of rust-lang#122820 - oli-obk:no_ord_def_id, r=estebank

Stop using `<DefId as Ord>` in various diagnostic situations

work towards rust-lang#90317

Reverts part of rust-lang#106281, as it sorts constants and that's problematic since it can contain `ParamConst`, which contains `DefId`s
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 28, 2024
…rister

Remove `DefId`'s `Partial/Ord` impls

work towards rust-lang#90317

based on rust-lang#122824 and rust-lang#122820

r? `@michaelwoerister`
bors added a commit to rust-lang-ci/rust that referenced this issue Jun 21, 2024
Stop sorting `Span`s' `SyntaxContext`, as that is incompatible with incremental

work towards rust-lang#90317

Luckily no one actually needed these to be sorted, so it didn't even affect diagnostics. I'm guessing they'd have been sorted by creation time anyway, so it wouldn't really have mattered.

r? `@cjgillot`
github-actions bot pushed a commit to rust-lang/miri that referenced this issue Jun 23, 2024
Stop sorting `Span`s' `SyntaxContext`, as that is incompatible with incremental

work towards rust-lang/rust#90317

Luckily no one actually needed these to be sorted, so it didn't even affect diagnostics. I'm guessing they'd have been sorted by creation time anyway, so it wouldn't really have mattered.

r? `@cjgillot`
flip1995 pushed a commit to flip1995/rust-clippy that referenced this issue Jun 28, 2024
Stop sorting `Span`s' `SyntaxContext`, as that is incompatible with incremental

work towards rust-lang/rust#90317

Luckily no one actually needed these to be sorted, so it didn't even affect diagnostics. I'm guessing they'd have been sorted by creation time anyway, so it wouldn't really have mattered.

r? `@cjgillot`
lnicola pushed a commit to lnicola/rust-analyzer that referenced this issue Jul 11, 2024
Stop sorting `Span`s' `SyntaxContext`, as that is incompatible with incremental

work towards rust-lang/rust#90317

Luckily no one actually needed these to be sorted, so it didn't even affect diagnostics. I'm guessing they'd have been sorted by creation time anyway, so it wouldn't really have mattered.

r? `@cjgillot`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-incr-comp Area: Incremental compilation E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

8 participants