…-cov`

Don't skip the inconsistent data layout check for custom LLVMs.

With rust-lang#118708, all targets will have a simple test that would trigger this
check if LLVM's data layouts do change - so data layouts would be
corrected during the LLVM upgrade. Therefore, with builtin targets, this
check won't trigger with our LLVM because each target will have been
confirmed to work. With non-builtin targets, this check is probably
useful to have because you can change the data layout in your target and
if its wrong then that could lead to bugs.

When using a custom LLVM, the same justification makes sense for
non-builtin targets as with our LLVM, the user can update their target to
match their LLVM and that's probably a good thing to do. However, with
a custom LLVM, the user cannot change the builtin target data layouts if
they don't match - though given that the compiler's data layout is used
for layout computation and a bunch of other things - you could get some
bugs because of the mismatch and probably want to know about that.

`CFG_LLVM_ROOT` was also always set during local development with
`download-ci-llvm` so this bug would never trigger locally.

Signed-off-by: David Wood <[email protected]>

On ELF, the text section is opened with ".text", on MachO with
".section __TEXT,__text".

Previously, on ELF this test was actually matching a GNU note
section, which is no longer emitted on Solaris starting with
LLVM 18.

Fixes rust-lang#120105.

It looks like none of these are actually needed.

Also add tests for min-system-llvm-version.

…wiser

coverage: Never emit improperly-ordered coverage regions

If we emit a coverage region that is improperly ordered (end < start), `llvm-cov` will fail with `coveragemap_error::malformed`, which is inconvenient for users and also very hard to debug.

Ideally we would fix the root causes of these situations, but they tend to occur in very obscure edge-case scenarios (often involving nested macros), and we don't always have a good MCVE to work from. So it makes sense to also have a catch-all check that will prevent improperly-ordered regions from ever being emitted.

---

This is mainly aimed at resolving rust-lang#119453. We don't have a specific way to reproduce it, which is why I haven't been able to add a test case in this PR. But based on the information provided in that issue, this change seems likely to avoid the error in `llvm-cov`.

```@rustbot``` label +A-code-coverage

…r=wesleywiser

llvm: change data layout bug to an error and make it trigger more

Fixes rust-lang#33446.

Don't skip the inconsistent data layout check for custom LLVMs or non-built-in targets.

With rust-lang#118708, all targets will have a simple test that would trigger this error if LLVM's data layouts do change - so data layouts would be corrected during the LLVM upgrade. Therefore, with builtin targets, this error won't happen with our LLVM because each target will have been confirmed to work. With non-builtin targets, this error is probably useful to have because you can change the data layout in your target and if it is wrong then that could lead to bugs.

When using a custom LLVM, the same justification makes sense for non-builtin targets as with our LLVM, the user can update their target to match their LLVM and that's probably a good thing to do. However, with a custom LLVM, the user cannot change the builtin target data layouts if they don't match - though given that the compiler's data layout is used for layout computation and a bunch of other things - you could get some bugs because of the mismatch and probably want to know about that. I'm not sure if this is something that people do and is okay, but I doubt it?

`CFG_LLVM_ROOT` was also always set during local development with `download-ci-llvm` so this bug would never trigger locally.

In rust-lang#33446, two points are raised:

- In the issue itself, changing this from a `bug!` to a proper error is what is suggested, by using `isCompatibleDataLayout` from LLVM, but that function still just does the same thing that we do and check for equality, so I've avoided the additional code necessary to do that FFI call.
- ```@Mark-Simulacrum``` suggests a different check is necessary to maintain backwards compatibility with old LLVM versions. I don't know how often this comes up, but we can do that with some simple string manipulation + LLVM version checks as happens already for LLVM 17 just above this diff.

Split assembly tests for ELF and MachO

On ELF, the text section is opened with ".text", on MachO with ".section __TEXT,__text".

Previously, on ELF this test was actually matching a GNU note section, which is no longer emitted on Solaris starting with LLVM 18.

Fixes rust-lang#120105.

r? ```@davidtwco```

…direction, r=dtolnay

Switch `NonZero` alias direction.

Step 4 mentioned in rust-lang#100428 (review).

Depends on rust-lang#120160.

r? `@dtolnay`

coverage: Don't instrument `#[automatically_derived]` functions

This PR makes the coverage instrumentor detect and skip functions that have [`#[automatically_derived]`](https://doc.rust-lang.org/reference/attributes/derive.html#the-automatically_derived-attribute) on their enclosing impl block.

Most notably, this means that methods generated by built-in derives (e.g. `Clone`, `Debug`, `PartialEq`) are now ignored by coverage instrumentation, and won't appear as executed or not-executed in coverage reports.

This is a noticeable change in user-visible behaviour, but overall I think it's a net improvement. For example, we've had a few user requests for this sort of change (e.g. rust-lang#105055, rust-lang#84605 (comment)), and I believe it's the behaviour that most users will expect/prefer by default.

It's possible to imagine situations where users would want to instrument these derived implementations, but I think it's OK to treat that as an opportunity to consider adding more fine-grained option flags to control the details of coverage instrumentation, while leaving this new behaviour as the default.

(Also note that while `-Cinstrument-coverage` is a stable feature, the exact details of coverage instrumentation are allowed to change. So we *can* make this change; the main question is whether we *should*.)

Fixes rust-lang#105055.

Remove no-system-llvm

We currently have a bunch of codegen tests that use no-system-llvm -- however, all of those tests also pass with system LLVM 16.

I've opted to remove `no-system-llvm` entirely, as there's basically no valid use case for it anymore:

 * The only thing this option could have legitimately been used for (testing the target feature support that requires an LLVM patch) doesn't use it, and the need for this will go away with LLVM 18 anyway.
 * In cases where the test depends on optimizations/fixes from newer LLVM versions, `min-llvm-version` should be used instead.
 * In case it depends on optimization/fixes from newer LLVM versions that have been backported into our fork, `min-system-llvm-version` (with the major version larger than the one in our fork) should be used instead.

r? ```@cuviper```

Remove extra # from url in suggestion

The suggestion added in rust-lang#119805 contains an unnecessary # hash sign.