Change:
let mut all_families = HashSet::new(); let mut all_pointer_widths = HashSet::new(); <del> // Handle custom target specs, which are not included in `--print=all-target-specs-json`. if config.target.ends_with(".json") { targets.insert( config.target.clone(), serde_json::from_str(&rustc_output( config, &["--print=target-spec-json", "-Zunstable-options", "--target", &config.target], )) .unwrap(), ); </del> <ins> // If current target is not included in the `--print=all-target-specs-json` output, // we check whether it is a custom target from the user or a synthetic target from bootstrap. if !targets.contains_key(&config.target) { let mut envs: HashMap<String, String> = HashMap::new(); if let Ok(t) = std::env::var("RUST_TARGET_PATH") { envs.insert("RUST_TARGET_PATH".into(), t); } // This returns false only when the target is neither a synthetic target // nor a custom target from the user, indicating it is most likely invalid. if config.target.ends_with(".json") || !envs.is_empty() { targets.insert( config.target.clone(), serde_json::from_str(&rustc_output( config, &[ "--print=target-spec-json", "-Zunstable-options", "--target", &config.target, ], envs, )) .unwrap(), ); } </ins> } for (target, cfg) in targets.iter() {

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Getting error while building & testing rust 1.72 via the file in poky (cmd- and then )in poky environment. Until rust 1.70 I was able to build & test the rust sources successfully. But after updating to rust 1.72, there's an assertion failure causing the problem. The rust build fails as follows- The code at Build terminates as follows- <!-- Provide the most recent version this worked on, for example: It most recently worked on: --It most recently worked on Rust 1.70 and earlier versions <!-- Provide the version you are using that has the regression. --Rust 1.72 <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. .

--<details<summaryBacktrace</summary<pstack backtrace: 0: rustbeginunwind at 1: core::panicking::panicfmt at 2: core::panicking::assertfailedinner 3: core::panicking::assertfailed at 4: <bootstrap::compile::Assemble as bootstrap::builder::Step::run at 5: bootstrap::builder::Builder::ensure at 6: bootstrap::builder::Builder::compiler at 7: <bootstrap::test::Compiletest as bootstrap::builder::Step::run at 8: bootstrap::builder::Builder::ensure at 9: <bootstrap::test::UiFullDeps as bootstrap::builder::Step::run at 10: bootstrap::builder::Builder::ensure at 11: <bootstrap::test::UiFullDeps as bootstrap::builder::Step::makerun at 12: bootstrap::builder::StepDescription::mayberun at 13: bootstrap::builder::StepDescription::run at 14: bootstrap::builder::Builder::runstepdescriptions at 15: bootstrap::builder::Builder::executecli at 16: bootstrap::Build::build at 17: bootstrap::main at 18: core::ops::function::FnOnce::callonce at note: Some details are omitted, run with for a verbose backtrace. Build completed unsuccessfully in 0:00:20 <!-- modify labels: +regression-from-stable-to-{stable} -regression-untriaged
I believe is unrelated to the issue you're seeing, but I'm not sure.
Yeah, I guess the assertion failure is main cause. Why the two strings are different though? Until rust 1.70, I didn't this assertion failure(diff in i.e left: , and i.e right: ). When did git blame for these lines, found that this code was present (from 5 years i.e 2018)even in the earlier rust versions.
Adding useful labels for triaging label -I-prioritize +T-bootstrap -needs-triage
I couldn't reproduce this problem from the HEAD. The assertation passes as expected(on `./x test bootstrap --target=..), I also printed them out. ! The diff: ! Sorry for sharing the the outputs in the image format; the attempt was done inside of QEMU(Debian 11).

Thanks for checking But, my build shows following- Note- The targets are printed 3 times and the assertion fails in the 3rd call Moreover, if I bypass the assertion check and then build, why do the compiler asks to switch to nightly channel instead of continuing to stable? I am wondering how does it gets the option during the build since I did not not provide any such options. Let me know if I am missing something
Do you have a custom ?
The generated during the rust build is as follows- is the directory where I am building rust (using cmd in yocto poky sources)
iirc will give you the stable 1.68 compiler. If so, please remove and from your configuration, and use the beta compiler which will be downloaded from CI automatically during the bootstrapping.
Actually, will give stable 1.70 compiler(on master branch). I am manually upgrading the version to 1.72 and then getting the error in bootstrapping build. I didn't understand removing and using beta compiler from CI during bootstrapping. Can you enlighten me on it?
Still, this is wrong. Remove the following lines: from your configuration
Ok, will check and get back.
Thanks for the suggestion, but I can't modify . The same worked with previous rust versions. Actually, the build compiler fetches some (nightly build flag option) while building on the stable channel and it's recommended not to shift to nightly build. Is there any way I can find which flag causes this build failure and suppress that flag to proceed the build?
any updates?
Sorry, I somehow missed the notification. Bootstrap requires the immediate previous version to compile the next version, allowing it to handle unstable features. So there's an issue with your configuration (rustc and cargo), and you should find a way to update your config file. I'm surprised you didn't encounter an error message like: It might be more helpful to receive this error message at the beginning of the bootstrap process, I suppose.
Actually, I see that a nightly flag is passed by default in Rust 1.72 release notes More info- I suspect that is causing buid failure as seen in above comment here,
As I explained above, you cannot build upstream rustc with 1.70 anymore, even for non-poky environments.

You should either not set rustc manually in the build configuration or set it to the proper version.
Alternatively, if this doesn't help, you can build the 1.71 source with the 1.70 compiler (which you already have) and then use that compiler (which is version 1.71) to bootstrap version 1.72. You shouldn't make version jumps higher than one major version. We also have which is supposed to prevent that.
Actually, rust has now been upgraded to 1.74.1 version in poky. I had tested all the versions from 1.72 to 1.75(manually upgraded the rust version in my local poky source) and this error still persists. The above approach would not be sustainable since poky is frequently rebased with latest rust release versions. I suspect the following commits(in rust 1.72), related to setting up of target configs might cause these issues: Can you confirm this?
I don't think they are related. I had tested all the versions from 1.72 to 1.75(manually upgraded the rust version in my local poky source) and this error still persists. Then we have another problem. We are using a nightly feature here: so using could cause this failure, but only for tests with () mode. But reading the issue title you get the same error with too I guess?
The error is given out when the compiler is built internally during bootstrapping rust compiler by following command: If command is given explicitly in terminal, it works fine.
Can you apply the following patch and try testing it again? It should fix the problem you are facing.
Thanks for the above patch. I applied the patch but still the build fails is as follows:
That seems to be related with which you linked above. Will figure out the solution.
Yes, let me know if you need any more information. According to this and commits, the standard rust supported target specifications are obtained by and flags. And to handle custom target specs, which are not included in like poky target triples(x8664-poky-linux-gnu in this case) is passed on the file (in this case) and the target specs are parsed from it. This should actually add the custom target specs in the build process but I wonder why it doesn't do so... Note: I already exported path were the and file are located.

Could you please test the last two commits from when you have the time? The first commit should resolve the error of using the nightly flag with a stable compiler, and the second one should resolve the custom target issue.
Thanks. I will test with the given changes and revert back in a day(it's eod here).
I tested with the two commits and the errors of were not seen. Testing was completed for the test suites like ui, run-pass-valgrind, coverage, mir-opt, codegen, assembly, incremental. But, after that while coping libs to qemu emulator(we run the test suite on qemu), following io::copy panic was observed:
Can you try again? That seems like related with a TCP connection on (and we didn't change anything on remote-test tools since 2 years including and ).
Sure, I will check again and revert back.
I tested 4 to 5 times and got the same error each time.
70.0 and 1.72.0 remote-test tools are identical. I am not entirely sure what could go wrong. Is the workflow you doing is same as you did for 1.70 (the one was working before) ?
Yes, I am doing the same workflow in both cases. Note- I am testing it on rust 1.75 built in poky sources as mentioned in
Error says that the server is shutting down before generating/sending a response. Can you provide more details about the part of your workflow that uses remote-test tools?
We are using for ssh server. (I even tried with openssh and got the same panic failure.) You can find the complete workflow here: Details for remote-test tools:
Here we have an issue for the remote-test tool problem It seems to occur randomly in QEMU environments from time to time. Retrying seems to fix the issue for each occurrence. I will try to identify the root cause in the coming week.
PR will close this issue upon merging, as we have a separate issue () open for the other problem.
, Thanks for the help to fix this issue. Yeah, I this panic failures randomly after the test suite testing is completed starting from rust 1.71 version
Just remembered now, How do I handle the assertion mentioned in Until now I was by-passing the assertion check with the following changes: Should I continue with it?
I will add another commit to handle that.

update:
Do we still need the patch mentioned in along with the changes in PR? I think the three file changes in the PR should be sufficient, right?
PR is enough, you don't need any other patches.
Hi Did you get a chance to look at the .
Not yet
Are you able to run any tests with remote-test or does it give the error instantly at the beginning?
Yes, I am able to run the tests. The error is seen at
I meant sending tests and running in the qemu environment Is the error always the same, like this?
Yes, the error is always same.
Can you try this patch and tell me if it fixes the problem?
The patch does not fix the problem. Still, the same error is seen.
I was able to repreduce the error, but only by sending large files (and the patch I linked fixes it). Unfortunately I don't know your use case, and I can't invest time on for debugging or trying to reproduce the error. If you can't debug and fix the problem you get, I suggest you to give more context about your use case (configurations, commands, etc.) under the issue.
I got some work around for this, by excluding test suite and , tests and it works for . But, when I check for other cross-compiled targets(), the following lib failure is seen I am investigating the problem and will let you know if there are any updates.
That seems to be related with MirOptPanicAbortSyntheticTarget tests
Yes, the log says the same and the error was seen after test cases while building stage1 library artifacts. Meanwhile, I came across the following and have a doubt, As mentioned in , do we have to pass the flag to explicitly for the linker error in Earlier it was working without passing the flag explicitly.
Earlier we didn't have those tests, so they might require passing . You can try and see if that solves the problem.
Is there any way to handle this panic failure and make the tests run successfully?
You can add to your command to exclude mir-opt tests, then run to run mir-opt tests without .