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

Rustflags in metadata #6503

Merged
merged 6 commits into from
Jan 4, 2019
Merged

Rustflags in metadata #6503

merged 6 commits into from
Jan 4, 2019

Conversation

Eh2406
Copy link
Contributor

@Eh2406 Eh2406 commented Dec 31, 2018

This is a small change that adds Rustflags to the Metadata. This means, for example, that if you do a plane build then build with "-C target-cpu=native", you will get 2 copies of the dependencies. Con, more space if you are changing Rustflags. Pro, not rebuilding all the dependencies when you switch back.

Suggested by https://internals.rust-lang.org/t/idea-cargo-global-binary-cache/9002/31

@dwijnand
Copy link
Member

dwijnand commented Jan 2, 2019

Nice doc addition too! The test seems overly complex for what it's testing (does it need dependencies? two of them?).

@Eh2406
Copy link
Contributor Author

Eh2406 commented Jan 2, 2019

The doc improvements are just a rewrite of how @ehuss explained it to me. I guess it is an example of "the best time to wright documentation is when you are new." I know what I did not understand and where I had looked, he new the anceer.

Good call on the test! (I was under the impression that this would only cache dependencies, hence adding them, I was wrong.)

@Eh2406
Copy link
Contributor Author

Eh2406 commented Jan 2, 2019

@ehuss dose that look better?

@matklad
Copy link
Member

matklad commented Jan 2, 2019

Cursory comment:

As I understand, there are two bits of information which track "dependencies": the hash of the file and the Fingerprint. Historically, Fingerprint tracked everything, and the hash tacked only subset of the things. I think the reasoning for this separation was to enable "automatic gc": if you change some flags, the file names stays the same, and so the old file gets overwritten.

However, I believe we've broken that "automatic gc" logic: if I today build a crate, and then add [profiles.dev] opt-level = 1 and build again, I get two sets of deps in target/debug/deps. With rust 1.10.0 I get only one set of dependencies.

So perhaps we can do something more radical here and just define the file hash to be exactly the fingerprint? That should simplify internal representation.

@Eh2406
Copy link
Contributor Author

Eh2406 commented Jan 2, 2019

I think there are still some important things that are not in metadata. The example @ehuss gave me (when I asked the same thing) was mtimes of files. If your example change was adding pub fn nop() {} to main then the "automatic gc" still works as you describe. It is reasonable to ask if we have gone to far in adding things to metadata. However, if we are imagining a global shared target_dir, then the problem of the "automatic gc" cleaning something we need for a different project became much more pressing.

@alexcrichton
Copy link
Member

I agree that we're not quite ready yet to merge these two hashes, the one for fingerprint calculation wasn't ever designed to be in the filename so it'd at least need a review to make sure it's suitable to always throw all of it in the filename. Incrementally adding more to the filename hash though I think is fine (like this PR)

@Eh2406
Copy link
Contributor Author

Eh2406 commented Jan 4, 2019

So what is this waiting on?

Copy link
Contributor

@ehuss ehuss left a comment

Choose a reason for hiding this comment

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

Seems fine to me. Worst case is that target gets a little more bloated. 👍 Alex?

@alexcrichton
Copy link
Member

@bors: r=ehuss

@bors
Copy link
Contributor

bors commented Jan 4, 2019

📌 Commit 6d24d57 has been approved by ehuss

@bors
Copy link
Contributor

bors commented Jan 4, 2019

⌛ Testing commit 6d24d57 with merge dcb4360...

bors added a commit that referenced this pull request Jan 4, 2019
Rustflags in metadata

This is a small change that adds Rustflags to the `Metadata`. This means, for example, that if you do a plane build then build with "-C target-cpu=native", you will get 2 copies of the dependencies. Con, more space if you are changing Rustflags. Pro, not rebuilding all the dependencies when you switch back.

Suggested by <https://internals.rust-lang.org/t/idea-cargo-global-binary-cache/9002/31>
@bors
Copy link
Contributor

bors commented Jan 4, 2019

☀️ Test successful - status-appveyor, status-travis
Approved by: ehuss
Pushing dcb4360 to master...

@bors bors merged commit 6d24d57 into rust-lang:master Jan 4, 2019
@Eh2406 Eh2406 deleted the RUSTFLAGS-in-Metadata branch January 7, 2019 21:13
bors added a commit to rust-lang/rust that referenced this pull request Jan 14, 2019
Update cargo

13 commits in 34320d212dca8cd27d06ce93c16c6151f46fcf2e..2b4a5f1f0bb6e13759e88ea9512527b0beba154f
2019-01-03 19:12:38 +0000 to 2019-01-12 04:13:12 +0000
- Add test for publish with [patch] + cleanup. (rust-lang/cargo#6544)
- Fix clippy warning (rust-lang/cargo#6546)
- Revert "Workaround by using yesterday's nightly" (rust-lang/cargo#6540)
- Adding feature-flags to `cargo publish` and `cargo package` (rust-lang/cargo#6453)
- Fix the Travis CI badge (rust-lang/cargo#6530)
- Add helpful text for Windows exceptions like Unix (rust-lang/cargo#6532)
- Report fix bugs to Rust instead of Cargo (rust-lang/cargo#6531)
- --{example,bin,bench,test} with no argument now lists all available targets (rust-lang/cargo#6505)
- Rebuild on mid build file modification (rust-lang/cargo#6484)
- Derive Clone for TomlDependency (rust-lang/cargo#6527)
- publish: rework the crates.io detection logic. (rust-lang/cargo#6525)
- avoid duplicates in ignore files (rust-lang/cargo#6521)
- Rustflags in metadata (rust-lang/cargo#6503)

r? @alexcrichton
@michaelwoerister
Copy link
Member

I find this change rather problematic. It keeps breaking things (path remapping, PGO, reproducible builds) because it goes against what rustc's -Cmetadata flag is intended for. -C metadata flag sets the crate disambiguator in rustc, which is only intended to disambiguate different versions of the same crate. Changing it will change every single symbol name the compiler generates for the crate. The disambiguator identifies that state of the source code, not the output artifacts of the compiler.

If there is some kind of caching of compiled artifacts, then that layer should take care of parsing RUSTFLAGS. Otherwise we'll just keep on adding exceptions.

@Eh2406
Copy link
Contributor Author

Eh2406 commented Sep 23, 2019

I am sorry this is making problems! The only problem where the report has come to my attention is the --remap-path-prefix, can you provide links to the discussion of the other problems you mentioned?

If there is some kind of caching of compiled artifacts

There definitely is, cargo has never rebuilt from scratch at every invocation.

@michaelwoerister
Copy link
Member

can you provide links to the discussion of the other problems you mentioned?

I just opened this issue: #7416

There definitely is, cargo has never rebuilt from scratch at every invocation.

I know. I think that improving caching via different metadata strings has problems though:

  • It leads to silent blow-up of the target directory where each small change to RUSTFLAGS creates its own crate graph of binaries, with probably quite a few of them "zombie" artifacts because the settings used during experimentation are not re-visited again.
  • It changes the name of output artifacts and symbols, something which other tools and scripts might rely on, especially when debugging something and wanting to inspect things that Cargo and rustc are generating.

I'm sorry for complaining about your feature, @Eh2406. You wrote such a nice doc string for it :)

@Eh2406
Copy link
Contributor Author

Eh2406 commented Sep 23, 2019

This PR was intended to help unlock work on the "zombie artifacts" problem, unfortunately that work has not yet progressed far enough to clean up the mess.

I do not object to a rewrite or removal if this is making more problems than it is worth.

alexcrichton added a commit to alexcrichton/cargo that referenced this pull request Sep 26, 2019
This is a moral revert of rust-lang#6503 but not a literal code revert. This
switches Cargo's behavior to avoid hashing compiler flags into
`-Cmetadata` since we've now had multiple requests of excluding flags
from the `-Cmetadata` hash: usage of `--remap-path-prefix` and PGO
options. These options should only affect how the compiler is
invoked/compiled and not radical changes such as symbol names, but
symbol names are changed based on `-Cmetadata`. Instead Cargo will still
track these flags internally, but only for reinvoking rustc, and not for
caching separately based on rustc flags.

Closes rust-lang#7416
bors added a commit that referenced this pull request Sep 30, 2019
Go back to not hashing `RUSTFLAGS` in `-Cmetadata`

This is a moral revert of #6503 but not a literal code revert. This
switches Cargo's behavior to avoid hashing compiler flags into
`-Cmetadata` since we've now had multiple requests of excluding flags
from the `-Cmetadata` hash: usage of `--remap-path-prefix` and PGO
options. These options should only affect how the compiler is
invoked/compiled and not radical changes such as symbol names, but
symbol names are changed based on `-Cmetadata`. Instead Cargo will still
track these flags internally, but only for reinvoking rustc, and not for
caching separately based on rustc flags.

Closes #7416
alexcrichton added a commit to alexcrichton/cargo that referenced this pull request Sep 30, 2019
This is a moral revert of rust-lang#6503 but not a literal code revert. This
switches Cargo's behavior to avoid hashing compiler flags into
`-Cmetadata` since we've now had multiple requests of excluding flags
from the `-Cmetadata` hash: usage of `--remap-path-prefix` and PGO
options. These options should only affect how the compiler is
invoked/compiled and not radical changes such as symbol names, but
symbol names are changed based on `-Cmetadata`. Instead Cargo will still
track these flags internally, but only for reinvoking rustc, and not for
caching separately based on rustc flags.

Closes rust-lang#7416
@ehuss ehuss added this to the 1.33.0 milestone Feb 6, 2022
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.

7 participants