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

Delete most of src/bootstrap/bin/rustc.rs #64316

Merged
merged 30 commits into from
Sep 24, 2019

Conversation

alexcrichton
Copy link
Member

This commit is an attempt at deleting as much of the rustc.rs shim that we have in rustbuild as possible. This shim predates RUSTFLAGS and is as old as rustbuild itself. While useful for quick hacks, it subverts Cargo's knowledge of rustc, makes it more difficult to build crates out of rustbuild, and is generally a hazard/code smell due to its architecture.

Additionally since the inception of this script we've added a number of features to Cargo such as profile overrides and RUSTFLAGS. This commit attempts to use these features of Cargo as much as possible to delete almost all of src/bootstrap/bin/rustc.rs. It's hoped that all new configuration for the Rust compiler can be codified in rustbuild rather than in this shim, allowing Cargo to have more knowledge about what's going on and making it a bit easier to reproduce builds outside of Cargo itself.

This was primarily motivated by some recent work on std-aware Cargo, and is also generally a cleanup of the script itself. This internally resulted in a number of refactorings of rustbuild itself, and the commits should be readable one-at-a-time instead of having to digest them all at once.

@rust-highfive

This comment has been minimized.

@rust-highfive
Copy link
Collaborator

⚠️ Warning ⚠️

  • These commits modify submodules.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 9, 2019
@alexcrichton
Copy link
Member Author

r? @Mark-Simulacrum

Copy link
Member

@Mark-Simulacrum Mark-Simulacrum left a comment

Choose a reason for hiding this comment

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

Overall looks excellent, left a few comments here and there though.

Edit: Looks like GH has deemed some of these outdated but I think not all of them are, I've resolved some of the comments below if they turned out to be replaced by a later one

src/bootstrap/builder.rs Outdated Show resolved Hide resolved
src/bootstrap/builder.rs Outdated Show resolved Hide resolved
src/bootstrap/builder.rs Show resolved Hide resolved
src/bootstrap/bin/rustc.rs Show resolved Hide resolved
src/bootstrap/builder.rs Outdated Show resolved Hide resolved
src/bootstrap/builder.rs Outdated Show resolved Hide resolved
src/bootstrap/builder.rs Outdated Show resolved Hide resolved
.arg("-Zconfig-profile");

let profile_var = |name: &str| {
let profile = if self.config.rust_optimize {
Copy link
Member

Choose a reason for hiding this comment

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

unrelated note: we should probably drop rust_optimize as a config flag entirely since there's no real point in a non-optimized build I imagine

src/bootstrap/compile.rs Show resolved Hide resolved
@rust-highfive

This comment has been minimized.

@Mark-Simulacrum Mark-Simulacrum added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 10, 2019
src/bootstrap/builder.rs Show resolved Hide resolved
src/bootstrap/builder.rs Outdated Show resolved Hide resolved
src/bootstrap/builder.rs Outdated Show resolved Hide resolved
src/bootstrap/builder.rs Outdated Show resolved Hide resolved
src/bootstrap/builder.rs Outdated Show resolved Hide resolved
src/bootstrap/builder.rs Show resolved Hide resolved
@rust-highfive

This comment has been minimized.

@Mark-Simulacrum
Copy link
Member

@alexcrichton I think this is ready to go now, unless I'm missing something? I've been waiting for a flip to S-waiting-on-review to do another pass if you think it's warranted.

@alexcrichton alexcrichton added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 16, 2019
@alexcrichton
Copy link
Member Author

@Mark-Simulacrum sorry, yes, this should be good to go

@bors

This comment has been minimized.

@@ -1,3 +1,5 @@
#![allow(rustc::default_hash_types)]
Copy link
Member

Choose a reason for hiding this comment

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

Could we switch these to rustc::internal like we do for libserialize/lib.rs?

@Mark-Simulacrum
Copy link
Member

Okay, r=me with last nit fixed (and looks like a rebase)

@Mark-Simulacrum
Copy link
Member

Let's also do

@bors rollup=never

@alexcrichton
Copy link
Member Author

@bors: r=Mark-Simulacrum

@bors

This comment has been minimized.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 16, 2019
@alexcrichton
Copy link
Member Author

@bors: r=Mark-Simulacrum

@bors
Copy link
Contributor

bors commented Sep 23, 2019

📌 Commit 1a8897f has been approved by Mark-Simulacrum

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 23, 2019
@bors
Copy link
Contributor

bors commented Sep 24, 2019

⌛ Testing commit 1a8897f with merge 7fdea7a...

bors added a commit that referenced this pull request Sep 24, 2019
Delete most of `src/bootstrap/bin/rustc.rs`

This commit is an attempt at deleting as much of the `rustc.rs` shim that we have in rustbuild as possible.  This shim predates `RUSTFLAGS` and is as old as rustbuild itself. While useful for quick hacks, it subverts Cargo's knowledge of `rustc`, makes it more difficult to build crates out of rustbuild, and is generally a hazard/code smell due to its architecture.

Additionally since the inception of this script we've added a number of features to Cargo such as profile overrides and `RUSTFLAGS`. This commit attempts to use these features of Cargo as much as possible to delete almost all of `src/bootstrap/bin/rustc.rs`. It's hoped that all new configuration for the Rust compiler can be codified in rustbuild rather than in this shim, allowing Cargo to have more knowledge about what's going on and making it a bit easier to reproduce builds outside of Cargo itself.

This was primarily motivated by some recent work on std-aware Cargo, and is also generally a cleanup of the script itself. This internally resulted in a number of refactorings of rustbuild itself, and the commits should be readable one-at-a-time instead of having to digest them all at once.
@bors
Copy link
Contributor

bors commented Sep 24, 2019

☀️ Test successful - checks-azure
Approved by: Mark-Simulacrum
Pushing 7fdea7a to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 24, 2019
@bors bors merged commit 1a8897f into rust-lang:master Sep 24, 2019
@alexcrichton alexcrichton deleted the cleanup-shim branch September 24, 2019 14:00
Manishearth added a commit to Manishearth/rust that referenced this pull request Jun 26, 2020
Support configurable deny-warnings for all in-tree crates.

This removes the hard-coded `deny(warnings)` on all in-tree tools, and allows it to be configured from the config.  This is just a personal preference, as I find `deny(warnings)` frustrating during development or doing small tests.

This also fixes some regressions in terms of warning handling.  Warnings used to be dependent on `SourceType`, but in rust-lang#64316 it was changed to be based on `Mode`. This means tools like rustdoc no longer used the same settings as the rest of the tree. It also made `SourceType` useless since the only thing it was used for was warnings. I think it would be better for everything in the tree to use the same settings.

Fixes rust-lang#64523
Manishearth added a commit to Manishearth/rust that referenced this pull request Jul 13, 2020
…-Simulacrum

Fix caching issue when building tools.

This fixes a problem with tool builds not being cached properly.

rust-lang#73297 changed it so that Clippy will participate in the "deny warnings" setting. Unfortunately this causes a problem because Clippy shares the build directory with other tools which do not participate in "deny warnings".  Because Cargo does not independently cache artifacts based on different RUSTFLAGS settings, it causes all the shared dependencies to get rebuilt if Clippy ever gets built.

The solution here is to stop using RUSTFLAGS, and just sneak the settings in through the rustc wrapper. Cargo won't know about the different settings, so it will not bust the cache. This should be safe since lint settings on dependencies are ignored. This is how things used to work in the past before rust-lang#64316.

Alternate solutions:
* Treat Clippy as a "submodule" and don't enforce warnings on it. This was the behavior before rust-lang#73297. The consequence is that if a warning sneaks into clippy, that the clippy maintainers will need to fix it when they sync clippy back to the clippy repo.
* Just deny warnings on all tools (removing the in-tree/submodule distinction). This is tempting, but with some issues (cc rust-lang#52336):
  * Adding or changing warnings in rustc can be difficult to land because tools have to be updated if they trip the warning. In practice, this isn't too bad.  Cargo (and rustfmt) already runs with `deny(warnings)`, so this has been the de-facto standard already (although they do not use the extra lints like `unused_lifetimes`).
* Teach Cargo to add flags to the workspace members, but not dependencies.
* Teach Cargo to add flags without fingerprinting them?
* Teach Cargo to independently cache different RUSTFLAGS artifacts (this was [reverted](rust-lang/cargo#7417) due to complications). This would also unnecessarily rebuild dependencies, but would avoid cache thrashing.
* Teach Cargo about lint settings.

Closes rust-lang#74016
Manishearth added a commit to Manishearth/rust that referenced this pull request Jul 13, 2020
…-Simulacrum

Fix caching issue when building tools.

This fixes a problem with tool builds not being cached properly.

rust-lang#73297 changed it so that Clippy will participate in the "deny warnings" setting. Unfortunately this causes a problem because Clippy shares the build directory with other tools which do not participate in "deny warnings".  Because Cargo does not independently cache artifacts based on different RUSTFLAGS settings, it causes all the shared dependencies to get rebuilt if Clippy ever gets built.

The solution here is to stop using RUSTFLAGS, and just sneak the settings in through the rustc wrapper. Cargo won't know about the different settings, so it will not bust the cache. This should be safe since lint settings on dependencies are ignored. This is how things used to work in the past before rust-lang#64316.

Alternate solutions:
* Treat Clippy as a "submodule" and don't enforce warnings on it. This was the behavior before rust-lang#73297. The consequence is that if a warning sneaks into clippy, that the clippy maintainers will need to fix it when they sync clippy back to the clippy repo.
* Just deny warnings on all tools (removing the in-tree/submodule distinction). This is tempting, but with some issues (cc rust-lang#52336):
  * Adding or changing warnings in rustc can be difficult to land because tools have to be updated if they trip the warning. In practice, this isn't too bad.  Cargo (and rustfmt) already runs with `deny(warnings)`, so this has been the de-facto standard already (although they do not use the extra lints like `unused_lifetimes`).
* Teach Cargo to add flags to the workspace members, but not dependencies.
* Teach Cargo to add flags without fingerprinting them?
* Teach Cargo to independently cache different RUSTFLAGS artifacts (this was [reverted](rust-lang/cargo#7417) due to complications). This would also unnecessarily rebuild dependencies, but would avoid cache thrashing.
* Teach Cargo about lint settings.

Closes rust-lang#74016
Manishearth added a commit to Manishearth/rust that referenced this pull request Jul 13, 2020
…-Simulacrum

Fix caching issue when building tools.

This fixes a problem with tool builds not being cached properly.

rust-lang#73297 changed it so that Clippy will participate in the "deny warnings" setting. Unfortunately this causes a problem because Clippy shares the build directory with other tools which do not participate in "deny warnings".  Because Cargo does not independently cache artifacts based on different RUSTFLAGS settings, it causes all the shared dependencies to get rebuilt if Clippy ever gets built.

The solution here is to stop using RUSTFLAGS, and just sneak the settings in through the rustc wrapper. Cargo won't know about the different settings, so it will not bust the cache. This should be safe since lint settings on dependencies are ignored. This is how things used to work in the past before rust-lang#64316.

Alternate solutions:
* Treat Clippy as a "submodule" and don't enforce warnings on it. This was the behavior before rust-lang#73297. The consequence is that if a warning sneaks into clippy, that the clippy maintainers will need to fix it when they sync clippy back to the clippy repo.
* Just deny warnings on all tools (removing the in-tree/submodule distinction). This is tempting, but with some issues (cc rust-lang#52336):
  * Adding or changing warnings in rustc can be difficult to land because tools have to be updated if they trip the warning. In practice, this isn't too bad.  Cargo (and rustfmt) already runs with `deny(warnings)`, so this has been the de-facto standard already (although they do not use the extra lints like `unused_lifetimes`).
* Teach Cargo to add flags to the workspace members, but not dependencies.
* Teach Cargo to add flags without fingerprinting them?
* Teach Cargo to independently cache different RUSTFLAGS artifacts (this was [reverted](rust-lang/cargo#7417) due to complications). This would also unnecessarily rebuild dependencies, but would avoid cache thrashing.
* Teach Cargo about lint settings.

Closes rust-lang#74016
Manishearth added a commit to Manishearth/rust that referenced this pull request Jul 13, 2020
…-Simulacrum

Fix caching issue when building tools.

This fixes a problem with tool builds not being cached properly.

rust-lang#73297 changed it so that Clippy will participate in the "deny warnings" setting. Unfortunately this causes a problem because Clippy shares the build directory with other tools which do not participate in "deny warnings".  Because Cargo does not independently cache artifacts based on different RUSTFLAGS settings, it causes all the shared dependencies to get rebuilt if Clippy ever gets built.

The solution here is to stop using RUSTFLAGS, and just sneak the settings in through the rustc wrapper. Cargo won't know about the different settings, so it will not bust the cache. This should be safe since lint settings on dependencies are ignored. This is how things used to work in the past before rust-lang#64316.

Alternate solutions:
* Treat Clippy as a "submodule" and don't enforce warnings on it. This was the behavior before rust-lang#73297. The consequence is that if a warning sneaks into clippy, that the clippy maintainers will need to fix it when they sync clippy back to the clippy repo.
* Just deny warnings on all tools (removing the in-tree/submodule distinction). This is tempting, but with some issues (cc rust-lang#52336):
  * Adding or changing warnings in rustc can be difficult to land because tools have to be updated if they trip the warning. In practice, this isn't too bad.  Cargo (and rustfmt) already runs with `deny(warnings)`, so this has been the de-facto standard already (although they do not use the extra lints like `unused_lifetimes`).
* Teach Cargo to add flags to the workspace members, but not dependencies.
* Teach Cargo to add flags without fingerprinting them?
* Teach Cargo to independently cache different RUSTFLAGS artifacts (this was [reverted](rust-lang/cargo#7417) due to complications). This would also unnecessarily rebuild dependencies, but would avoid cache thrashing.
* Teach Cargo about lint settings.

Closes rust-lang#74016
Manishearth added a commit to Manishearth/rust that referenced this pull request Jul 14, 2020
…-Simulacrum

Fix caching issue when building tools.

This fixes a problem with tool builds not being cached properly.

rust-lang#73297 changed it so that Clippy will participate in the "deny warnings" setting. Unfortunately this causes a problem because Clippy shares the build directory with other tools which do not participate in "deny warnings".  Because Cargo does not independently cache artifacts based on different RUSTFLAGS settings, it causes all the shared dependencies to get rebuilt if Clippy ever gets built.

The solution here is to stop using RUSTFLAGS, and just sneak the settings in through the rustc wrapper. Cargo won't know about the different settings, so it will not bust the cache. This should be safe since lint settings on dependencies are ignored. This is how things used to work in the past before rust-lang#64316.

Alternate solutions:
* Treat Clippy as a "submodule" and don't enforce warnings on it. This was the behavior before rust-lang#73297. The consequence is that if a warning sneaks into clippy, that the clippy maintainers will need to fix it when they sync clippy back to the clippy repo.
* Just deny warnings on all tools (removing the in-tree/submodule distinction). This is tempting, but with some issues (cc rust-lang#52336):
  * Adding or changing warnings in rustc can be difficult to land because tools have to be updated if they trip the warning. In practice, this isn't too bad.  Cargo (and rustfmt) already runs with `deny(warnings)`, so this has been the de-facto standard already (although they do not use the extra lints like `unused_lifetimes`).
* Teach Cargo to add flags to the workspace members, but not dependencies.
* Teach Cargo to add flags without fingerprinting them?
* Teach Cargo to independently cache different RUSTFLAGS artifacts (this was [reverted](rust-lang/cargo#7417) due to complications). This would also unnecessarily rebuild dependencies, but would avoid cache thrashing.
* Teach Cargo about lint settings.

Closes rust-lang#74016
Manishearth added a commit to Manishearth/rust that referenced this pull request Jul 14, 2020
…-Simulacrum

Fix caching issue when building tools.

This fixes a problem with tool builds not being cached properly.

rust-lang#73297 changed it so that Clippy will participate in the "deny warnings" setting. Unfortunately this causes a problem because Clippy shares the build directory with other tools which do not participate in "deny warnings".  Because Cargo does not independently cache artifacts based on different RUSTFLAGS settings, it causes all the shared dependencies to get rebuilt if Clippy ever gets built.

The solution here is to stop using RUSTFLAGS, and just sneak the settings in through the rustc wrapper. Cargo won't know about the different settings, so it will not bust the cache. This should be safe since lint settings on dependencies are ignored. This is how things used to work in the past before rust-lang#64316.

Alternate solutions:
* Treat Clippy as a "submodule" and don't enforce warnings on it. This was the behavior before rust-lang#73297. The consequence is that if a warning sneaks into clippy, that the clippy maintainers will need to fix it when they sync clippy back to the clippy repo.
* Just deny warnings on all tools (removing the in-tree/submodule distinction). This is tempting, but with some issues (cc rust-lang#52336):
  * Adding or changing warnings in rustc can be difficult to land because tools have to be updated if they trip the warning. In practice, this isn't too bad.  Cargo (and rustfmt) already runs with `deny(warnings)`, so this has been the de-facto standard already (although they do not use the extra lints like `unused_lifetimes`).
* Teach Cargo to add flags to the workspace members, but not dependencies.
* Teach Cargo to add flags without fingerprinting them?
* Teach Cargo to independently cache different RUSTFLAGS artifacts (this was [reverted](rust-lang/cargo#7417) due to complications). This would also unnecessarily rebuild dependencies, but would avoid cache thrashing.
* Teach Cargo about lint settings.

Closes rust-lang#74016
Manishearth added a commit to Manishearth/rust that referenced this pull request Jul 14, 2020
…-Simulacrum

Fix caching issue when building tools.

This fixes a problem with tool builds not being cached properly.

rust-lang#73297 changed it so that Clippy will participate in the "deny warnings" setting. Unfortunately this causes a problem because Clippy shares the build directory with other tools which do not participate in "deny warnings".  Because Cargo does not independently cache artifacts based on different RUSTFLAGS settings, it causes all the shared dependencies to get rebuilt if Clippy ever gets built.

The solution here is to stop using RUSTFLAGS, and just sneak the settings in through the rustc wrapper. Cargo won't know about the different settings, so it will not bust the cache. This should be safe since lint settings on dependencies are ignored. This is how things used to work in the past before rust-lang#64316.

Alternate solutions:
* Treat Clippy as a "submodule" and don't enforce warnings on it. This was the behavior before rust-lang#73297. The consequence is that if a warning sneaks into clippy, that the clippy maintainers will need to fix it when they sync clippy back to the clippy repo.
* Just deny warnings on all tools (removing the in-tree/submodule distinction). This is tempting, but with some issues (cc rust-lang#52336):
  * Adding or changing warnings in rustc can be difficult to land because tools have to be updated if they trip the warning. In practice, this isn't too bad.  Cargo (and rustfmt) already runs with `deny(warnings)`, so this has been the de-facto standard already (although they do not use the extra lints like `unused_lifetimes`).
* Teach Cargo to add flags to the workspace members, but not dependencies.
* Teach Cargo to add flags without fingerprinting them?
* Teach Cargo to independently cache different RUSTFLAGS artifacts (this was [reverted](rust-lang/cargo#7417) due to complications). This would also unnecessarily rebuild dependencies, but would avoid cache thrashing.
* Teach Cargo about lint settings.

Closes rust-lang#74016
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Sep 16, 2020
…-Simulacrum

Fix generating rustc docs with non-default lib directory.

If `libdir` is set in `config.toml`, then the tool to generate the rustc docs was unable to run `rustc` because it could not find the shared libraries. The solution is to set the dylib search path to include the libdir.

I changed the API of `add_rustc_lib_path` to take `Command` instead of `Cargo` to try to share the code in several places. This is how it worked before rust-lang#64316, and I think this still retains the spirit of that change.

Fixes rust-lang#76702
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Sep 16, 2020
…-Simulacrum

Fix generating rustc docs with non-default lib directory.

If `libdir` is set in `config.toml`, then the tool to generate the rustc docs was unable to run `rustc` because it could not find the shared libraries. The solution is to set the dylib search path to include the libdir.

I changed the API of `add_rustc_lib_path` to take `Command` instead of `Cargo` to try to share the code in several places. This is how it worked before rust-lang#64316, and I think this still retains the spirit of that change.

Fixes rust-lang#76702
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Apr 20, 2023
…, r=albertlarsan68

 fix out-of-date comment about rpath in bootstrap

in rust-lang#64316   (rust-lang@1bec962),  the `RUSTC_RPATH`  enviroment variables had been removed , but the comments about the rpath still keep it
this PR fix it  to avoid misunstanding
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants