| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 7 pull requests
Successful merges:
- #109395 (Fix issue when there are multiple candidates for edit_distance_with_substrings)
- #109755 (Implement support for `GeneratorWitnessMIR` in new solver)
- #109782 (Don't leave a comma at the start of argument list when removing arguments)
- #109977 (rustdoc: avoid including line numbers in Google SERP snippets)
- #109980 (Derive String's PartialEq implementation)
- #109984 (Remove f32 & f64 from MemDecoder/MemEncoder)
- #110004 (add `dont_check_failure_status` option in the compiler test)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
add `dont_check_failure_status` option in the compiler test
Sometimes the compiler triggers one ice while processing another ice. This will cause a recursive panic and go to [`sys::abort_internal()`](https://github.com/rust-lang/rust/blob/master/library/std/src/panicking.rs#L675), which generates an unfixed exit code. So I think we need an option to allow these use cases to generate different exit codes
Updates #75760
cc #95134
For example, when set `parallel_compiler = true`, issue-95134 will ice in `report_ice` since it try to print the query stack. Below is the brief error message:
```
failures:
---- [ui] tests\ui\recursion\issue-95134.rs stdout ----
error: Error: expected failure status (Some(101)) but received status Some(-1073740791).
status: exit code: 0xc0000409
command: PATH="D:\rust-backup\parallel_rust\rust-para\build\x86_64-pc-windows-msvc\stage1\bin;C:\Program Files (x86)\Windows Kits\10\bin\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64;D:\rust-backup\parallel_rust\rust-para\build\x86_64-pc-windows-msvc\stage0-bootstrap-tools\x86_64-pc-windows-msvc\release\deps;D:\rust-backup\parallel_rust\rust-para\build\x86_64-pc-windows-msvc\stage0\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.4\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.4\libnvvp;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\TortoiseGit\bin;C:\Program Files\CMake\bin;C:\Program Files (x86)\GnuWin32\bin;C:\Program Files\Git\cmd;C:\Program Files\NVIDIA Corporation\Nsight Compute 2021.2.1\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Users\HuaweiOpensource\anaconda3;C:\Users\HuaweiOpensource\anaconda3\Scripts;C:\Users\HuaweiOpensource\anaconda3\Library\bin;C:\Users\HuaweiOpensource\anaconda3\Library\mingw-w64;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files (x86)\GnuWin32\bin;C:\Users\HuaweiOpensource\AppData\Local\Programs\Python\Python38\Scripts\;C:\Users\HuaweiOpensource\AppData\Local\Programs\Python\Python38\;C:\Users\HuaweiOpensource\.cargo\bin;C:\Users\HuaweiOpensource\.cargo\bin;D:\Program Files\JetBrains\CLion 2022.1.3\bin;;D:\Program Files\JetBrains\PyCharm Community Edition 2020.3\bin;;D:\Program Files\OpenSSL-Win64\bin;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit;C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64;" "D:\\rust-backup\\parallel_rust\\rust-para\\build\\x86_64-pc-windows-msvc\\stage1\\bin\\rustc.exe" "D:\\rust-backup\\parallel_rust\\rust-para\\tests\\ui\\recursion\\issue-95134.rs" "-Zthreads=1" "--target=x86_64-pc-windows-msvc" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Zdeduplicate-diagnostics=no" "-Cstrip=debuginfo" "--remap-path-prefix=D:\\rust-backup\\parallel_rust\\rust-para\\tests\\ui=fake-test-src-base" "-C" "prefer-dynamic" "--out-dir" "D:\\rust-backup\\parallel_rust\\rust-para\\build\\x86_64-pc-windows-msvc\\test\\ui\\recursion\\issue-95134" "-A" "unused" "-Crpath" "-Cdebuginfo=0" "-Lnative=D:\\rust-backup\\parallel_rust\\rust-para\\build\\x86_64-pc-windows-msvc\\native\\rust-test-helpers" "-L" "D:\\rust-backup\\parallel_rust\\rust-para\\build\\x86_64-pc-windows-msvc\\test\\ui\\recursion\\issue-95134\\auxiliary" "-Copt-level=0"
stdout: none
--- stderr -------------------------------
thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', C:\Users\HuaweiOpensource\.cargo\registry\src\github.com-1ecc6299db9ec823\ena-0.14.2\src\snapshot_vec.rs:199:10
stack backtrace:
0: 0x7ffc3e90bc05 - std::backtrace_rs::backtrace::trace_unsynchronized::hfabb14c555fa1e54
1: 0x7ffc3e900799 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h88786f2c1c37cad0
2: 0x7ffc3e95143b - core::fmt::write::hef4555c5285e005b
3: 0x7ffc3e8ef2aa - std::io::Write::write_fmt::h9ea304efc4781c26
4: 0x7ffc3e90059b - std::sys_common::backtrace::print::h7b33cd350eefb143
......
178: 0x7ffc27d6a3f2 - <&mut serde_json[7222a1897944c7c8]::ser::Serializer<&mut alloc[6a6f6c0f0cd9fa15]::vec::Vec<u8>, serde_json[7222a1897944c7c8]::ser::PrettyFormatter> as serde[d3e6684f4f38fcf7]::ser::Serializer>::collect_seq::<&alloc[6a6f6c0f0cd9fa15]::vec::Vec<serde_json[7222a1897944c7c8]::value::Value>>
179: 0x7ffc3e8ed9ec - std::sys::windows::thread::Thread::new::thread_start::h5be4f069fac1a629
180: 0x7ffcb0b37614 - BaseThreadInitThunk
181: 0x7ffcb18c26a1 - RtlUserThreadStart
error: 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.70.0-dev running on x86_64-pc-windows-msvc
note: compiler flags: -Z threads=1 -C codegen-units=1 -Z ui-testing -Z simulate-remapped-rust-src-base=/rustc/FAKE_PREFIX -Z translate-remapped-path-to-local-path=no -Z deduplicate-diagnostics=no -C strip=debuginfo -C prefer-dynamic -C rpath -C debuginfo=0 -C opt-level=0
query stack during panic:
thread 'rustc' panicked at 'type variables should not be hashed: _#0t', D:\rust-backup\parallel_rust\rust-para\compiler\rustc_type_ir\src\lib.rs:718:17
stack backtrace:
0: 0x7ffc3e90bc05 - std::backtrace_rs::backtrace::trace_unsynchronized::hfabb14c555fa1e54
1: 0x7ffc3e900799 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h88786f2c1c37cad0
2: 0x7ffc3e95143b - core::fmt::write::hef4555c5285e005b
3: 0x7ffc3e8ef2aa - std::io::Write::write_fmt::h9ea304efc4781c26
4: 0x7ffc3e90059b - std::sys_common::backtrace::print::h7b33cd350eefb143
5: 0x7ffc3e91c109 - std::panicking::default_hook::h12f01c5f2b8959c6
......
197: 0x7ffc27d6a3f2 - <&mut serde_json[7222a1897944c7c8]::ser::Serializer<&mut alloc[6a6f6c0f0cd9fa15]::vec::Vec<u8>, serde_json[7222a1897944c7c8]::ser::PrettyFormatter> as serde[d3e6684f4f38fcf7]::ser::Serializer>::collect_seq::<&alloc[6a6f6c0f0cd9fa15]::vec::Vec<serde_json[7222a1897944c7c8]::value::Value>>
198: 0x7ffc3e8ed9ec - std::sys::windows::thread::Thread::new::thread_start::h5be4f069fac1a629
199: 0x7ffcb0b37614 - BaseThreadInitThunk
200: 0x7ffcb18c26a1 - RtlUserThreadStart
error: 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.70.0-dev running on x86_64-pc-windows-msvc
note: compiler flags: -Z threads=1 -C codegen-units=1 -Z ui-testing -Z simulate-remapped-rust-src-base=/rustc/FAKE_PREFIX -Z translate-remapped-path-to-local-path=no -Z deduplicate-diagnostics=no -C strip=debuginfo -C prefer-dynamic -C rpath -C debuginfo=0 -C opt-level=0
query stack during panic:
thread panicked while processing panic. aborting.
------------------------------------------
```
|
|
Remove f32 & f64 from MemDecoder/MemEncoder
r? ```@Nilstrieb```
since they said (maybe joked) on discord that it's a bug if the compiler uses f32 anywhere 🙃
|
|
Derive String's PartialEq implementation
|
|
rustdoc: avoid including line numbers in Google SERP snippets
|
|
Don't leave a comma at the start of argument list when removing arguments
Fixes #109425
Quite a dirty hack, but at least it works ig.
|
|
r=cjgillot
Implement support for `GeneratorWitnessMIR` in new solver
r? ```@cjgillot```
I mostly want this to cut down the number of failing UI tests when running the UI test suite with `--compare-mode=next-solver`, but there doesn't seem like much reason to block implementing this since it adds minimal complexity to the existing structural traits impl in the new solver.
If others are against adding this for some reason, then maybe we should just make `GeneratorWitnessMIR` return `NoSolution` for these traits. Anything but an ICE please :smile_cat: :ice_cube:
|
|
Fix issue when there are multiple candidates for edit_distance_with_substrings
Fixes #109291
|
|
Erase query cache values
This replaces most concrete query values `V` with `MaybeUninit<[u8; { size_of::<V>() }]>` without introducing dynamic dispatch like https://github.com/rust-lang/rust/pull/108638 does. This is split out of https://github.com/rust-lang/rust/pull/108638 so the performance impact of only this change can be measured.
r? `@cjgillot`
|
|
Check pattern refutability on THIR
The current `check_match` query is based on HIR, but partially re-lowers HIR into THIR.
This PR proposed to use the results of the `thir_body` query to check matches, instead of re-building THIR.
Most of the diagnostic changes are spans getting shorter, or commas/semicolons not getting removed.
This PR degrades the diagnostic for confusing constants in patterns (`let A = foo()` where `A` resolves to a `const A` somewhere): it does not point ot the definition of `const A` any more.
|
|
|
|
Update to LLVM 16.0.1
Update to current `release/16.x` branch. I've opted for a rebase to get rid of all our custom cherry-picks.
Fixes #109775.
r? `@cuviper`
|
|
|
|
Use `FieldIdx` in `FieldsShape`
Finally got to the main motivating example from https://github.com/rust-lang/compiler-team/issues/606 :)
|
|
|
|
|
|
|
|
|
|
|
|
Reduce the default max number of files in a UI test directory
It doesn't make sense for the root directory to have a lower limit than subdirectories.
|
|
Only visit reachable blocks in ConstProp lint.
Fixes https://github.com/rust-lang/rust/issues/78803
Fixes https://github.com/rust-lang/rust/issues/109731
|
|
Rollup of 7 pull requests
Successful merges:
- #109909 (Deny `use`ing tool paths)
- #109921 (Don't ICE when encountering `dyn*` in statics or consts)
- #109922 (Disable `has_thread_local` on OpenHarmony)
- #109926 (write threads info into log only when debugging)
- #109968 (Add regression test for #80409)
- #109969 (Add regression test for #86351)
- #109973 (rustdoc: Improve logo display very small screen)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
r=notriddle
rustdoc: Improve logo display very small screen
Before:
After:
r? `@notriddle`
|
|
Add regression test for #86351
r? `@compiler-errors`
Closes #86351
|
|
Add regression test for #80409
r? ``@compiler-errors``
Closes #80409
|
|
write threads info into log only when debugging
The current tracing log will unconditionally write thread information during parallel compilation, which sometimes confuses some normal output log information
This fixes the UI test failure of:
```
[ui] tests/ui/consts/const_in_pattern/issue-73431.rs
```
Updates #75760
|
|
Disable `has_thread_local` on OpenHarmony
OpenHarmony uses emulated TLS, which doesn't link properly when using thread-local variables across crate boundaries with `-C prefer-dynamic`. This PR makes thread_local! use pthreads directly instead.
|
|
Don't ICE when encountering `dyn*` in statics or consts
Since we have properly implemented `dyn*` support in CTFE (#107728), let's not ICE here anymore.
Fixes #105777
r? `@eholk`
|
|
Deny `use`ing tool paths
Fixes #109853
Fixes #109147
|
|
resolve: Restore some effective visibility optimizations
Something similar was previously removed as a part of https://github.com/rust-lang/rust/pull/104602.
So we can see [bitmaps-3.1.0](https://github.com/rust-lang/rustc-perf/tree/master/collector/compile-benchmarks/bitmaps-3.1.0), [match-stress](https://github.com/rust-lang/rustc-perf/tree/master/collector/compile-benchmarks/match-stress) and [unused-warnings](https://github.com/rust-lang/rustc-perf/tree/master/collector/compile-benchmarks/unused-warnings) in regressions there, and in improvements in this PR.
After this PR all table changes should also be "locally correct" after every update.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use SipHash-1-3 instead of SipHash-2-4 for StableHasher
Noticed this, and it seems easy and likely a perf win. IIUC we don't need DDOS resistance (just collision) so we ideally would have an even faster hash, but it's hard to beat this SipHash impl here, since it's been so highly tuned for the interface.
It wouldn't surprise me if there's some subtle reason changing this sucks, as it's so obvious it seems likely to have been done. Still, SipHash-1-3 seems to still have the guarantees StableHasher should need (and seemingly more), and is clearly less work. So it's worth a shot.
Not fully tested locally.
|
|
Validate `ignore` and `only` compiletest directive, and add human-readable ignore reasons
This PR adds strict validation for the `ignore` and `only` compiletest directives, failing if an unknown value is provided to them. Doing so uncovered 79 tests in `tests/ui` that had invalid directives, so this PR also fixes them.
Finally, this PR adds human-readable ignore reasons when tests are ignored due to `ignore` or `only` directives, like *"only executed when the architecture is aarch64"* or *"ignored when the operative system is windows"*. This was the original reason why I started working on this PR and #108659, as we need both of them for Ferrocene.
The PR is a draft because the code is extremely inefficient: it calls `rustc --print=cfg --target $target` for every rustc target (to gather the list of allowed ignore values), which on my system takes between 4s and 5s, and performs a lot of allocations of constant values. I'll fix both of them in the coming days.
r? `@ehuss`
|
|
|
|
The function names with const generic parameters are printed in a
different order.
|
|
The order in which the multiple errors for the ambiguous intra doc links
are printed is different.
|
|
The ids for the multiple `Item` associated type elements are swapped
between the first and second impl.
|
|
|
|
|
|
|
|
|
|
|
