force "HEAD" for non-CI and `git_upstream_merge_base` for CI environment
When rust-lang/rust is configured as remote, some of the git logic (for tracking changed files) that uses get_closest_merge_commit starts to produce annoying results as the upstream branch becomes outdated quickly (since it isn't updated with git pull). We can rely on HEAD for non-CI environments as we specifically treat bors commits as merge commits, which also exist on upstream. As for CI environments, we should use `git_upstream_merge_base` to correctly track modified files as bors commits may be in `HEAD` but not yet on the upstream remote.
This is also an alternative fix for https://github.com/rust-lang/rust/issues/129528 since https://github.com/rust-lang/rust/pull/131331 reverts the previous fix attempts.
Take a display name for `tool_check_step!`
The tool build step already takes a display name, make the tool check step also take a display name to better represent the tool name. I.e. instead of `src/tools/cargo-miri` becoming `cargomiri`, it now becomes `cargo-miri`.
Fixes#131592.
When rust-lang/rust is configured as remote, some of the git
logic (for tracking changed files) that uses get_closest_merge_commit
starts to produce annoying results as the upstream branch becomes outdated
quickly (since it isn't updated with git pull). We can rely on HEAD for
non-CI environments as we specifically treat bors commits as merge commits,
which also exist on upstream. As for CI environments, we should use
`git_upstream_merge_base` to correctly track modified files as bors commits
may be in `HEAD` but not yet on the upstream remote.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Flatten redundant test module `run_make_support::diff::tests::tests`
This module is already named `tests`, and is already gated by `#[cfg(test)]`, so there's no need for it to also contain `mod tests`.
r? jieyouxu
intrinsics fmuladdf{32,64}: expose llvm.fmuladd.* semantics
Add intrinsics `fmuladd{f32,f64}`. This computes `(a * b) + c`, to be fused if the code generator determines that (i) the target instruction set has support for a fused operation, and (ii) that the fused operation is more efficient than the equivalent, separate pair of `mul` and `add` instructions.
https://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic
The codegen_cranelift uses the `fma` function from libc, which is a correct implementation, but without the desired performance semantic. I think this requires an update to cranelift to expose a suitable instruction in its IR.
I have not tested with codegen_gcc, but it should behave the same way (using `fma` from libc).
---
This topic has been discussed a few times on Zulip and was suggested, for example, by `@workingjubilee` in [Effect of fma disabled](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Effect.20of.20fma.20disabled/near/274179331).
Add intrinsics `fmuladd{f16,f32,f64,f128}`. This computes `(a * b) +
c`, to be fused if the code generator determines that (i) the target
instruction set has support for a fused operation, and (ii) that the
fused operation is more efficient than the equivalent, separate pair
of `mul` and `add` instructions.
https://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic
MIRI support is included for f32 and f64.
The codegen_cranelift uses the `fma` function from libc, which is a
correct implementation, but without the desired performance semantic. I
think this requires an update to cranelift to expose a suitable
instruction in its IR.
I have not tested with codegen_gcc, but it should behave the same
way (using `fma` from libc).
Rollup of 6 pull requests
Successful merges:
- #129079 (Create `_imp__` symbols also when doing ThinLTO)
- #131208 (ABI: Pass aggregates by value on AIX)
- #131394 (fix(rustdoc): add space between struct fields and their descriptions)
- #131519 (Use Default visibility for rustc-generated C symbol declarations)
- #131541 (compiletest: Extract auxiliary-crate properties to their own module/struct)
- #131542 (next-solver: remove outdated FIXMEs)
r? `@ghost`
`@rustbot` modify labels: rollup
compiletest: Extract auxiliary-crate properties to their own module/struct
This moves the values of the 4 different `aux-*` directives into their own sub-struct. That struct, along with its directive-parsing code, can then be shared by both `TestProps` and `EarlyProps`.
The final patch also fixes an oversight in up-to-date checking, by including *all* auxiliary crates in the timestamp, not just ordinary `aux-build` ones.
Retire the `unnamed_fields` feature for now
`#![feature(unnamed_fields)]` was implemented in part in #115131 and #115367, however work on that feature has (afaict) stalled and in the mean time there have been some concerns raised (e.g.[^1][^2]) about whether `unnamed_fields` is worthwhile to have in the language, especially in its current desugaring. Because it represents a compiler implementation burden including a new kind of anonymous ADT and additional complication to field selection, and is quite prone to bugs today, I'm choosing to remove the feature.
However, since I'm not one to really write a bunch of words, I'm specifically *not* going to de-RFC this feature. This PR essentially *rolls back* the state of this feature to "RFC accepted but not yet implemented"; however if anyone wants to formally unapprove the RFC from the t-lang side, then please be my guest. I'm just not totally willing to summarize the various language-facing reasons for why this feature is or is not worthwhile, since I'm coming from the compiler side mostly.
Fixes#117942Fixes#121161Fixes#121263Fixes#121299Fixes#121722Fixes#121799Fixes#126969Fixes#131041
Tracking:
* https://github.com/rust-lang/rust/issues/49804
[^1]: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Unnamed.20struct.2Funion.20fields
[^2]: https://github.com/rust-lang/rust/issues/49804#issuecomment-1972619108
coverage: Include the highest counter ID seen in `.cov-map` dumps
When making changes that have a large impact on coverage counter creation, this makes it easier to see whether the number of physical counters has changed.
(The highest counter ID seen in coverage maps is not necessarily the same as the number of physical counters actually used by the instrumented code, but it's the best approximation we can get from looking only at the coverage maps, and it should be reasonably accurate in most cases.)
Extracted from #131398, since I'm still considering whether to make those changes as-is, whereas this PR is useful and good on its own.
When making changes that have a large impact on coverage counter creation, this
makes it easier to see whether the number of physical counters has changed.
(The highest counter ID seen in coverage maps is not necessarily the same as
the number of physical counters actually used by the instrumented code, but
it's the best approximation we can get from looking only at the coverage maps,
and it should be reasonably accurate in most cases.)
compiletest: Simplify the choice of `--emit` mode for assembly tests
Tiny little cleanup that I noticed while working on #131524. No functional change.
Historically, the original code structure (#58791) predates the `Emit` enum (#103298), so it was manually adding `--emit` flags to the compiler invocation. But now the match can just evaluate to the appropriate `Emit` value directly.
compiletest: Remove the magic hacks for finding output with `lto=thin`
This hack was intended to handle the case where `-Clto=thin` causes the compiler to emit multiple output files (when producing LLVM-IR or assembly).
The hack only affects 4 tests, of which 3 are just meta-tests for the hack itself. The one remaining test that motivated the hack currently doesn't even need it!
(`tests/codegen/issues/issue-81408-dllimport-thinlto-windows.rs`)
This hack was intended to handle the case where `-Clto=thin` causes the
compiler to emit multiple output files (when producing LLVM-IR or assembly).
The hack only affects 4 tests, of which 3 are just meta-tests for the hack
itself. The one remaining test that motivated the hack currently doesn't even
need it!
(`tests/codegen/issues/issue-81408-dllimport-thinlto-windows.rs`)
stabilize `ci_rustc_if_unchanged_logic` test
Makes `ci_rustc_if_unchanged_logic` test more stable and re-enables it. Previously, it was expecting CI-rustc to be used all the time when there were no changes, which wasn’t always the case. Purpose of this test is making sure we don't use CI-rustc while there are changes in compiler and/or library, but we don't really need to cover cases where CI-rustc is not enabled.
Second commit was pushed for making a change in the compiler tree, so `ci_rustc_if_unchanged_logic` can be tested properly in merge CI.
Compiler & its UI tests: Rename remaining occurrences of "object safe" to "dyn compatible"
Follow-up to #130826.
Part of #130852.
1. 1st commit: Fix stupid oversights. Should've been part of #130826.
2. 2nd commit: Rename the unstable feature `object_safe_for_dispatch` to `dyn_compatible_for_dispatch`. Might not be worth the churn, you decide.
3. 3rd commit: Apply the renaming to all UI tests (contents and paths).
add test infra to explicitely test rustc with autodiff/enzyme disabled
I assume this is not what you want for now, but I'll update the PR once I understand how the ignore- directives work.
To summarize the situation, we want a feature gate test where we don't enable the autodiff feature using `#![feature(autodiff)]`. There are two situations.
1) We have a rustc which was build without autodiff support (current default): It gives one error about the feature being needed and one error about this rustc version being build without autodiff support.
2) We have a rustc which was build with autodiff support (i.e. for now a custom build): It gives one error about the feature being needed.
We have a `//`````@needs-enzyme`````` directive which we can use in revisions for the second case.
However, we have no way to specify that needs-enzyme implies that the second error should not be seen.
This ads a way of passing the following test:
```
//@ revisions: has_support no_support
//`````@[has_support]````` needs-enzyme
//`````@[no_support]````` needs-enzyme-disabled
#![crate_type = "lib"]
#[autodiff(dfoo, Reverse)]
//[has_support]~^ ERROR use of unstable library feature 'autodiff' [E0658]
//[no_support]~^^ ERROR use of unstable library feature 'autodiff' [E0658]
//[no_support]~| ERROR this rustc version does not support autodiff
fn foo() {}
```
Cherry picking this PR to my frontend pr makes the test above pass in both configurations (enzyme=true/false in config.toml).
I'm open to other changes that make this testcase pass.
r? `````@jieyouxu`````
Tracking:
- https://github.com/rust-lang/rust/issues/124509
Match std `RUSTFLAGS` for host and target for `mir-opt` test suite to fix double std build/rebuilds
Previously the bootstrap compiletest `Step::run` flow had:
```rs
// ensure that `libproc_macro` is available on the host.
builder.ensure(compile::Std::new(compiler, compiler.host));
// ...
if suite == "mir-opt" {
builder.ensure(compile::Std::new_for_mir_opt_tests(compiler, target));
} else {
builder.ensure(compile::Std::new(compiler, target));
}
```
This can cause unnecessary std rebuilds (even on the same invocation) because if host == target then `builder.ensure(compile::Std::new_for_mir_opt_tests(compiler, target))` will have different `RUSTFLAGS` than `builder.ensure(compile::Std::new(compiler, compiler.host))`.
This PR fixes that by matching up std `RUSTFLAGS` if the test suite is `mir-opt`:
```rs
if suite == "mir-opt" {
builder.ensure(compile::Std::new_for_mir_opt_tests(compiler, compiler.host));
} else {
builder.ensure(compile::Std::new(compiler, compiler.host));
}
```
This is a short-term fix, the better fix is to enforce how `RUSTFLAGS` are handled as described in https://github.com/rust-lang/rust/issues/131437#issuecomment-2401710727.
Fixes#131437.
Clippy: Backport `needless_return` fix
r? `@Manishearth`
This cherry-picks https://github.com/rust-lang/rust-clippy/pull/13464, so that it gets into master and with that into `beta` tomorrow, so that the bug in this lint doesn't hit `beta`.
Changes look quite big, but most of them are whitespace changes because of the introduction of an `_inner` function. In reality it only adds 2 checks.
Don't warn on proc macro generated code in `needless_return`
Fixes#13458Fixes#13457Fixes#13467Fixes#13479Fixes#13481Fixes#13526Fixes#13486
The fix is unfortunately a little more convoluted than just simply adding a `is_from_proc_macro`. That check *does* fix the issue, however it also introduces a bunch of false negatives in the tests, specifically when the returned expression is in a different syntax context, e.g. `return format!(..)`.
The proc macro check builds up a start and end pattern based on the HIR nodes and compares it to a snippet of the span, however that would currently fail for `return format!(..)` because we would have the patterns `("return", <something inside of the format macro>)`, which doesn't compare equal. So we now return an empty string pattern for when it's in a different syntax context.
"Hide whitespace" helps a bit for reviewing the proc macro detection change
changelog: none
disable `download-rustc` if LLVM submodule has changes in CI
We can't use CI rustc while using in-tree LLVM (which happens in LLVM submodule update PRs) and this PR handles that by ignoring CI-rustc in CI and failing in non-CI environments.
