…clif-2024-05-13

Remove `Rvalue::CheckedBinaryOp`

Zulip conversation: <https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/intrinsics.20vs.20binop.2Funop/near/438729996>
cc `@RalfJung`

While it's a draft,
r? ghost

…, r=RalfJung,nikic

compiler: add simd_ctpop intrinsic

Fairly straightforward addition.

cc `@rust-lang/opsem` new (extremely boring) intrinsic

Typical uses of ThinLTO don't have any use for this as a standalone
file, but distributed ThinLTO uses this to make the linker phase more
efficient. With clang you'd do something like `clang -flto=thin
-fthin-link-bitcode=foo.indexing.o -c foo.c` and then get both foo.o
(full of bitcode) and foo.indexing.o (just the summary or index part of
the bitcode). That's then usable by a two-stage linking process that's
more friendly to distributed build systems like bazel, which is why I'm
working on this area.

I talked some to @teresajohnson about naming in this area, as things
seem to be a little confused between various blog posts and build
systems. "bitcode index" and "bitcode summary" tend to be a little too
ambiguous, and she tends to use "thin link bitcode" and "minimized
bitcode" (which matches the descriptions in LLVM). Since the clang
option is thin-link-bitcode, I went with that to try and not add a new
spelling in the world.

Per @dtolnay, you can work around the lack of this by using `lld
--thinlto-index-only` to do the indexing on regular .o files of
bitcode, but that is a bit wasteful on actions when we already have all
the information in rustc and could just write out the matching minimized
bitcode. I didn't test that at all in our infrastructure, because by the
time I learned that I already had this patch largely written.

The standard library now has the right configs in it's Cargo.toml

rustc_codegen_llvm: add support for writing summary bitcode

Typical uses of ThinLTO don't have any use for this as a standalone file, but distributed ThinLTO uses this to make the linker phase more efficient. With clang you'd do something like `clang -flto=thin -fthin-link-bitcode=foo.indexing.o -c foo.c` and then get both foo.o (full of bitcode) and foo.indexing.o (just the summary or index part of the bitcode). That's then usable by a two-stage linking process that's more friendly to distributed build systems like bazel, which is why I'm working on this area.

I talked some to `@teresajohnson` about naming in this area, as things seem to be a little confused between various blog posts and build systems. "bitcode index" and "bitcode summary" tend to be a little too ambiguous, and she tends to use "thin link bitcode" and "minimized bitcode" (which matches the descriptions in LLVM). Since the clang option is thin-link-bitcode, I went with that to try and not add a new spelling in the world.

Per `@dtolnay,` you can work around the lack of this by using `lld --thinlto-index-only` to do the indexing on regular .o files of bitcode, but that is a bit wasteful on actions when we already have all the information in rustc and could just write out the matching minimized bitcode. I didn't test that at all in our infrastructure, because by the time I learned that I already had this patch largely written.

This replaces the drop_in_place reference with null in vtables. On
librustc_driver.so, this drops about ~17k dynamic relocations from the
output, since many vtables can now be placed in read-only memory, rather
than having a relocated pointer included.

This makes a tradeoff by adding a null check at vtable call sites.
That's hard to avoid without changing the vtable format (e.g., to use a
pc-relative relocation instead of an absolute address, and avoid the
dynamic relocation that way). But it seems likely that the check is
cheap at runtime.

Add an intrinsic for `ptr::metadata`

The follow-up to rust-lang#123840, so we can remove `PtrComponents` and `PtrRepr` from libcore entirely (well, after a bootstrap update).

As discussed in <https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/.60ptr_metadata.60.20in.20MIR/near/435637808>, this introduces `UnOp::PtrMetadata` taking a raw pointer and returning the associated metadata value.

By no longer going through a `union`, this should also help future PRs better optimize pointer operations.

r? ``@oli-obk``

Fixes rust-lang/rustc_codegen_cranelift#1493

Show files produced by `--emit foo` in json artifact notifications

Right now it is possible to ask `rustc` to save some intermediate representation into one or more files with `--emit=foo`, but figuring out what exactly was produced is difficult. This pull request adds information about `llvm_ir` and `asm` intermediate files into notifications produced by `--json=artifacts`.

Related discussion: https://internals.rust-lang.org/t/easier-access-to-files-generated-by-emit-foo/20477

Motivation - `cargo-show-asm` parses those intermediate files and presents them in a user friendly way, but right now I have to apply some dirty hacks. Hacks make behavior confusing: hintron/computer-enhance#35

This pull request introduces a new behavior: now `rustc` will emit a new artifact notification for every artifact type user asked to `--emit`, for example for `--emit asm` those will include all the `.s` files.

Most users won't notice this behavior, to be affected by it all of the following must hold:
- user must use `rustc` binary directly (when `cargo` invokes `rustc` - it consumes artifact notifications and doesn't emit anything)
- user must specify both `--emit xxx` and `--json artifacts`
- user must refuse to handle unknown artifact types
- user must disable incremental compilation (or deal with it better than cargo does, or use a workaround like `save-temps`) in order not to hit rust-lang#88829 / rust-lang#89149

…LLVM specific

cc rust-lang/rustc_codegen_cranelift#1494

cc rust-lang#125493

add `llvm.x86.sse2.cvtps2dq`

PR rust-lang#125443 will reformat all the use declarations in the repo. This
would break a patch kept in `rustc_codegen_cranelift` that gets applied
to `library/std/src/sys/pal/windows/rand.rs`.

So this commit formats the use declarations in
`library/std/src/sys/pal/windows/rand.rs` in advance of rust-lang#125443 and
updates the patch file accordingly.

The motivation is that rust-lang#125443 is a huge change and we want to get
fiddly little changes like this out of the way so it can be nothing more
than an `x fmt --all`.

We already do this for a number of crates, e.g. `rustc_middle`,
`rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`.

For the ones we don't, in many cases the attributes are a mess.
- There is no consistency about order of attribute kinds (e.g.
  `allow`/`deny`/`feature`).
- Within attribute kind groups (e.g. the `feature` attributes),
  sometimes the order is alphabetical, and sometimes there is no
  particular order.
- Sometimes the attributes of a particular kind aren't even grouped
  all together, e.g. there might be a `feature`, then an `allow`, then
  another `feature`.

This commit extends the existing sorting to all compiler crates,
increasing consistency. If any new attribute line is added there is now
only one place it can go -- no need for arbitrary decisions.

Exceptions:
- `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`,
  because they have no crate attributes.
- `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's
  ignored in `rustfmt.toml`).

…in a hidden type

… r=davidtwco

Use `tidy` to sort crate attributes for all compiler crates.

We already do this for a number of crates, e.g. `rustc_middle`, `rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`.

For the ones we don't, in many cases the attributes are a mess.
- There is no consistency about order of attribute kinds (e.g. `allow`/`deny`/`feature`).
- Within attribute kind groups (e.g. the `feature` attributes), sometimes the order is alphabetical, and sometimes there is no particular order.
- Sometimes the attributes of a particular kind aren't even grouped all together, e.g. there might be a `feature`, then an `allow`, then another `feature`.

This commit extends the existing sorting to all compiler crates, increasing consistency. If any new attribute line is added there is now only one place it can go -- no need for arbitrary decisions.

Exceptions:
- `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`, because they have no crate attributes.
- `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's ignored in `rustfmt.toml`).

r? `@davidtwco`

…kingjubilee

Rollup of 16 pull requests

Successful merges:

 - rust-lang#123374 (DOC: Add FFI example for slice::from_raw_parts())
 - rust-lang#124514 (Recommend to never display zero disambiguators when demangling v0 symbols)
 - rust-lang#125978 (Cleanup: HIR ty lowering: Consolidate the places that do assoc item probing & access checking)
 - rust-lang#125980 (Nvptx remove direct passmode)
 - rust-lang#126187 (For E0277 suggest adding `Result` return type for function when using QuestionMark `?` in the body.)
 - rust-lang#126210 (docs(core): make more const_ptr doctests assert instead of printing)
 - rust-lang#126249 (Simplify `[T; N]::try_map` signature)
 - rust-lang#126256 (Add {{target}} substitution to compiletest)
 - rust-lang#126263 (Make issue-122805.rs big endian compatible)
 - rust-lang#126281 (set_env: State the conclusion upfront)
 - rust-lang#126286 (Make `storage-live.rs` robust against rustc internal changes.)
 - rust-lang#126287 (Update a cranelift patch file for formatting changes.)
 - rust-lang#126301 (Use `tidy` to sort crate attributes for all compiler crates.)
 - rust-lang#126305 (Make PathBuf less Ok with adding UTF-16 then `into_string`)
 - rust-lang#126310 (Migrate run make prefer rlib)
 - rust-lang#126314 (fix RELEASES: we do not support upcasting to auto traits)

r? `@ghost`
`@rustbot` modify labels: rollup

Only compute vtable information during codegen

This PR removes vtable information from the `Object` and `TraitUpcasting` candidate sources in the trait solvers, and defers the computation of relevant information to `Instance::resolve`. This is because vtables really aren't a thing in the trait world -- they're an implementation detail in codegen.

Previously it was just easiest to tangle this information together since we were already doing the work of looking at all the supertraits in the trait solver, and specifically because we use traits to represent when it's possible to call a method via a vtable (`Object` candidate) and do upcasting (`Unsize` candidate). but I am somewhat suspicious we're doing a *lot* of extra work, especially in polymorphic contexts, so let's see what perf says.

This paves the way for tracking more state (e.g. error tainting) in the diagnostic context handle

Fix varargs support on `aarch64-apple-darwin`

Closes rust-lang/rustc_codegen_cranelift#1248

There is no idx in the function signature.

As the comment says, this lint "is mostly historical, and not
particularly useful". It's not worth keeping it around.

This way all UnwindContext::add_function calls can be done automatically
in a single place.

This fixes a crash with macOS's ld-prime on arm64.

Fixes rust-lang/rustc_codegen_cranelift#1501

the `expose_provenance` method does not require `T: Sized`

The linker issue with XCode 15 has been fixed.

The new enum `DeclareLetBindings` has three variants:
- `Yes`: Declare `let` bindings as normal, for `if` conditions.
- `No`: Don't declare bindings, for match guards and let-else.
- `LetNotPermitted`: Assert that `let` expressions should not occur.

The previous boolean used `true` to indicate that storage-live should _not_ be
emitted, so all occurrences of `Yes` and `No` should be the logical opposite of
the previous value.

These particular callers don't actually use the returned macro information, so
they can use a simpler span-unexpansion function that doesn't return it.

compiler should not suggest nonsensical signatures, original suggestion was

error[E0308]: mismatched types
 --> src/lib.rs:3:31
  |
3 | fn select<F, I>(filter: F) -> Select<F, I> {
  |    ------                     ^^^^^^^^^^^^ expected `Select<F, I>`, found `()`
  |    |
  |    implicitly returns `()` as its body has no tail or `return` expression
  |
  = note: expected struct `Select<F, I>`
          found unit type `()`

error[E0282]: type annotations needed for `Select<{closure@src/lib.rs:8:22: 8:25}, I>`
 --> src/lib.rs:8:9
  |
8 |     let lit = select(|x| match x {
  |         ^^^
  |
help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified
  |
8 |     let lit: Select<{closure@src/lib.rs:8:22: 8:25}, I> = select(|x| match x {
  |            ++++++++++++++++++++++++++++++++++++++++++++

Some errors have detailed explanations: E0282, E0308.
For more information about an error, try `rustc --explain E0282`.

…clif-2024-06-30

…r=lcnr

Remove the `box_pointers` lint.

As the comment says, this lint "is mostly historical, and not particularly useful". It's not worth keeping it around.

r? `@estebank`

…umentation, r=Amanieu

Fix simd_gather documentation

There is no idx in the function signature.

Replace some magic booleans in match-lowering with enums

This PR takes some boolean arguments used by the match-lowering code, and replaces them with dedicated enums that more clearly express their effect, while also making it much easier to find how each value is ultimately used.

…trieb

small correction to fmt::Pointer impl

~~The `addr` method does not require `T: Sized`, and is preferred for use over `expose_provenance`.~~
`expose_provenance` does not require `T: Sized`.

coverage: Avoid getting extra unexpansion info when we don't need it

Several callers of `unexpand_into_body_span_with_visible_macro` would immediately discard the additional macro-related information, which is wasteful. We can avoid this by having them instead call a simpler method that just returns the span they care about.

This PR also moves the relevant functions out of `coverage::spans::from_mir` and into a new submodule `coverage::unexpand`, so that calling them from `coverage::mappings` is less awkward.

There should be no actual changes to coverage-instrumentation output, as demonstrated by the absence of test updates.

Add a regression test for rust-lang#123630

Fixes rust-lang#123630

compiler should not suggest nonsensical signatures, original suggestion was

```
error[E0308]: mismatched types
 --> src/lib.rs:3:31
  |
3 | fn select<F, I>(filter: F) -> Select<F, I> {
  |    ------                     ^^^^^^^^^^^^ expected `Select<F, I>`, found `()`
  |    |
  |    implicitly returns `()` as its body has no tail or `return` expression
  |
  = note: expected struct `Select<F, I>`
          found unit type `()`

error[E0282]: type annotations needed for `Select<{closure@src/lib.rs:8:22: 8:25}, I>`
 --> src/lib.rs:8:9
  |
8 |     let lit = select(|x| match x {
  |         ^^^
  |
help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified
  |
8 |     let lit: Select<{closure@src/lib.rs:8:22: 8:25}, I> = select(|x| match x {
  |            ++++++++++++++++++++++++++++++++++++++++++++

Some errors have detailed explanations: E0282, E0308. For more information about an error, try `rustc --explain E0282`.
```

…gs, r=Kobzol

Improve `run-make-support` library `args` API

It allows to pass both `Vec` and slices, which makes it much better (for me at least 😉).

r? `@Kobzol`

…bjorn3

Subtree sync for rustc_codegen_cranelift

The main highlight this time is support for arm64 macOS in cg_clif. A future PR will enable distributing it as rustup component.

r? `@ghost`

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