-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Remove missing_tools config #107830
Remove missing_tools config #107830
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ozkanonur (or someone else) soon. Please see the contribution instructions for more information. |
Seems like changes made in this PR can't be passed in the pipelines currently. Please make sure all the pipelines gets passed successfully then we can review the changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please also squash your commits into single one?
d3b0e3a
to
1d3aac4
Compare
Done! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great! Just one more note before taking this into master.
Sure, the code looks better! |
95029aa
to
e679bd0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the review fixes!
@bors r+ rollup |
src/bootstrap/dist.rs
Outdated
.ensure(tool::RustAnalyzer { compiler, target }) | ||
.expect("rust-analyzer always builds"); | ||
.ensure(tool::RustAnalyzer { compiler, target }); | ||
// .expect("rust-analyzer always builds"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// .expect("rust-analyzer always builds"); |
source_type: SourceType::Submodule, | ||
extra_features: Vec::new(), | ||
allow_features: "", | ||
}); | ||
|
||
let build_cred = |name, path| { | ||
// These credential helpers are currently experimental. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment is now outdated.
if is_expected && !duplicates.is_empty() { | ||
eprintln!( | ||
"duplicate artifacts found when compiling a tool, this \ | ||
typically means that something was recompiled because \ | ||
a transitive dependency has different features activated \ | ||
than in a previous build:\n" | ||
); | ||
let (same, different): (Vec<_>, Vec<_>) = | ||
duplicates.into_iter().partition(|(_, cur, prev)| cur.2 == prev.2); | ||
if !same.is_empty() { | ||
eprintln!( | ||
"the following dependencies are duplicated although they \ | ||
have the same features enabled:" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This check was removed and not replaced with anything. That seems ok to me, we don't check this for the compiler itself, but wanted to note that explicitly so it's easy to find in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this being removed? The duplicate artifact check is important for ensuring that some dependencies are not unnecessarily built multiple times which can increase CI time. There's a large amount of infrastructure (particularly the workspace-hack) that this would unravel.
Also, these changes seem unrelated to removing missing-tools
. Is there a full description of what this PR is doing and why?
Remove missing_tools config Fixes rust-lang#79249 Request to check if run_cargo function has been appropriately modified and what changes need to be made
Something broke miri in the rollup ^ and I can't see any changes to miri itself, wondering if it was this one... |
⌛ Testing commit e679bd0 with merge efc262b6b3ce38809dde9031e3ef9289ab6eea55... |
So do I need to check this in a windows environment? Because my Linux compilation in local works just fine |
You can catch this error which is raised on linux environment.
I guess you run the Here is a little help for reproducing the error: config.toml that is used in failed pipeline changelog-seen = 2
[llvm]
static-libstdcpp = true
download-ci-llvm = false
[build]
extended = true
docs = false
print-step-timings = true
metrics = true
submodules = false
locked-deps = true
cargo-native-static = true
configure-args = ['--enable-extended', '--disable-docs']
[rust]
codegen-units-std = 1
remap-debuginfo = true
verbose-tests = true
dist-src = false
channel = "nightly"
debuginfo-level-std = 1
[dist]
compression-formats = ["xz"] command that is used in failed pipeline python3 x.py dist --host mips64el-unknown-linux-gnuabi64 --target mips64el-unknown-linux-gnuabi64 I tried this in ubuntu 22.04 container(because I can't get some of the required packages on my host system for this particular test) and I can confirm the exact same error raises. p.s: Most likely you can cut some of the parts from |
Thanks for the detailed steps! I will try it out |
From what I gather, it looks an issue with libffi-sys. It does not have any "mips" architecture defined in their Should I take it up with the maintainers of that repository asking to include mips and mips64 architecture? Specific error: error[E0425]: cannot find value `FFI_TRAMPOLINE_SIZE` in this scope
--> libffi-sys-rs/src/lib.rs:165:25
|
165 | pub tramp: [c_char; FFI_TRAMPOLINE_SIZE],
| ^^^^^^^^^^^^^^^^^^^ not found in this scope
|
note: these constants exist but are inaccessible
--> libffi-sys-rs/src/arch.rs:34:9 Note - The i686 windows build error is different and occurs in llvm build, which I am not able to debug yet |
@tharunsuresh-code where do you see that error? when building which tool? I don't see it in the github actions logs. |
oh no I'm wrong, I missed the miri error @ozkanonur pointed out. Sorry for the noise. @bors r- |
Yes, that seems like the right thing to do :) mips64-unknown-linux-gnuabi64 is "Tier 2 with Host Tools" so theoretically it should have all these tools available. cc @RalfJung @Mark-Simulacrum in case you have opinions on whether we should require Miri to be available on tier 2 targets; right now it's allowed to be missing. |
Thanks for pointing this out! I was trying to recreate the windows error and was having successful builds on my local windows machine 😅
Thanks, @jyn514! Created an issue -> tov/libffi-rs#67 |
No strong opinion. Assuming that it doesn't put much of a burden on Miri itself (which I doubt it does; adding support for more targets is tricky but I don't quite see how more host triples could be a problem), I'd leave this to the people that work on these targets. Though it seems you did run into libffi issues... we could totally disable FFI support on hosts not supported by libffi. However using Miri on those targets might require passing something like |
☔ The latest upstream changes (presumably #108268) made this pull request unmergeable. Please resolve the merge conflicts. |
Hmm, how could we do that without hard coding the target name? I worry that we'll disable FFI for the target, it will get supported upstream, and then it'll stay unsupported in miri indefinitely because we don't notice. |
Yeah we'd rely on someone reporting an issue to unlock this in Miri.
|
commit 1c808f18903f43ca6898a1452caf2481627b3d4e Merge: e679bd0 3200982 Author: Tharun Suresh <[email protected]> Date: Tue Feb 21 21:42:46 2023 +0530 Merge branch 'master' of https://github.com/rust-lang/rust commit e679bd0 Author: Tharun Suresh <[email protected]> Date: Sun Feb 12 09:37:41 2023 +0530 Remove missing_tools config rust-lang#107830
1684426
to
68431a6
Compare
@@ -696,7 +548,6 @@ impl Step for Cargo { | |||
tool: name, | |||
mode: Mode::ToolRustc, | |||
path, | |||
is_optional_tool: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is intentionally set to be optional. These credential programs had some risk that they wouldn't compile in all environments. I suppose if you can get CI to pass on all targets, then it should be ok. But I want to point out that this is a risky change, and I'm a little nervous about doing this.
@@ -202,7 +202,6 @@ pub struct Config { | |||
pub save_toolstates: Option<PathBuf>, | |||
pub print_step_timings: bool, | |||
pub print_step_rusage: bool, | |||
pub missing_tools: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing this will break anyone who has it set in their config. Is there a procedure for removing settings in such a way to alert people ahead-of-time that their config will no longer work?
if is_expected && !duplicates.is_empty() { | ||
eprintln!( | ||
"duplicate artifacts found when compiling a tool, this \ | ||
typically means that something was recompiled because \ | ||
a transitive dependency has different features activated \ | ||
than in a previous build:\n" | ||
); | ||
let (same, different): (Vec<_>, Vec<_>) = | ||
duplicates.into_iter().partition(|(_, cur, prev)| cur.2 == prev.2); | ||
if !same.is_empty() { | ||
eprintln!( | ||
"the following dependencies are duplicated although they \ | ||
have the same features enabled:" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this being removed? The duplicate artifact check is important for ensuring that some dependencies are not unnecessarily built multiple times which can increase CI time. There's a large amount of infrastructure (particularly the workspace-hack) that this would unravel.
Also, these changes seem unrelated to removing missing-tools
. Is there a full description of what this PR is doing and why?
☔ The latest upstream changes (presumably #108877) made this pull request unmergeable. Please resolve the merge conflicts. |
I will close this due to inactivity. Feel free to re-open it when you decide to work on this. |
tov/libffi-rs#67 was fixed, might be worth rechecking if miri builds on mips now |
MIPS is a tier 3 target now (#115238), so if this PR was blocked on "Miri should build on all tier 2 targets" then MIPS is not even a concern any more. |
Fixes #79249
Request to check if run_cargo function has been appropriately modified and what changes need to be made