Rollup of 8 pull requests
Successful merges:
- #74759 (add `unsigned_abs` to signed integers)
- #75043 (rustc_ast: `(Nested)MetaItem::check_name` -> `has_name`)
- #75056 (Lint path statements to suggest using drop when the type needs drop)
- #75081 (Fix logging for rustdoc)
- #75083 (Do not trigger `unused_braces` for `while let`)
- #75084 (Stabilize Ident::new_raw)
- #75103 (Disable building rust-analyzer on riscv64)
- #75106 (Enable docs on in the x86_64-unknown-linux-musl manifest)
Failed merges:
r? @ghost
Lint path statements to suggest using drop when the type needs drop
Fixes#48852. With this change the current lint description doesn't really fit entirely anymore I think.
rustc: Improving safe wasm float->int casts
This commit improves code generation for WebAssembly targets when
translating floating to integer casts. This improvement is only relevant
when the `nontrapping-fptoint` feature is not enabled, but the feature
is not enabled by default right now. Additionally this improvement only
affects safe casts since unchecked casts were improved in #74659.
Some more background for this issue is present on #73591, but the
general gist of the issue is that in LLVM the `fptosi` and `fptoui`
instructions are defined to return an `undef` value if they execute on
out-of-bounds values; they notably do not trap. To implement these
instructions for WebAssembly the LLVM backend must therefore generate
quite a few instructions before executing `i32.trunc_f32_s` (for
example) because this WebAssembly instruction traps on out-of-bounds
values. This codegen into wasm instructions happens very late in the
code generator, so what ends up happening is that rustc inserts its own
codegen to implement Rust's saturating semantics, and then LLVM also
inserts its own codegen to make sure that the `fptosi` instruction
doesn't trap. Overall this means that a function like this:
#[no_mangle]
pub unsafe extern "C" fn cast(x: f64) -> u32 {
x as u32
}
will generate this WebAssembly today:
(func $cast (type 0) (param f64) (result i32)
(local i32 i32)
local.get 0
f64.const 0x1.fffffffep+31 (;=4.29497e+09;)
f64.gt
local.set 1
block ;; label = @1
block ;; label = @2
local.get 0
f64.const 0x0p+0 (;=0;)
local.get 0
f64.const 0x0p+0 (;=0;)
f64.gt
select
local.tee 0
f64.const 0x1p+32 (;=4.29497e+09;)
f64.lt
local.get 0
f64.const 0x0p+0 (;=0;)
f64.ge
i32.and
i32.eqz
br_if 0 (;@2;)
local.get 0
i32.trunc_f64_u
local.set 2
br 1 (;@1;)
end
i32.const 0
local.set 2
end
i32.const -1
local.get 2
local.get 1
select)
This PR improves the situation by updating the code generation for
float-to-int conversions in rustc, specifically only for WebAssembly
targets and only for some situations (float-to-u8 still has not great
codegen). The fix here is to use basic blocks and control flow to avoid
speculatively executing `fptosi`, and instead LLVM's raw intrinsic for
the WebAssembly instruction is used instead. This effectively extends
the support added in #74659 to checked casts. After this commit the
codegen for the above Rust function looks like:
(func $cast (type 0) (param f64) (result i32)
(local i32)
block ;; label = @1
local.get 0
f64.const 0x0p+0 (;=0;)
f64.ge
local.tee 1
i32.const 1
i32.xor
br_if 0 (;@1;)
local.get 0
f64.const 0x1.fffffffep+31 (;=4.29497e+09;)
f64.le
i32.eqz
br_if 0 (;@1;)
local.get 0
i32.trunc_f64_u
return
end
i32.const -1
i32.const 0
local.get 1
select)
For reference, in Rust 1.44, which did not have saturating
float-to-integer casts, the codegen LLVM would emit is:
(func $cast (type 0) (param f64) (result i32)
block ;; label = @1
local.get 0
f64.const 0x1p+32 (;=4.29497e+09;)
f64.lt
local.get 0
f64.const 0x0p+0 (;=0;)
f64.ge
i32.and
i32.eqz
br_if 0 (;@1;)
local.get 0
i32.trunc_f64_u
return
end
i32.const 0)
So we're relatively close to the original codegen, although it's
slightly different because the semantics of the function changed where
we're emulating the `i32.trunc_sat_f32_s` instruction rather than always
replacing out-of-bounds values with zero.
There is still work that could be done to improve casts such as `f32` to
`u8`. That form of cast still uses the `fptosi` instruction which
generates lots of branch-y code. This seems less important to tackle now
though. In the meantime this should take care of most use cases of
floating-point conversion and as a result I'm going to speculate that
this...
Closes#73591
Fix change detection in CfgSimplifier::collapse_goto_chain
Check that the old target is different from the new collapsed one, before concluding that anything changed.
Fixes#75074Fixes#75051
tests: Ignore src/test/debuginfo/rc_arc.rs on Windows
It requires loading pretty-printers (`src\etc\gdb_load_rust_pretty_printers.py`), but GDB doesn't load them on Windows.
Not sure how this passes through CI, due to an old GDB version perhaps?
Stabilize `Result::as_deref` and `as_deref_mut`
FCP completed in https://github.com/rust-lang/rust/issues/50264#issuecomment-645681400.
This PR stabilizes two new APIs for `std::result::Result`:
```rust
fn as_deref(&self) -> Result<&T::Target, &E> where T: Deref;
fn as_deref_mut(&mut self) -> Result<&mut T::Target, &mut E> where T: DerefMut;
```
This PR also removes two rarely used unstable APIs from `Result`:
```rust
fn as_deref_err(&self) -> Result<&T, &E::Target> where E: Deref;
fn as_deref_mut_err(&mut self) -> Result<&mut T, &mut E::Target> where E: DerefMut;
```
Closes#50264
compiletest: Support ignoring tests requiring missing LLVM components
This PR implements a more principled solution to the problem described in https://github.com/rust-lang/rust/pull/66084.
Builds of LLVM backends take a lot of time and disk space.
So it usually makes sense to build rustc with
```toml
[llvm]
targets = "X86"
experimental-targets = ""
```
unless you are working on some target-specific tasks.
A few tests, however, require non-x86 backends to be built.
A new test directive `// needs-llvm-components: component1 component2 component3` makes such tests to be automatically ignored if one of the listed components is missing in the provided LLVM (this is determined through `llvm-config --components`).
As a result, the test suite now fully passes with LLVM built only with the x86 backend. The component list in this case is
```
aggressiveinstcombine all all-targets analysis asmparser asmprinter binaryformat bitreader bitstreamreader bitwriter cfguard codegen core coroutines coverage debuginfocodeview debuginfodwarf debuginfogsym debuginfomsf debuginfopdb demangle dlltooldriver dwarflinker engine executionengine frontendopenmp fuzzmutate globalisel instcombine instrumentation interpreter ipo irreader jitlink libdriver lineeditor linker lto mc mca mcdisassembler mcjit mcparser mirparser native nativecodegen objcarcopts object objectyaml option orcerror orcjit passes profiledata remarks runtimedyld scalaropts selectiondag support symbolize tablegen target textapi transformutils vectorize windowsmanifest x86 x86asmparser x86codegen x86desc x86disassembler x86info x86utils xray
```
(With the default target list it's much larger.)
```
aarch64 aarch64asmparser aarch64codegen aarch64desc aarch64disassembler aarch64info aarch64utils aggressiveinstcombine all all-targets analysis arm armasmparser armcodegen armdesc armdisassembler arminfo armutils asmparser asmprinter avr avrasmparser avrcodegen avrdesc avrdisassembler avrinfo binaryformat bitreader bitstreamreader bitwriter cfguard codegen core coroutines coverage debuginfocodeview debuginfodwarf debuginfogsym debuginfomsf debuginfopdb demangle dlltooldriver dwarflinker engine executionengine frontendopenmp fuzzmutate globalisel hexagon hexagonasmparser hexagoncodegen hexagondesc hexagondisassembler hexagoninfo instcombine instrumentation interpreter ipo irreader jitlink libdriver lineeditor linker lto mc mca mcdisassembler mcjit mcparser mips mipsasmparser mipscodegen mipsdesc mipsdisassembler mipsinfo mirparser msp430 msp430asmparser msp430codegen msp430desc msp430disassembler msp430info native nativecodegen nvptx nvptxcodegen nvptxdesc nvptxinfo objcarcopts object objectyaml option orcerror orcjit passes powerpc powerpcasmparser powerpccodegen powerpcdesc powerpcdisassembler powerpcinfo profiledata remarks riscv riscvasmparser riscvcodegen riscvdesc riscvdisassembler riscvinfo riscvutils runtimedyld scalaropts selectiondag sparc sparcasmparser sparccodegen sparcdesc sparcdisassembler sparcinfo support symbolize systemz systemzasmparser systemzcodegen systemzdesc systemzdisassembler systemzinfo tablegen target textapi transformutils vectorize webassembly webassemblyasmparser webassemblycodegen webassemblydesc webassemblydisassembler webassemblyinfo windowsmanifest x86 x86asmparser x86codegen x86desc x86disassembler x86info x86utils xray
```
https://github.com/rust-lang/rust/pull/66084 is also reverted now.
r? @Mark-Simulacrum
pprust: adjust mixed comment printing and add regression test for #74745Fixes#74745.
This PR adds a regression test for #74745. While a `ignore-tidy-trailing-lines` header is required, this doesn't stop the test from reproducing, so long as there is no newline at the end of the file.
However, adding the header comments made the test fail due to a bug in pprust - so this PR also adjusts the pretty printing of mixed comments so that the initial zero-break isn't emitted at the beginning of the line. Through this, the `block-comment-wchar` test can have the `pp-exact` file removed, as it no longer converges from pretty printing of the source.
Fix ICEs with `@ ..` binding
This reverts #74557 and introduces an alternative fix while ensuring that #74954 is not broken.
The diagnostics are verbose though, it fixes three related issues.
cc #74954, #74539, and #74702
This commit adds a regression test for #74745. While a
`ignore-tidy-trailing-lines` header is required, this doesn't stop the
test from reproducing, so long as there is no newline at the end of the
file.
However, adding the header comments made the test fail due to a bug in
pprust, fixed in the previous commit.
Signed-off-by: David Wood <david@davidtw.co>
This commit adjusts the pretty printing of mixed comments so that the
initial zero-break isn't emitted at the beginning of the line. Through
this, the `block-comment-wchar` test can have the `pp-exact` file
removed, as it no longer converges from pretty printing of the source.
Signed-off-by: David Wood <david@davidtw.co>
Deduplicate `::` -> `:` typo errors
Deduplicate errors caused by the same type ascription typo, including
ones suggested during parsing that would get reported again during
resolve. Fix#70382.
[mir] Special treatment for dereferencing a borrow to a static definition
Fix#70584.
As suggested by @oli-obk in this [comment](https://github.com/rust-lang/rust/issues/70584#issuecomment-626009260), one can chase the definition of the local variable being de-referenced and check if it is a true static variable. If that is the case, `validate_place` will admit the promotion.
This is my first time to contribute to `rustc`, and I have two questions.
1. A generalization to some extent is applied to decide if the promotion is possible in the static context. In case that there are more projection operations preceding the de-referencing, `validate_place` recursively decent into inner projection operations. I have put thoughts into its correctness but I am not totally sure about it.
2. I have a hard time to find a good place for the test case. This patch has to do with MIR, but this test case would look out of place compared to other tests in `src/test/ui/mir` or `src/test/ui/borrowck` because it does not generate errors while others do. It is tentatively placed in `src/test/ui/statics` for now.
Thank you for any comments and suggestions!
mir: add `used_generic_parameters_needs_subst`
Fixes#74636.
This PR adds a `used_generic_parameters_needs_subst` helper function which checks whether a type needs substitution, but only for parameters that the `unused_generic_params` query considers used. This is used in the MIR interpreter to make the check for some pointer casts and for reflection intrinsics more precise.
I've opened this as a draft PR because this might not be the approach we want to fix this issue and we have to decide what to do about the reflection case.
r? @eddyb
cc @lcnr @wesleywiser
Fix Const-Generic Cycle ICE #74199
This PR intends to fix the bug in Issue #74199 by following the suggestion provided of ignoring the error that causes the ICE.
This does not fix the underlying cycle detection issue, but fixes the ICE.
Also adds a test to check that it doesn't causes an ICE but returns a valid error for now.
r? @lcnr
Edit: Also it's funny how this PR number is an anagram of the issue number
* Deduplicate type ascription LHS errors
* Remove duplicated `:` -> `::` suggestion from parse error
* Tweak wording to be more accurate
* Modify `current_type_ascription` to reduce span wrangling
* remove now unnecessary match arm
* Add run-rustfix to appropriate tests
This commit adds a `ensure_monomorphic_enough` utility function which
checks whether a type needs substitution, but only for parameters
that the `unused_generic_params` query considers used.
`ensure_monomorphic_enough` is then used throughout interpret where
`needs_subst` checks previously existed (in particular, for some
pointer casts and for reflection intrinsics more precise).
Signed-off-by: David Wood <david@davidtw.co>
Make `Option::unwrap` unstably const
This is lumped into the `const_option` feature gate (#67441), which enables a potpourri of `Option` methods.
cc @rust-lang/wg-const-eval
r? @oli-obk
Improve diagnostics when constant pattern is too generic
This PR is a follow-up to PR #74538 and issue #73976
When constants queries Layout, TypeId or type_name of a generic parameter, instead of emitting `could not evaluate constant pattern`, we will instead emit a more detailed message `constant pattern depends on a generic parameter`.
