move pal cfgs in f32 and f64 to sys
I'd like to push forward on `sys` being a separate crate. To start with, most of these PAL exception cases are very simple little bits of code like this, so I thought I would try tidying them up.
Re-enable some coverage tests on Linux
These tests were originally disabled (on all platforms) in #110393, because those changes had made them start failing on Linux for unclear reasons.
I tried to re-enable them unconditionally in #111179, since they worked locally on my Mac, but I found that they were still failing on Linux, so I gave up at that time.
Later while working on #112300 I was able to re-enable them on Windows and Mac, since those changes made it possible to add specific `ignore-` directives to individual tests. I noticed at the time that the tests actually seemed to be working again on Linux, but by that point I didn't want to risk more CI failures, so I left them disabled on Linux with an intention to re-enable them later.
Now I'm going back to re-enable them on Linux too, since they seem to work fine.
---
Because `run-coverage` tests are sensitive to line numbers, and `x test tidy` doesn't like leading blank lines, I've replaced the old comment/ignore with an informative comment that occupies the same number of lines.
Feature: Add a memory layout viewer
**Motivation**: rustc by default doesn't enforce a particular memory layout, however it can be useful to see what it is doing under the hood, or if using a particular repr ensure it is behaving how you want it to. This command provides a way to visually explore memory layouts of structures.
**Example**:
this structure:
```rust
struct X {
x: i32,
y: u8,
z: Vec<bool>,
w: usize,
}
```
produces this output:
<img width="692" alt="image" src="https://github.com/rust-lang/rust-analyzer/assets/22418744/e0312233-18a7-4bb9-ae5b-7b52fcff158a">
**Work yet to be done**:
- tests (see below)
- html is mildly janky (see below)
- enums and unions are viewed flatly, how should they be represented?
- should niches be marked somehow?
This was written for my own use, and the jank is fine for me, but in its current state it is probably not ready to merge mostly because it is missing tests, and also because the code quality is not great. However, before I spend time fixing those things idk if this is even something wanted, if it is I am happy to clean it up, if not that's cool too.
[`unnecessary_literal_unwrap`]: don't lint if binding initializer comes from expansion
Fixes https://github.com/rust-lang/rust-clippy/discussions/11109
changelog: [`unnecessary_literal_unwrap`]: don't lint if binding initializer comes from expansion
Copy stage0 `rustc` binaries to `stage0-sysroot`
This is basically a revival of https://github.com/rust-lang/rust/pull/101711 and https://github.com/rust-lang/rust/pull/107956, with an added check that the full sysroot will only be created if the original rustc comes from `stage0/bin`.
What is/should be tested:
- [x] `rustup toolchain link stage0` (new libstd is used correctly)
- [x] `python3 x.py fmt dist --stage 0`
- [x] Custom rustc/cargo in `config.toml` (in this case this logic is ignored)
- [x] Perfbot (try perf run has succeeded)
- [x] Real use case (https://github.com/rust-lang/backtrace-rs/pull/542)
(Hopefully) fixes: https://github.com/rust-lang/rust/issues/101691
This is not the "end all, be all" solution to this problem, but as long as it resolves the basic use-case, and doesn't break perfbot, I say ship it. This code will probably be nuked anyway Soon™ because of the stage redesign.
PR #95604 introduced a "synthetic object file to ensure all exported and
used symbols participate in the linking". One constraint on this file is
that for MIPS-based targets, its architecture-specific ELF flags must be
the same as all other object files passed to the linker. That's enforced
by LLD, here:
https://github.com/llvm/llvm-project/blob/llvmorg-16.0.6/lld/ELF/Arch/MipsArchTree.cpp#L77
The current approach to determining e_flags for 32-bit was implemented
in PR #96930, which links to this issue that summarizes the problem well:
https://github.com/ayrtonm/psx-sdk-rs/issues/9
> ... the temporary object file is created with an e_flags which is
> invalid for 32-bit MIPS targets. The main issue is that it omits the ABI
> bits (EF_MIPS_ABI_O32) which implies it uses the N64 ABI.
To enable the N32 MIPS ABI (which succeeded O32), this patch enables
setting the synthetic object's ABI based on the target "llvm-abiname"
field, if it's given; otherwise, the O32 ABI is assumed for 32-bit MIPS
targets.
More information about the N32 ABI can be found here:
https://web.archive.org/web/20160121005457/http://techpubs.sgi.com/library/manuals/2000/007-2816-005/pdf/007-2816-005.pdf
"try this" -> "try"
Current help messages contain a mix of "try", "try this", and one "try this instead". In the spirit of #10631, this PR adopts the first, as it is the most concise.
It also updates the `lint_message_conventions` test to catch cases of "try this".
(Aside: #10120 unfairly contained multiple changes in one PR. I am trying to break that PR up into smaller pieces.)
changelog: Make help messages more concise ("try this" -> "try").
Add Tests for native wasm exceptions
### Motivation
In PR #111322, I added support for native WASM exceptions. I was asked by ``@davidtwco`` to add some tests for it in a follow up PR, which seems like a very good idea.
This PR adds three tests for this feature:
* codegen: ensure the correct LLVM instructions are used
* assembly: ensure the correct WASM instructions are used
* run-make: ensure the exception handling works; the WASM code is run using a small nodejs script which demonstrates the exception handling
### Complications
There are a few changes beside adding the tests, which were necessary
* Tests for the wasm32-unknown-unknown target are (as far as I know) only run on `test-various`. Its docker image uses nodejs-15, which is very old. Experimental support for wasm-exceptions was added in nodejs16. In nodejs 18.12 (LTS), they are stable.
- --> increase nodejs to 18.12 in `test-various`
* codegen/assembly tests are not performed for the wasm32-unknown-unknown target yet
- --> add those to `test-various` as well
Due to the last point, some tests are run which have not run before (assembly+codegen tests for wasm32-unknown-unknown). I added `// ignore wasm32-bare` for those which failed
### Local testing
I run all tests locally using both `test-various` and `wasm32`. As far as I know, none of the other systems run any test for wasm32 targets.
Always name the return place.
MIR opts more and more consider `_0` as just another local, so there is no point in keeping the special case in debug-info logic.
Add `needless_pass_by_ref_mut` lint
changelog: [`needless_pass_by_ref_mut`]: This PR add a new lint `needless_pass_by_ref_mut` which emits a warning in case a `&mut` function argument isn't used mutably. It doesn't warn on trait and trait impls functions.
Fixes#8863.
Update debuginfo test runner to provide more useful output
This change makes debuginfo tests more user friendly. Changes:
- Print all lines that fail to match the patterns instead of just the first
- Provide better error messages that also say what did match
- Strip leading whitespace from directives so they are not skipped if indented
- Improve documentation and improve nesting on some related items
As an example, given the following intentional fail (and a few not shown):
```rust
// from tests/debuginfo/rc_arc.rs
// cdb-command:dx rc,d
// cdb-check:rc,d : 111 [Type: alloc::rc::Rc<i32>]
// cdb-check: [Reference count] : 11 [Type: core::cell FAIL::Cell<usize>]
// cdb-check: [Weak reference count] : 2 [Type: core::cell FAIL::Cell<usize>]
```
The current output (tested in #113313) will show:
```
2023-07-04T08:10:00.1939267Z ---- [debuginfo-cdb] tests\debuginfo\rc_arc.rs stdout ----
2023-07-04T08:10:00.1942182Z
2023-07-04T08:10:00.1957463Z error: line not found in debugger output: [Reference count] : 11 [Type: core:: cell FAIL::Cell<usize>]
2023-07-04T08:10:00.1958272Z status: exit code: 0
```
With this chane, you are able to see all failures in that check group, as well as what parts were successful. The output is now:
```
2023-07-04T09:45:57.2514224Z error: check directive(s) from `C:\a\rust\rust\tests\debuginfo\rc_arc.rs` not found in debugger output. errors:
2023-07-04T09:45:57.2514631Z (rc_arc.rs:31) ` [Reference count] : 11 [Type: core::cell FAIL::Cell<usize>]`
2023-07-04T09:45:57.2514908Z (rc_arc.rs:32) ` [Weak reference count] : 2 [Type: core::cell FAIL::Cell<usize>]`
2023-07-04T09:45:57.2515181Z (rc_arc.rs:41) ` [Reference count] : 21 [Type: core::sync::atomic FAIL::AtomicUsize]`
2023-07-04T09:45:57.2515452Z (rc_arc.rs:50) `dyn_rc,d [Type: alloc::rc::Rc<dyn$<core::fmt FAIL::Debug> >]`
2023-07-04T09:45:57.2515695Z the following subset of check directive(s) was found successfully::
2023-07-04T09:45:57.2516080Z (rc_arc.rs:30) `rc,d : 111 [Type: alloc::rc::Rc<i32>]`
2023-07-04T09:45:57.2516312Z (rc_arc.rs:35) `weak_rc,d : 111 [Type: alloc::rc::Weak<i32>]`
2023-07-04T09:45:57.2516555Z (rc_arc.rs:36) ` [Reference count] : 11 [Type: core::cell::Cell<usize>]`
2023-07-04T09:45:57.2516881Z (rc_arc.rs:37) ` [Weak reference count] : 2 [Type: core::cell::Cell<usize>]`
...
```
Which makes it easier to see what did and didn't succeed without manual comparison against the source test file.
Port PGO/LTO/BOLT optimized build pipeline to Rust
This PR ports the `stage-build.py` PGO/LTO/BOLT optimization script from Python to Rust, to make it easier to use dependencies, and make it a bit more robust. The PR switches both the Linux and Windows dist runners to the Rust script and removes the old Python script.
Funnily enough, the Rust port has less lines of code than the Python script :) I think that clearly shows that the Python script really lacked dependencies.
`does_not_fill_wildcard_with_wildcard`
and `does_not_fill_wildcard_with_partial_wildcard_and_wildcard`
both made no modifications to the code,
which is a problem for mutable ast porting as it generates a best-effort
minimal set of text edits,
and assists require at least one text edit.
