Fix syntax errors and support systems where sh isn't bash
#1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This also switches the order of the condition for the powershell check; according to https://learn.microsoft.com/en-us/powershell/scripting/learn/deep-dives/everything-about-null?view=powershell-7.2#checking-for-null that's more reliable.
albertlarsan68
pushed a commit
that referenced
this pull request
Dec 18, 2022
Speed up tidy This can be reviewed commit by commit since they contain separate optimizations. ``` # master $ taskset -c 0-5 hyperfine './x test tidy' Benchmark #1: ./x test tidy Time (mean ± σ): 4.857 s ± 0.064 s [User: 12.967 s, System: 2.014 s] Range (min … max): 4.779 s … 4.997 s 10 runs # PR $ taskset -c 0-5 hyperfine './x test tidy' Benchmark #1: ./x test tidy Time (mean ± σ): 3.672 s ± 0.035 s [User: 10.524 s, System: 2.029 s] Range (min … max): 3.610 s … 3.725 s 10 runs ```
albertlarsan68
pushed a commit
that referenced
this pull request
Jan 2, 2023
…aces, r=jyn514 Only deduplicate stack traces for good path bugs Fixes rust-lang#106267 Restores backtraces for `bug!` and `delay_span_bug` after rust-lang#106056. Only `delay_good_path_bug` needed its backtraces to be deduplicated, since it spits out the backtrace where it was created when it's being emitted. Before: ``` error: internal compiler error: /home/ubuntu/rust2/compiler/rustc_middle/src/ty/relate.rs:638:13: var types encountered in super_relate_consts: Const { ty: usize, kind: Infer(Var(_#0c)) } Const { ty: usize, kind: Param(N/#1) } note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: rustc 1.68.0-dev running on x86_64-unknown-linux-gnu query stack during panic: #0 [typeck] type-checking `<impl at /home/ubuntu/test.rs:7:1: 7:34>::trigger` #1 [typeck_item_bodies] type-checking all item bodies #2 [analysis] running analysis passes on this crate end of query stack error: aborting due to 2 previous errors ``` Hmm... that's a little bare. After: ``` error: internal compiler error: /home/ubuntu/rust2/compiler/rustc_middle/src/ty/relate.rs:638:13: var types encountered in super_relate_consts: Const { ty: usize, kind: Infer(Var(_#0c)) } Const { ty: usize, kind: Param(N/#1) } thread 'rustc' panicked at 'Box<dyn Any>', /home/ubuntu/rust2/compiler/rustc_errors/src/lib.rs:1599:9 stack backtrace: 0: 0x7ffb5b41bdd1 - std::backtrace_rs::backtrace::libunwind::trace::h26056f81198c6594 at /home/ubuntu/rust2/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5 1: 0x7ffb5b41bdd1 - std::backtrace_rs::backtrace::trace_unsynchronized::hacfb345a0c6d5bb1 at /home/ubuntu/rust2/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5 2: 0x7ffb5b41bdd1 - std::sys_common::backtrace::_print_fmt::h18ea6016ac8030f3 at /home/ubuntu/rust2/library/std/src/sys_common/backtrace.rs:65:5 3: 0x7ffb5b41bdd1 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::he35dde201d0c2d09 at /home/ubuntu/rust2/library/std/src/sys_common/backtrace.rs:44:22 4: 0x7ffb5b4a0308 - core::fmt::write::h094ad263467a053c at /home/ubuntu/rust2/library/core/src/fmt/mod.rs:1208:17 5: 0x7ffb5b43caf1 - std::io::Write::write_fmt::hd47b4e2324b4d9b7 at /home/ubuntu/rust2/library/std/src/io/mod.rs:1682:15 6: 0x7ffb5b41bbfa - std::sys_common::backtrace::_print::h43044162653a17fc at /home/ubuntu/rust2/library/std/src/sys_common/backtrace.rs:47:5 7: 0x7ffb5b41bbfa - std::sys_common::backtrace::print::hc8605da258fa5aeb at /home/ubuntu/rust2/library/std/src/sys_common/backtrace.rs:34:9 8: 0x7ffb5b3ffb87 - std::panicking::default_hook::{{closure}}::h9e37f23f75122a15 9: 0x7ffb5b3ff97b - std::panicking::default_hook::h602873a063f84da2 at /home/ubuntu/rust2/library/std/src/panicking.rs:286:9 10: 0x7ffb5be192b2 - <alloc[48d7b30605060536]::boxed::Box<dyn for<'a, 'b> core[672e3947e150d6c6]::ops::function::Fn<(&'a core[672e3947e150d6c6]::panic::panic_info::PanicInfo<'b>,), Output = ()> + core[672e3947e150d6c6]::marker::Send + core[672e3947e150d6c6]::marker::Sync> as core[672e3947e150d6c6]::ops::function::Fn<(&core[672e3947e150d6c6]::panic::panic_info::PanicInfo,)>>::call at /home/ubuntu/rust2/library/alloc/src/boxed.rs:2002:9 11: 0x7ffb5be192b2 - rustc_driver[f5b6d32d8905ecdd]::DEFAULT_HOOK::{closure#0}::{closure#0} at /home/ubuntu/rust2/compiler/rustc_driver/src/lib.rs:1204:17 12: 0x7ffb5b4000d3 - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::hfd13333ca953ae8e at /home/ubuntu/rust2/library/alloc/src/boxed.rs:2002:9 13: 0x7ffb5b4000d3 - std::panicking::rust_panic_with_hook::h45753e10264ebe7e at /home/ubuntu/rust2/library/std/src/panicking.rs:692:13 14: 0x7ffb5e8b3a63 - std[3330b4673efabfce]::panicking::begin_panic::<rustc_errors[1b15f4e7e49d1fd5]::ExplicitBug>::{closure#0} [... FRAMES INTENTIONALLY OMITTED BECAUSE GITHUB GOT ANGRY ...] 186: 0x7ffb5bea5554 - <std[3330b4673efabfce]::thread::Builder>::spawn_unchecked_::<rustc_interface[947706ead88047d0]::util::run_in_thread_pool_with_globals<rustc_interface[947706ead88047d0]::interface::run_compiler<core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>, rustc_driver[f5b6d32d8905ecdd]::run_compiler::{closure#1}>::{closure#0}, core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>>::{closure#0}::{closure#0}, core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>>::{closure#1} at /home/ubuntu/rust2/library/std/src/thread/mod.rs:549:30 187: 0x7ffb5bea5554 - <<std[3330b4673efabfce]::thread::Builder>::spawn_unchecked_<rustc_interface[947706ead88047d0]::util::run_in_thread_pool_with_globals<rustc_interface[947706ead88047d0]::interface::run_compiler<core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>, rustc_driver[f5b6d32d8905ecdd]::run_compiler::{closure#1}>::{closure#0}, core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>>::{closure#0}::{closure#0}, core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>>::{closure#1} as core[672e3947e150d6c6]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0} at /home/ubuntu/rust2/library/core/src/ops/function.rs:250:5 188: 0x7ffb5b433968 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::he8b26fc22c6f51ec at /home/ubuntu/rust2/library/alloc/src/boxed.rs:1988:9 189: 0x7ffb5b433968 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h5cf9cbe75a8c3ddc at /home/ubuntu/rust2/library/alloc/src/boxed.rs:1988:9 190: 0x7ffb5b41199c - std::sys::unix::thread::Thread::new::thread_start::h2d6dd4455e97d031 at /home/ubuntu/rust2/library/std/src/sys/unix/thread.rs:108:17 191: 0x7ffb5441b609 - start_thread 192: 0x7ffb5b282133 - clone 193: 0x0 - <unknown> note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: rustc 1.68.0-dev running on x86_64-unknown-linux-gnu query stack during panic: #0 [typeck] type-checking `<impl at /home/ubuntu/test.rs:7:1: 7:34>::trigger` #1 [typeck_item_bodies] type-checking all item bodies #2 [analysis] running analysis passes on this crate end of query stack error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0601`. ```
albertlarsan68
pushed a commit
that referenced
this pull request
Jan 28, 2023
…u-se
Implement `SpecOptionPartialEq` for `cmp::Ordering`
Noticed as I continue to explore options for having code using `partial_cmp` optimize better.
Before:
```llvm
; Function Attrs: mustprogress nofree nosync nounwind willreturn uwtable
define noundef zeroext i1 `@ordering_eq(i8` noundef %0, i8 noundef %1) unnamed_addr #0 {
start:
%2 = icmp eq i8 %0, 2
br i1 %2, label %bb1.i, label %bb3.i
bb1.i: ; preds = %start
%3 = icmp eq i8 %1, 2
br label %"_ZN55_$LT$T$u20$as$u20$core..option..SpecOptionPartialEq$GT$2eq17hb7e7beacecde585fE.exit"
bb3.i: ; preds = %start
%.not.i = icmp ne i8 %1, 2
%4 = icmp eq i8 %0, %1
%spec.select.i = and i1 %.not.i, %4
br label %"_ZN55_$LT$T$u20$as$u20$core..option..SpecOptionPartialEq$GT$2eq17hb7e7beacecde585fE.exit"
"_ZN55_$LT$T$u20$as$u20$core..option..SpecOptionPartialEq$GT$2eq17hb7e7beacecde585fE.exit": ; preds = %bb1.i, %bb3.i
%.0.i = phi i1 [ %3, %bb1.i ], [ %spec.select.i, %bb3.i ]
ret i1 %.0.i
}
```
After:
```llvm
; Function Attrs: mustprogress nofree norecurse nosync nounwind readnone willreturn uwtable
define noundef zeroext i1 `@ordering_eq(i8` noundef %0, i8 noundef %1) unnamed_addr #1 {
start:
%2 = icmp eq i8 %0, %1
ret i1 %2
}
```
(Which <https://alive2.llvm.org/ce/z/-rop5r> says LLVM *could* just do itself, but there's probably an issue already open for that problem from when this was originally looked at for `Option<NonZeroU8>` and friends.)
albertlarsan68
pushed a commit
that referenced
this pull request
Apr 19, 2023
There were a series of unfortunate interactions here. Here's an MCVE of the test this fixes (committed as `tests/ui/meta/no_std-extern-libc.rs`): ```rust #![crate_type = "lib"] #![no_std] #![feature(rustc_private)] extern crate libc; ``` Before, this would give an error about duplicate versions of libc: ``` error[E0464]: multiple candidates for `rlib` dependency `libc` found --> fake-test-src-base/allocator/no_std-alloc-error-handler-default.rs:15:1 | LL | extern crate libc; | ^^^^^^^^^^^^^^^^^^ | = note: candidate #1: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-358db1024b7d9957.rlib = note: candidate #2: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-ebc478710122a279.rmeta ``` Both these versions were downloaded from CI, but one came from the `rust-std` component and one came from `rustc-dev`: ``` ; tar -tf build/cache/f2d9a3d0771504f1ae776226a5799dcb4408a91a/rust-std-nightly-x86_64-unknown-linux-gnu.tar.xz | grep liblibc rust-std-nightly-x86_64-unknown-linux-gnu/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-68a2d9e195dd6ed2.rlib ; tar -tf build/cache/f2d9a3d0771504f1ae776226a5799dcb4408a91a/rustc-dev-nightly-x86_64-unknown-linux-gnu.tar.xz | grep liblibc rustc-dev-nightly-x86_64-unknown-linux-gnu/rustc-dev/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-f226c9fbdd92a0fd.rmeta ``` The fix was to only copy files from `rust-std` unless a Step explicitly requests for the `rustc-dev` components to be available by calling `builder.ensure(compile::Rustc)`. To avoid having to re-parse the `rustc-dev.tar.xz` tarball every time, which is quite slow, this adds a new `build/host/ci-rustc/.rustc-dev-contents` cache file which stores only the names of files we need to copy into the sysroot. This also allows reverting the hack in rust-lang#110121; now that we only copy rustc-dev on-demand, we can correctly add the `Rustc` check artifacts into the sysroot, so that this works correctly even when `download-rustc` is forced to `true`. --- See rust-lang#108767 (comment) for why `no_std` is required for the MCVE test to fail; it's complicated and not particularly important. Fixes rust-lang#108767.
albertlarsan68
pushed a commit
that referenced
this pull request
Apr 19, 2023
…tlarsan68 Fix no_std tests that load libc from the sysroot when download-rustc is enabled There were a series of unfortunate interactions here. Here's an MCVE of the test this fixes (committed as `tests/ui/meta/no_std-extern-libc.rs`): ```rust #![crate_type = "lib"] #![no_std] #![feature(rustc_private)] extern crate libc; ``` Before, this would give an error about duplicate versions of libc: ``` error[E0464]: multiple candidates for `rlib` dependency `libc` found --> fake-test-src-base/allocator/no_std-alloc-error-handler-default.rs:15:1 | LL | extern crate libc; | ^^^^^^^^^^^^^^^^^^ | = note: candidate #1: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-358db1024b7d9957.rlib = note: candidate #2: /home/gh-jyn514/rust/build/aarch64-unknown-linux-gnu/stage2/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-ebc478710122a279.rmeta ``` Both these versions were downloaded from CI, but one came from the `rust-std` component and one came from `rustc-dev`: ``` ; tar -tf build/cache/f2d9a3d0771504f1ae776226a5799dcb4408a91a/rust-std-nightly-x86_64-unknown-linux-gnu.tar.xz | grep liblibc rust-std-nightly-x86_64-unknown-linux-gnu/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-68a2d9e195dd6ed2.rlib ; tar -tf build/cache/f2d9a3d0771504f1ae776226a5799dcb4408a91a/rustc-dev-nightly-x86_64-unknown-linux-gnu.tar.xz | grep liblibc rustc-dev-nightly-x86_64-unknown-linux-gnu/rustc-dev/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-f226c9fbdd92a0fd.rmeta ``` The fix was to only copy files from `rust-std` unless a Step explicitly requests for the `rustc-dev` components to be available by calling `builder.ensure(compile::Rustc)`. To avoid having to re-parse the `rustc-dev.tar.xz` tarball every time, which is quite slow, this adds a new `build/host/ci-rustc/.rustc-dev-contents` cache file which stores only the names of files we need to copy into the sysroot. This also allows reverting the hack in rust-lang#110121; now that we only copy rustc-dev on-demand, we can correctly add the `Rustc` check artifacts into the sysroot, so that this works correctly even when `download-rustc` is forced to `true` and some tool depends on a local change to `compiler`. --- See rust-lang#108767 (comment) for why `no_std` is required for the MCVE test to fail; it's complicated and not particularly important. Fixes rust-lang#108767.
albertlarsan68
pushed a commit
that referenced
this pull request
May 1, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This also switches the order of the condition for the powershell check; according to https://learn.microsoft.com/en-us/powershell/scripting/learn/deep-dives/everything-about-null?view=powershell-7.2#checking-for-null that's more reliable.