…clif-2024-09-22

…pal trait def id are truly NOPs

Fixes rust-lang/rustc_codegen_cranelift#1394

- fix for divergence
- fix error message
- fix another cranelift test
- fix some cranelift things
- don't set the NORETURN option for naked asm
- fix use of naked_asm! in doc comment
- fix use of naked_asm! in run-make test
- use `span_bug` in unreachable branch

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).

It is only necessary in dist/lib/rustlib/*/lib anymore. The jit mode now
correctly find it there too.

As part of the "arbitrary self types v2" project, we are going to
replace the current `Receiver` trait with a new mechanism based on a
new, different `Receiver` trait.

This PR renames the old trait to get it out the way. Naming is hard.
Options considered included:
* HardCodedReceiver (because it should only be used for things in the
  standard library, and hence is sort-of hard coded)
* LegacyReceiver
* TargetLessReceiver
* OldReceiver

These are all bad names, but fortunately this will be temporary.
Assuming the new mechanism proceeds to stabilization as intended, the
legacy trait will be removed altogether.

Although we expect this trait to be used only in the standard library,
we suspect it may be in use elsehwere, so we're landing this change
separately to identify any surprising breakages.

It's known that this trait is used within the Rust for Linux project; a
patch is in progress to remove their dependency.

This is a part of the arbitrary self types v2 project,
rust-lang/rfcs#3519
rust-lang#44874

r? @wesleywiser

Don't panic about debug info for Arm64 Windows unwind info

Fundamentally, we have *three* disjoint categories of functions:
1. const-stable functions
2. private/unstable functions that are meant to be callable from const-stable functions
3. functions that can make use of unstable const features

This PR implements the following system:
- `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions.
- `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category.
- `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls.

Also, several holes in recursive const stability checking are being closed.
There's still one potential hole that is hard to avoid, which is when MIR
building automatically inserts calls to a particular function in stable
functions -- which happens in the panic machinery. Those need to *not* be
`rustc_const_unstable` (or manually get a `rustc_const_stable_indirect`) to be
sure they follow recursive const stability. But that's a fairly rare and special
case so IMO it's fine.

The net effect of this is that a `#[unstable]` or unmarked function can be
constified simply by marking it as `const fn`, and it will then be
const-callable from stable `const fn` and subject to recursive const stability
requirements. If it is publicly reachable (which implies it cannot be unmarked),
it will be const-unstable under the same feature gate. Only if the function ever
becomes `#[stable]` does it need a `#[rustc_const_unstable]` or
`#[rustc_const_stable]` marker to decide if this should also imply
const-stability.

Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to
use unstable const lang features (including intrinsics), or (b) `#[stable]`
functions that are not yet intended to be const-stable. Adding
`#[rustc_const_stable]` is only needed for functions that are actually meant to
be directly callable from stable const code. `#[rustc_const_stable_indirect]` is
used to mark intrinsics as const-callable and for `#[rustc_const_unstable]`
functions that are actually called from other, exposed-on-stable `const fn`. No
other attributes are required.

- removed extra bits from predicates queries that are no longer needed in the new system
- removed the need for `non_erasable_generics` to take in tcx and DefId, removed unused arguments in callers

…ler-errors

Effects cleanup

- removed extra bits from predicates queries that are no longer needed in the new system
- removed the need for `non_erasable_generics` to take in tcx and DefId, removed unused arguments in callers

r? compiler-errors

The output of `rustc -C help` generally has one option per line. There was one
exception because of a (presumably) forgotten line continuation escape.

…clif-2024-11-02

We don't see a reason to explicitly pass the default here, so just use
the default instead of explicitly passing it and needing an ifdef.

@rustbot label: +llvm-main

…ss35

Docs: added brief colon explanation

rust-lang#131865
(this is my first attempt at contributing, feedback is welcome)

…=cuviper

PassWrapper: adapt for llvm/llvm-project@b01e2a8b5620466c3b

A boolean turned into an enum. None matches the old behavior of false, so we pass that.

```@rustbot``` label: +llvm-main

…r=jieyouxu

coverage: Regression test for inlining into an uninstrumented crate

Regression test for rust-lang#132395, after I was able to figure out a simple way to reproduce it. See also rust-lang#132436.

In addition to confirming that there is no ICE, this test also demonstrates that the affected code is undercounted, because executing the inlined copy doesn't increment coverage counters.

…manieu

get rid of a whole bunch of unnecessary rustc_const_unstable attributes

In general, when a `const fn` is still unstable, it doesn't need a `#[rustc_const_unstable]` attribute. The only exception is functions that internally use things that can't be used in stable const fn yet.

So this gets rid of a whole bunch of `#[rustc_const_unstable]` in libcore.

unicode_data.rs: show command for generating file

rust-lang#131647 made this an easily runnable tool, now we just have to mention that in the comment. :)

Fixes rust-lang#131640.

better test for const HashMap; remove const_hash leftovers

The existing `const_with_hasher` test is kind of silly since the HashMap it constructs can never contain any elements. So this adjusts the test to construct a usable HashMap, which is a bit non-trivial since the default hash builder cannot be built in `const`. `BuildHasherDefault::new()` helps but is unstable (rust-lang#123197), so we also have a test that does not involve that type.

The second commit removes the last remnants of rust-lang#104061, since they aren't actually useful -- without const traits, you can't do any hashing in `const`.

Cc `@rust-lang/libs-api` `@rust-lang/wg-const-eval`
Closes rust-lang#104061
Related to rust-lang#102575

…ouxu

Port most of `--print=target-cpus` to Rust

The logic and formatting needed by `--print=target-cpus` has historically been carried out in C++ code. Originally it used `printf` to write directly to the console, but later it switched over to writing to a `std::ostringstream` and then passing its buffer to a callback function pointer.

This PR replaces that C++ code with a very simple function that writes a list of CPU names to a `&RustString`, with the rest of the logic and formatting being handled by ordinary safe Rust code.

NFC add known bug nr to test

r? ```@jieyouxu```

…r=compiler-errors

make codegen help output more consistent

The output of `rustc -C help` generally has one option per line. There was one exception because of a (presumably) forgotten line continuation escape.

…ompiler-errors

Added regression test for generics index out of bounds

Added a regression test for  rust-lang#117446
This ICE was fixed in Rust 1.75 but a regression test was never added.

This PR adds a UI test with a reduced version of the original bug report that does not rely on external crates.

…bjorn3

Subtree sync for rustc_codegen_cranelift

The highlight this time is an update to Cranelift 0.113,

r? `@ghost`

`@rustbot` label +A-codegen +A-cranelift +T-compiler

… r=jieyouxu

Use `*_opt` typeck results fns to not ICE in fallback suggestion

Self-explanatory. Fixes rust-lang#132517.

Do not format generic consts

We introduced **nightly support** for generic const items in rust-lang#113522, but formatting of consts was not modified. Making them format *correctly* is hard, so let's just bail formatting them so we don't accidentally strip their generics and where clauses. This is essentially no-op formatting for generic const items.

r? `@calebcartwright` or `@ytmimi`