conditionally modify darwin targets to macosx targets with versions
We need this behavior so that Rust LLVM IR objects match the target triple for Clang LLVM IR objects. This matching then convinces the linker that yes, you really can do cross-language LTO with objects from different compilers.
The newly-added tests seem to pass locally on x86_64-unknown-linux-gnu. I haven't done a full test run or tried the new compiler in an cross-language LTO setup yet.
PGO: Add a run-make test that makes sure that PGO profiling data is used by the compiler during optimizations.
From the tests comment section:
```
# This test makes sure that PGO profiling data leads to cold functions being
# marked as `cold` and hot functions with `inlinehint`.
# The test program contains an `if` were actual execution only ever takes the
# `else` branch. Accordingly, we expect the function that is never called to
# be marked as cold.
```
r? @alexcrichton
In JSON output, emit a directive after metadata is generated.
To implement pipelining, Cargo needs to know when metadata generation is
finished. This is done via a new JSON "directive".
Unfortunately, metadata file writing currently occurs very late during
compilation, so pipelining won't produce a speed-up. Moving metadata
file writing earlier will be a follow-up.
r? @alexcrichton
To implement pipelining, Cargo needs to know when metadata generation is
finished. This commit adds code to do that. Unfortunately, metadata file
writing currently occurs very late during compilation, so pipelining
won't produce a speed-up. Moving metadata file writing earlier will be a
follow-up.
The change involves splitting the existing `Emitter::emit` method in
two: `Emitter::emit_diagnostic` and `Emitter::emit_directive`.
The JSON directives look like this:
```
{"directive":"metadata file written: liba.rmeta"}
```
The functionality is behind the `-Z emit-directives` option, and also
requires `--error-format=json`.
Add codegen test for PGO instrumentation.
This PR adds a codegen test that makes sure that LLVM actually generates instrumentation code when we enable PGO instrumentation in `rustc`.
The second commit updates a test case to the new commandline option syntax introduced in #59874. Without the fix the test still works, but it confusingly creates a directory called `test.profraw`, which usually is the name of the _file_ where profiling data is collected.
compiletest normalization: preserve non-JSON lines such as ICEs
Currently, every non-JSON line from stderr gets normalized away when compiletest normalizes the output. In particular, ICEs get normalized to the empty output. That does not seem desirable, so this changes normalization to preserve non-JSON lines instead.
Also see https://github.com/laumann/compiletest-rs/issues/169: because of that bug, Miri currently *looks* green in the toolstate, but some tests ICE. That same bug is likely no longer present in latest compiletest because the error code gets checked separately, but it still seems like a good idea to also make sure that ICEs are considered stderr output:
This change found an accidental user-visible `error!` in CTFE validation (fixed), and a non-deterministic panic when there are two `main` symbols (not fixed, no idea where this comes from). Both got missed before because non-JSON output got ignored.
On musl (and some other platforms), compiletest ends up creating a static rlib
(instead of a dylib) when building 'aux-build' crates.
This commit changes the '--extern-private' path computed by compiletest
to properly take this into account
compiletest: Improve no_prefer_dynamic docs
This adds some extra docs for the `no-prefer-dynamic` header.
And also a `s/must_compile_successfully/compile_pass`.
`must_compile_successfully` has been renamed to `compile_pass` at some
point in the past and this comment was still referring to the old name.
This adds some extra docs for the `no-prefer-dynamic` header.
And also a `s/must_compile_successfully/compile_pass`.
`must_compile_successfully` has been renamed to `compile_pass` at some
point in the past and this comment was still referring to the old name.
When using the `rustfix-coverage` flag, some tests currently fail
because they define a different error-format than `json`.
The current implementation crashes when encountering those tests. Since
we don't care about non-json test output when collecting the coverage
data, we handle those tests by returning an empty `Vec` instead.
Add a way to track Rustfix UI test coverage
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.
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.
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
Filter ui revision tests
Updates UI test output filtering to also filter away test annotations for revisions:
Previously filtered: //~ ERROR [XXXX]
Now also filters: //[revision]~ ERROR [XXXX]
I reckon, if we have the one, we should have the other for consistency, its lack was probably an oversight (the existence of revision testing is not really well documented...)
MIPS: add r6 support
MIPS r6 is quite different with the previous version.
It use some new target triples:
mipsisa32r6-unknown-linux-gnu
mipsisa32r6el-unknown-linux-gnu
mipsisa64r6-unknown-linux-gnuabi64
mipsisa64r6el-unknown-linux-gnuabi64
This patch has been tested with Debian Port for mips64r6el,
and the support of these triples also is included in llvm:
https://reviews.llvm.org/rGe58c45a695f39004710b6ce940d489fee800dbd3
