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

fix a few errant Krate edges #35960

Merged
merged 12 commits into from
Sep 13, 2016
Merged

Conversation

nikomatsakis
Copy link
Contributor

Exploring the effect of small changes on syntex reuse, I discovered the following sources of unnecessary edges from Krate

r? @michaelwoerister


/// Tracks nodes that are forbidden to read/write; see
/// `DepGraph::forbid`. Used for debugging only.
forbidden: RefCell<Vec<DepNode<DefId>>>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this field also be #[cfg(debug_assertions)]-ed?

@michaelwoerister
Copy link
Member

Good catches both!
r=me with the nits and addressed.

@arielb1
Copy link
Contributor

arielb1 commented Aug 25, 2016

That said, the pattern that is used for the inherent impls map
is generally an anti-pattern (that is, holding the borrow lock for the
duration of using the contents)

I remember a similar place in coherence where I intentionally held the lock because someone (i.e., metadata loading) was inserting stuff to the list behind my back and I wanted to prevent that problem from recurring.

If nobody is supposed to mutate a list behind your back, holding a lock is the "safe" option - it can lead to more ICEs, but it can make your assumptions more visible.

@bors
Copy link
Contributor

bors commented Aug 27, 2016

☔ The latest upstream changes (presumably #36030) made this pull request unmergeable. Please resolve the merge conflicts.

@nikomatsakis nikomatsakis force-pushed the incr-comp-krate-edges branch from e08d4fb to 30c6f12 Compare August 31, 2016 19:19
@nikomatsakis
Copy link
Contributor Author

@bors r=mw

@bors
Copy link
Contributor

bors commented Aug 31, 2016

📌 Commit 30c6f12 has been approved by mw

@nikomatsakis
Copy link
Contributor Author

@bors r-

@nikomatsakis
Copy link
Contributor Author

nikomatsakis commented Sep 1, 2016

Warnings from travis look legit, even though I didn't see anything like that locally. Maybe I didn't run full tests on the latest commit or something.

@nikomatsakis
Copy link
Contributor Author

@bors r=mw

@bors
Copy link
Contributor

bors commented Sep 1, 2016

📌 Commit d287b7a has been approved by mw

@nikomatsakis
Copy link
Contributor Author

@bors r- // again the travis issue looks legit, and again I wonder why I am not seeing this locally!

@nikomatsakis
Copy link
Contributor Author

@nagisa @michaelwoerister

Should this field also be #[cfg(debug_assertions)]-ed?

The answer is sort of yes, but I wound up (see most recent commit) taking a different approach. In particular, the number of things that must have #[cfg] applied to them seemed to be growing at a kind of ridiculous rate, and moreover making a field #[cfg] is kind of annoying since you can't apply #[cfg] to the field in the struct literals. I really find code with #[cfg] sprinkled all about in random places quite hard to read -- I like it to be contained at one or two "pinch points" or not used at all, so in the most recent commit I removed the #[cfg(debug_assertions)] on the forbid method and replaced it with an assert!. But I'm not totally happy with that.

I'm not sure what's a better way to formulate the code here. It occurs to me now I could maybe make a mod forbid that is different if debug-assertions are disabled, so that at least all the cond code can be contained in one place, but it still feels like a lot for such a small thing.

@nikomatsakis
Copy link
Contributor Author

again the travis issue looks legit, and again I wonder why I am not seeing this locally!

Oh, I am dumb, it's because I'm building with debug-assertions enabled, of course!

@nikomatsakis
Copy link
Contributor Author

OK, so, I wound up implementing a better mechanism altogether. I'll push a few more commits shortly.

@nikomatsakis nikomatsakis force-pushed the incr-comp-krate-edges branch 2 times, most recently from 54f8bdf to cf7fd6b Compare September 2, 2016 15:55
@nikomatsakis
Copy link
Contributor Author

r? @michaelwoerister -- this fixes one add'l bug, and revamps the forbidden stuff into something more powerful.

@bors
Copy link
Contributor

bors commented Sep 5, 2016

☔ The latest upstream changes (presumably #36203) made this pull request unmergeable. Please resolve the merge conflicts.

The goal here is to avoid writing to the `inherent_impls` map from
within the general `Coherence` task, and instead write to it as we
visit. Writing to it from the Coherence task is actually an information
leak; it happened to be safe because Coherence read from
`DepNode::Krate`, but that was very coarse.

I removed the `Rc` here because, upon manual inspection, nobody clones
the data in this table, and it meant that we can accumulate the data in
place. That said, the pattern that is used for the inherent impls map
is *generally* an anti-pattern (that is, holding the borrow lock for the
duration of using the contents), so it'd probably be better to
clone (and I doubt that would be expensive -- how many inherent impls
does a typical type have?).
We touch the krate to adjust the maps, but we don't expose that data
widely.
It is useful to track down an errant edge that is being added.  This is
not a perfect mechanism, since it doesn't consider (e.g.) if we are
in an ignored task, but it's helpful enough for now.
It was duplicating information available elsewhere.
The shadow graph supercedes the existing code that checked for
reads/writes without an active task and now adds the ability
to filter for specific edges.
Across crates only, converting a def-id into its def-key or def-path was
considered a read. This caused spurious reads when computing the symbol
name for some item.
supplanted by RUST_FORBID_DEP_GRAPH_EDGE
I also added an `opt_def_path` so that we can deal with DefIds that are
missing a `DefPath` entry.
add licenses to shadow.rs

That first edge looks suspicious to you. So you set
`RUST_FORBID_DEP_GRAPH_EDGE` to `Hir&foo -> Collect&bar`, re-run, and
then observe the backtrace. Voila, bug fixed!
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! :)

@michaelwoerister
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Sep 12, 2016

📌 Commit 9ca5786 has been approved by michaelwoerister

@bors
Copy link
Contributor

bors commented Sep 13, 2016

⌛ Testing commit 9ca5786 with merge fa9d8cc...

bors added a commit that referenced this pull request Sep 13, 2016
…oerister

fix a few errant `Krate` edges

Exploring the effect of small changes on `syntex` reuse, I discovered the following sources of unnecessary edges from `Krate`

r? @michaelwoerister
@bors bors merged commit 9ca5786 into rust-lang:master Sep 13, 2016
@nikomatsakis nikomatsakis deleted the incr-comp-krate-edges branch October 3, 2016 14:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants