-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
incr.comp.: Hash more pieces of crate metadata to detect changes there. #41709
incr.comp.: Hash more pieces of crate metadata to detect changes there. #41709
Conversation
r? @arielb1 (rust_highfive has picked a reviewer for you, use r? to override) |
☔ The latest upstream changes (presumably #41717) made this pull request unmergeable. Please resolve the merge conflicts. |
1df872d
to
e3e4fde
Compare
e3e4fde
to
b973646
Compare
This should be ready for review now. One interesting thing in the changes here is that some |
I'm not sure if the errors on Travis are legit. I'll need to test locally. |
☔ The latest upstream changes (presumably #41773) made this pull request unmergeable. Please resolve the merge conflicts. |
b973646
to
b4b14eb
Compare
b4b14eb
to
6a5e2a5
Compare
All checks passing 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.
Gotta' few questions
// Hook up the codemap with a callback that allows it to register FileMap | ||
// accesses with the dependency graph. | ||
let cm_depgraph = dep_graph.clone(); | ||
let codemap_dep_tracking_callback = Box::new(move |filemap: &FileMap| { |
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 see why you were unhappy.
This makes me wonder: I think that eventually we probably want some way to "hide" data in the tcx (e.g., maybe using privacy), so that it is only exposed via query. This would be a way to have stuff like random bits in the session be treated universally by the red-green system.
(For stuff that's hashed initially, like command-line-options, we might want to make some public accessor methods I guess.)
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.
Yes, some refactorings like that would be nice.
} | ||
DepNode::FileMap(..) => { | ||
// These don't make a semantic | ||
// difference, filter them out. |
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'm not sure I follow this -- we use the SVH as a shorthand for "anything changed at all in this crate", you're saying that changes in the filemap shouldn't (e.g.) trigger downstream rebuilds when we are being conservative?
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 added this filter in order to appease the svh-related tests in run-pass. There are a few of them asserting that adding a comment (for example) does not change the SVH. These tests are still around from when the SVH tried to encode binary compatibility of crates, I think. The SVH has gotten a bit stricter since, but it's probably good that it's not too sensitive.
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.
Yeah, those tests seem pretty .. rotten. But ok.
src/libsyntax_pos/lib.rs
Outdated
@@ -491,6 +493,8 @@ impl Decodable for FileMap { | |||
Ok(FileMap { | |||
name: name, | |||
name_was_remapped: name_was_remapped, | |||
// `crate_of_origin` has to be set by the importer. | |||
crate_of_origin: 0xEFFF_FFFF, |
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.
Wait, what's this? :)
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.
Sorry :)
It's a number that is unlikely to ever be a valid CrateNum
. 0xFFFF_FFFF
is already taken for some other special purpose. I should introduce an INVALID_CRATE
const.
ok well r=me |
@bors r=nikomatsakis I added the |
📌 Commit 115602b has been approved by |
…ikomatsakis incr.comp.: Hash more pieces of crate metadata to detect changes there. This PR adds incr. comp. hashes for non-`Entry` pieces of data in crate metadata. The first part of it I like: `EntryBuilder` is refactored into the more generally applicable `IsolatedEncoder` which provides means of encoding something into metadata while also feeding the encoded data into an incr. comp. hash. We already did this for `Entry`, now we are doing it for various other pieces of data too, like the set of exported symbols and so on. The hashes generated there are persisted together with the per-`Entry` hashes and are also used for dep-graph dirtying the same way. The second part of the PR I'm not entirely happy with: In order to make sure that we don't forget registering a read to the new `DepNodes` introduced here, I added the `Tracked<T>` struct. This struct wraps a value and requires a `DepNode` when accessing the wrapped value. This makes it harder to overlook adding read edges in the right places and works just fine. However, crate metadata is already used in places where there is no `tcx` yet or even in places where no `cnum` has been assigned -- this makes it harder to apply this feature consistently or implement it ergonomically. The result is not too bad but there's a bit more code churn and a bit more opportunity to get something wrong than I would have liked. On the other hand, wrapping things in `Tracked<T>` already has revealed some bugs, so there's definitely some value in it. This is still a work in progress: - [x] I need to write some test cases. - [x] Accessing the CodeMap should really be dependency tracked too, especially with the new path-remapping feature. cc @nikomatsakis
☀️ Test successful - status-appveyor, status-travis |
…ookup, r=nikomatsakis ICH: Handle case of removed FileMaps. This PR fixes a bug introduced in rust-lang#41709 where removing a source file between compilation sessions would cause an ICE: https://travis-ci.org/rust-icci/crossbeam/jobs/230582234#L633 r? @nikomatsakis
…ookup, r=nikomatsakis ICH: Handle case of removed FileMaps. This PR fixes a bug introduced in rust-lang#41709 where removing a source file between compilation sessions would cause an ICE: https://travis-ci.org/rust-icci/crossbeam/jobs/230582234#L633 r? @nikomatsakis
…ookup, r=nikomatsakis ICH: Handle case of removed FileMaps. This PR fixes a bug introduced in rust-lang#41709 where removing a source file between compilation sessions would cause an ICE: https://travis-ci.org/rust-icci/crossbeam/jobs/230582234#L633 r? @nikomatsakis
#42101 |
This PR adds incr. comp. hashes for non-
Entry
pieces of data in crate metadata.The first part of it I like:
EntryBuilder
is refactored into the more generally applicableIsolatedEncoder
which provides means of encoding something into metadata while also feeding the encoded data into an incr. comp. hash. We already did this forEntry
, now we are doing it for various other pieces of data too, like the set of exported symbols and so on. The hashes generated there are persisted together with the per-Entry
hashes and are also used for dep-graph dirtying the same way.The second part of the PR I'm not entirely happy with: In order to make sure that we don't forget registering a read to the new
DepNodes
introduced here, I added theTracked<T>
struct. This struct wraps a value and requires aDepNode
when accessing the wrapped value. This makes it harder to overlook adding read edges in the right places and works just fine.However, crate metadata is already used in places where there is no
tcx
yet or even in places where nocnum
has been assigned -- this makes it harder to apply this feature consistently or implement it ergonomically. The result is not too bad but there's a bit more code churn and a bit more opportunity to get something wrong than I would have liked. On the other hand, wrapping things inTracked<T>
already has revealed some bugs, so there's definitely some value in it.This is still a work in progress:
cc @nikomatsakis