incr.comp.: Turn translation-related attributes into a query

[wesleywiser]

Fixes#47320

r? @michaelwoerister

[bors]

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

[michaelwoerister]

Thanks a lot for the very thorough PR, @wesleywiser! This makes a lot of things much nicer, I think, and probably more efficient too.

I added some comments where things need addressing. Just minor things though.

One thing left to do is caching the new query. Doing so is a bit more involved than it should be but it's pretty simple nonetheless:

1. Mark the query as cacheable like here:

   rust/src/librustc/ty/maps/config.rs

   Line 685 in e2746d8

   impl_disk_cacheable_query!(def_symbol_name, |_| true);

2. Allow for the query to be "refreshed" before writing back out to disk:

   rust/src/librustc/ty/maps/plumbing.rs

   Line 999 in e2746d8

   ContainsExternIndicator => contains_extern_indicator,

3. Actually write query results to disk, like here:

   rust/src/librustc/ty/maps/on_disk_cache.rs

   Line 220 in e2746d8

   encode_query_results::<contains_extern_indicator,_>(tcx, enc, qri)?;

[michaelwoerister]

This transformation isn't quite right: We need to always go through all of the ifs instead of chaining them via else. The previous version used else because the body of the for loop would be executed for each attribute individually.

[michaelwoerister]

You should be able to use the impl_stable_hash_for! macro, like here:

rust/src/librustc/ich/impls_hir.rs

Lines 144 to 149 in e2746d8

	impl_stable_hash_for!(enum hir::LifetimeName{
	Implicit,
	Underscore,
	Static,
	Name(name)
	});

[wesleywiser]

I tried that but the macro doesn't seem to like the path to that enum. Trying impl_stable_hash_for!(enum attr::InlineAttr { ... }) yields error[E0433]: failed to resolve. Did you mean syntax::attr?

but changing that to impl_stable_hash_for!(enum syntax::attr::InlineAttr { ... }) yields error[E0433]: failed to resolve. Use of undeclared type or module syntax. I'm not sure where to go from here...

[michaelwoerister]

We usually de-structure the data types in these implementations:

fnhash_stable<W:StableHasherResult>(&self,hcx:&mutStableHashingContext<'hir>,hasher:&mutStableHasher<W>){let hir::TransFnAttrs{
flags,
inline,} = *self;
flags.hash_stable(hcx, hasher);
inline.hash_stable(hcx, hasher);}

This way the code contains an exhaustive list of all fields and one cannot add or remove a field without also updating the impl here. It's a bit more verbose but it is a good way of letting the compiler help keeping things consistent.

[michaelwoerister]

We should be able to get rid of this attrs entirely.

[michaelwoerister]

Just saw that this is fixed in a later commit :)

[michaelwoerister]

This will probably need updating to Lrc too.

[bors]

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

[wesleywiser]

@michaelwoerister I resolved all of your feedback except for the issue I mentioned above with the impl_stable_hash_for!(enum) macro.

[michaelwoerister]

Yes, the macro is sometimes weird like that. With an absolute path (starting with ::syntax) it would probably work.

Thanks for fixing the nits! This looks great!

@bors try (I'd like to see if this affects performance)

@bors r+

[bors]

📌 Commit fbcdef5 has been approved by michaelwoerister

[bors]

⌛ Trying commit fbcdef582ec8be6eeef06d90463b226166d07d22 with merge b773dbdc99823e59733116d290342079ba1ca26e...

[bors]

☀️ Test successful - status-travis
State: approved=michaelwoerister try=True

[bors]

⌛ Testing commit fbcdef582ec8be6eeef06d90463b226166d07d22 with merge f24577a22bd6f638589992267b87d23fde912871...

[michaelwoerister]

@bors r-

[michaelwoerister]

I seems that bors has decided to push this PR to the front of the queue (and kill the one that was almost finished :(). If it goes through, we don't need a separate perf run. Note to myself: don't r+ and try at the same time...

[michaelwoerister]

@bors r+ (so that bors doesn't suddenly decide to not merge even though all tests have passed)

[bors]

📌 Commit fbcdef5 has been approved by michaelwoerister

[michaelwoerister]

@Mark-Simulacrum, could you do a perf run please?

[bors]

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

[Mark-Simulacrum]

Perf started for b773dbdc99823e59733116d290342079ba1ca26e.

[michaelwoerister]

Thanks, @Mark-Simulacrum!

Here's the link: http://perf.rust-lang.org/compare.html?start=1733a61141d125beb45587dd89d54cd4a01cdd5a&end=b773dbdc99823e59733116d290342079ba1ca26e&stat=instructions%3Au

Will this work? Are there build artifacts for the commit? The try-build was f24577a.

[wesleywiser]

Rebased

[Mark-Simulacrum]

There were two try builds, of which bors seems to think only one completed so I ran perf for that one. The URL you provided looks correct.

[michaelwoerister]

@bors r+ (after rebase)

[bors]

📌 Commit e0f7527 has been approved by michaelwoerister

[michaelwoerister]

Thanks, @Mark-Simulacrum, yes the link works now, it's all good :)

The numbers look good too! Pretty much in line with what I expected.

[wesleywiser]

@michaelwoerister Are you concerned about the style-servo and style-servo-opt max regressions?

[michaelwoerister]

No, that's fine, the clean-incremental benchmark for style-servo is not stable: #48184
There's something in there that causes a varying number of CGUs to be recompiled even if there is no change.

[wesleywiser]

Got it. Thanks!