This came out of the first Rustfix WG meeting.
One of the goals is to enable Rustfix tests for all UI tests that
trigger lints with `MachineApplicable` suggestions. In order to do that
we first want to create a tracking issue that lists all files with
missing `// run-rustfix` headers.
This PR adds a `--rustfix-coverage` flag to `./x.py` and compiletest to
list the files with the missing headers in `/tmp/rustfix_missing_coverage.txt`.
From that file we can create the tracking issue and at some point also
enforce the `// run-rustfix` flag on UI tests with `MachineApplicable`
lints.
Rework how bootstrap tools are built
This makes bootstrap tools buildable and testable in stage 0 with the downloaded bootstrap compiler, futhermore, it makes it such that they cannot be built in any other stage.
Notably, this will also mean that compiletest may need to wait a cycle before it can use changes to `libtest`, as it no longer depends on the in-tree libtest.
Introduce assembly tests suite
The change introduces a new test suite - **Assembly** tests. The motivation behind this is an ability to perform end-to-end codegen testing with LLVM backend. Turned out, NVPTX backend sometimes missing common Rust features (`i128` and libcalls in the past, and still full atomics support) due to different reasons.
Prior to this change, basic NVPTX assembly tests were implemented within `run-make` suite. Now, it's easier to write additional and maintain existing tests for the target.
cc @gnzlbg @peterhj
cc @eddyb I adjusted mangling scheme expectation, so there is no need to change the tests for #57967
bootstrap: Default to a sensible llvm-suffix.
I used version-channel-sha, hopefully that should work.
I checked that bootstrap builds, but I cannot check anything else since the llvm
build process is started from cargo, and thus calls clang, and thus I hit the
same bug I hope to fix with this change.
Hopefully fixes#59034.
I used version-channel-sha, hopefully that should work.
I checked that bootstrap builds, but I cannot check anything else since the llvm
build process is started from cargo, and thus calls clang, and thus I hit the
same bug I hope to fix with this change.
Hopefully fixes#59034.
look for python2 symlinks before bootstrap python
Before this commit, if you're running x.py directly on a system where
`python` is symlinked to Python 3, then the `python` config option will
default to a Python 3 interpreter. This causes debuginfo tests to fail
with an opaque error message, since they have a hard requirement on
Python 2.
This commit modifies the Python probe behavior to look for python2.7 and
python2 *before* using the interpreter used to execute `x.py`.
Before this commit, if you're running x.py directly on a system where
`python` is symlinked to Python 3, then the `python` config option will
default to a Python 3 interpreter. This causes debuginfo tests to fail
with an opaque error message, since they have a hard requirement on
Python 2.
This commit modifies the Python probe behavior to look for python2.7 and
python2 *before* using the interpreter used to execute `x.py`.
rustc: Update LLVM, remove dead wasm code
This commit updates the LLVM branch to the rebased version of the
upstream release/8.x branch. This includes a wasm patch which means that
the `rewrite_imports` pass in rustc is no longer needed (yay!) and we
can instead rely on `wasm-import-module`, an attribute we're already
emitting, to take care of all the work.
We'll use this as a temporary measure to get an LLVM update landed, but
we'll have to go through and update images later to make sure they've
got the right toolchains.
