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

Take commandline arguments into account for incr. comp. #35340

Merged
merged 6 commits into from
Aug 15, 2016

Conversation

michaelwoerister
Copy link
Member

@michaelwoerister michaelwoerister commented Aug 4, 2016

Implements the conservative strategy described in #33727.

From now one, every time a new commandline option is added, one has to specify if it influences the incremental compilation cache. I've tried to implement this as automatic as possible: One just has to added either the [TRACKED] or the [UNTRACKED] marker next to the field. The Options, CodegenOptions, and DebuggingOptions definitions in session::config show plenty of examples.

The PR removes some cruft from session::config::Options, mostly unnecessary copies of flags also present in DebuggingOptions or CodeGenOptions in the same struct.

One notable removal is the cfg field that contained the values passed via --cfg commandline arguments. I chose to remove it because (1) its content is only a subset of what later is stored in hir::Crate::config and it's pretty likely that reading the cfgs from Options would not be what you wanted, and (2) we could not incorporate it into the dep-tracking hash of the Options struct because of how the test framework works, leaving us with a piece of untracked but vital data.

It is now recommended (just as before) to access the crate config via the krate() method in the HIR map.

Because the cfg field is not present in the Options struct any more, some methods in the CompilerCalls trait now take the crate config as an explicit parameter -- which might constitute a breaking change for plugin authors.

@rust-highfive
Copy link
Collaborator

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

use syntax::feature_gate::UnstableFeatures;
use syntax::parse::token::InternedString;

pub trait DepTrackingHash {
Copy link
Contributor

Choose a reason for hiding this comment

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

for some types, like DefPath, it'd be nice to have access to a tcx -- maybe add that as an argument? (of course they can get it through TLS too, but...)

Copy link
Member Author

Choose a reason for hiding this comment

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

This trait wasn't really meant to be used for something other than commandline arguments. However, if we decide that we want to use it for the ICH, that would certainly be possible.

@michaelwoerister michaelwoerister force-pushed the incr-comp-cli-args branch 2 times, most recently from f7af64e to a61e3ff Compare August 9, 2016 13:12
@michaelwoerister michaelwoerister added T-tools T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 9, 2016
@michaelwoerister
Copy link
Member Author

cc @nrc regarding CompilerCalls
cc @rust-lang/compiler @rust-lang/tools

@michaelwoerister michaelwoerister changed the title WIP: Take commandline arguments into account for incr. comp. Take commandline arguments into account for incr. comp. Aug 9, 2016
debuginfo: DebugInfoLevel [TRACKED],
lint_opts: Vec<(String, lint::Level)> [TRACKED],
lint_cap: Option<lint::Level> [TRACKED],
describe_lints: bool [UNTRACKED],
Copy link
Contributor

Choose a reason for hiding this comment

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

ps I love this [UNTRACKED] notation. Such a beautiful use of macros.

That said, this is a good example of the backwards compat sort of thing that macros are supposed to disallow. ;)

Copy link
Contributor

Choose a reason for hiding this comment

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

That said, this is a good example of the backwards compat sort of thing that macros are supposed to disallow. ;)

To clarify: imagine if types were extended to support T[...]; in that case, this would not parse anymore. Personally I think it's fine to leave it as is, but you could also add some separator token like ; or ,.

Copy link
Member Author

Choose a reason for hiding this comment

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

So it turns out that there's almost no common character allowed directly after a ty production :)
; and , probably would be allowed, but I think they are kind of misleading in this context. I'll just leave it the way it is. We can always change it easily if need be.

@michaelwoerister
Copy link
Member Author

@jonas-schievink might also be interested in this :)

($t:ty) => (
impl DepTrackingHash for Vec<$t> {
fn hash(&self, hasher: &mut SipHasher, error_format: ErrorOutputType) {
let mut elems = self.clone();
Copy link
Contributor

Choose a reason for hiding this comment

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

Oh man. I guess this is good but kind of sucks.

Copy link
Contributor

Choose a reason for hiding this comment

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

Not that I have a better idea =)

Copy link
Contributor

@nikomatsakis nikomatsakis Aug 9, 2016

Choose a reason for hiding this comment

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

ps seems mildly better to make a vector of indices and sort that:

let mut elems: Vec<_> = (0..self.len()).collect();
elems.sort_by(|i, j| self[i].cmp(&self[j]));
for (index, original_index) in elems.iter().enumerate() {
    self[original_index].hash();
}

Copy link
Member Author

Choose a reason for hiding this comment

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

Right :)
On the other hand, this code is executed exactly once for a tiny amount of data...

@nikomatsakis
Copy link
Contributor

r=me modulo nits and resolving the questions that @alexcrichton raised =)

@alexcrichton
Copy link
Member

I think all my points are resolved, I didn't realize that incrementality was only up to codegen and linking wasn't incremental. In that case I think this is good to go modulo taking native libraries into account which affect dllimport on MSVC

@michaelwoerister
Copy link
Member Author

michaelwoerister commented Aug 9, 2016

... and linking wasn't incremental

It will hopefully be so at least for gold users. But that has little to do with us (except for passing the right flags to the linker).

EDIT: And the MSVC linker can do that too, I think.

@michaelwoerister
Copy link
Member Author

@bors r=nikomatsakis

I think I've addressed all the nits.

@bors
Copy link
Contributor

bors commented Aug 9, 2016

📌 Commit 845e37b has been approved by nikomatsakis

@michaelwoerister
Copy link
Member Author

Regarding search_path and externs, we'll have to make sure that we detect changes in the library files themselves. Most of it should be caught be Metadata hashes already.

@bors
Copy link
Contributor

bors commented Aug 11, 2016

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

Commandline arguments influence whether incremental compilation
can use its compilation cache and thus their changes relative to
previous compilation sessions need to be taking into account. This
commit makes sure that one has to specify for every commandline
argument whether it influences incremental compilation or not.
.. and use it to purge the incremental compilation cache if necessary.
The 'cfg' in the Options struct is only the commandline-specified
subset of the crate configuration and it's almost always wrong to
read that instead of the CrateConfig in HIR crate node.
@michaelwoerister
Copy link
Member Author

OK, I could reproduce the test failure after a rebase (I guess it contained a change that bors' merge already had too), and it seems that there's something wrong with either macros or extern crates: If the main function in the test contains a println!() then the test fails:

module WorkProduct(WorkProductId("commandline_args")) is dirty because Hir("commandline_args/45447b7afbd5e544f7d0f1df0fccd26014d9850130abd3f020b89ff96b82079f-exe::main[0]") changed or was removed

Without the println! everything works as expected...

@michaelwoerister
Copy link
Member Author

@bors r=nikomatsakis

@bors
Copy link
Contributor

bors commented Aug 11, 2016

📌 Commit 67f19e5 has been approved by nikomatsakis

@bors
Copy link
Contributor

bors commented Aug 12, 2016

⌛ Testing commit 67f19e5 with merge eddcb8d...

bors added a commit that referenced this pull request Aug 12, 2016
…sakis

Take commandline arguments into account for incr. comp.

Implements the conservative strategy described in #33727.

From now one, every time a new commandline option is added, one has to specify if it influences the incremental compilation cache. I've tried to implement this as automatic as possible: One just has to added either the `[TRACKED]` or the `[UNTRACKED]` marker next to the field. The `Options`, `CodegenOptions`, and `DebuggingOptions` definitions in `session::config` show plenty of examples.

The PR removes some cruft from `session::config::Options`, mostly unnecessary copies of flags also present in `DebuggingOptions` or `CodeGenOptions` in the same struct.

One notable removal is the `cfg` field that contained the values passed via `--cfg` commandline arguments. I chose to remove it because (1) its content is only a subset of what later is stored in `hir::Crate::config` and it's pretty likely that reading the cfgs from `Options` would not be what you wanted, and (2) we could not incorporate it into the dep-tracking hash of the `Options` struct because of how the test framework works, leaving us with a piece of untracked but vital data.

It is now recommended (just as before) to access the crate config via the `krate()` method in the HIR map.

Because the `cfg` field is not present in the `Options` struct any more, some methods in the `CompilerCalls` trait now take the crate config as an explicit parameter -- which might constitute a breaking change for plugin authors.
@bors
Copy link
Contributor

bors commented Aug 12, 2016

💔 Test failed - auto-linux-64-debug-opt

@sophiajt
Copy link
Contributor

@bors retry

@michaelwoerister
Copy link
Member Author

@bors retry

This seems spurious ...

@eddyb
Copy link
Member

eddyb commented Aug 12, 2016

@alexcrichton Can we increase the timeout? And/or add RUSTFLAGS_STAGE2=-Ztime-passes to debug-opt.

@alexcrichton
Copy link
Member

I've not been watching bors over the past week or so, can we open an issue about this? It would be good to have all information related to this in one issue (I don't know the context here)

@michaelwoerister
Copy link
Member Author

See #35628 for the timeout.

@bors
Copy link
Contributor

bors commented Aug 13, 2016

⌛ Testing commit 67f19e5 with merge d6ae9eb...

@bors
Copy link
Contributor

bors commented Aug 13, 2016

💔 Test failed - auto-linux-64-debug-opt

@michaelwoerister
Copy link
Member Author

@bors retry

@bors
Copy link
Contributor

bors commented Aug 15, 2016

⌛ Testing commit 67f19e5 with merge f65d96f...

bors added a commit that referenced this pull request Aug 15, 2016
…sakis

Take commandline arguments into account for incr. comp.

Implements the conservative strategy described in #33727.

From now one, every time a new commandline option is added, one has to specify if it influences the incremental compilation cache. I've tried to implement this as automatic as possible: One just has to added either the `[TRACKED]` or the `[UNTRACKED]` marker next to the field. The `Options`, `CodegenOptions`, and `DebuggingOptions` definitions in `session::config` show plenty of examples.

The PR removes some cruft from `session::config::Options`, mostly unnecessary copies of flags also present in `DebuggingOptions` or `CodeGenOptions` in the same struct.

One notable removal is the `cfg` field that contained the values passed via `--cfg` commandline arguments. I chose to remove it because (1) its content is only a subset of what later is stored in `hir::Crate::config` and it's pretty likely that reading the cfgs from `Options` would not be what you wanted, and (2) we could not incorporate it into the dep-tracking hash of the `Options` struct because of how the test framework works, leaving us with a piece of untracked but vital data.

It is now recommended (just as before) to access the crate config via the `krate()` method in the HIR map.

Because the `cfg` field is not present in the `Options` struct any more, some methods in the `CompilerCalls` trait now take the crate config as an explicit parameter -- which might constitute a breaking change for plugin authors.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

7 participants