Rollup of 12 pull requests
Successful merges:
- #123423 (Distribute LLVM bitcode linker as a preview component)
- #123548 (libtest: also measure time in Miri)
- #123666 (Fix some typos in doc)
- #123864 (Remove a HACK by instead inferring opaque types during expected/formal type checking)
- #123896 (Migrate some diagnostics in `rustc_resolve` to session diagnostic)
- #123919 (builtin-derive: tag → discriminant)
- #123922 (Remove magic constants when using `base_n`.)
- #123931 (Don't leak unnameable types in `-> _` recover)
- #123933 (move the LargeAssignments lint logic into its own file)
- #123934 (`rustc_data_structures::graph` mini refactor)
- #123941 (Fix UB in LLVM FFI when passing zero or >1 bundle)
- #123957 (disable create_dir_all_bare test on all(miri, windows))
r? `@ghost`
`@rustbot` modify labels: rollup
Fix UB in LLVM FFI when passing zero or >1 bundle
Rust passes a `*const &OperandBundleDef` to these APIs, usually from a `Vec<&OperandBundleDef>` or so. Previously we were dereferencing that pointer and passing it to the ArrayRef constructor with some length (N).
This meant that if the length was 0, we were dereferencing a pointer to nowhere (if the vector on the Rust side didn't actually get allocated or so), and if the length was >1 then loading the *second* element somewhere in LLVM would've been reading past the end.
Since Rust can't hold OperandBundleDef by-value we're forced to indirect through a vector that copies out the OperandBundleDefs from the by-reference list on the Rust side in order to match the LLVM expected API.
move the LargeAssignments lint logic into its own file
The collector is a file full of very subtle logic, so let's try to keep that separate from the logic that only serves to implement this lint.
Remove magic constants when using `base_n`.
Some use cases of `base_n` use number literals instead of the predefined constants. The latter are more descriptive so it might be better to use those instead.
builtin-derive: tag → discriminant
As far as I can tell, all of this operates on the discriminant, not the tag. After all, with something like `Option<&T>`, the "tag" of the `Some` variant is basically just the reference value, which is never what you want to compare when figuring out which variant the enum is in.
See [here](https://rustc-dev-guide.rust-lang.org/appendix/glossary.html) for an explanation of the difference between tag and discriminant.
Migrate some diagnostics in `rustc_resolve` to session diagnostic
Hello, I migrated some diagnostics in `rustc_resolve` to session diagnostic.
r? ``@davidtwco``
Remove a HACK by instead inferring opaque types during expected/formal type checking
I was wondering why I couldn't come up with a test that hits the code path of the argument check checking the types we inferred from the return type... Turns out we reject those attempts early during fudging.
I have absolutely no information for you as to what kind of type inference changes this may incur, but I think we should just land this out of two reasons:
* had I found the other place to use opaque type inference on before I added the hack, we'd be using that today and this PR would never have happened
* if it is possible to hit this path, it requires some god awful recursive RPIT logic that I doubt anyone would have written without actively trying to write obscure code
r? ``@ghost``
libtest: also measure time in Miri
A long time ago we disabled timekeeping of the default test harness in Miri, as otherwise it would fail to run without `-Zmiri-disable-isolation`. However, since then Miri gained a "fake clock" that lets it present some deterministic notion of time when isolation is enabled.
So we could now let libtest do timekeeping again when running in Miri. That's nice as it can help detect tests that run too long. However it can also be confusing as the results with isolation can be quite different than the real time.
``@rust-lang/miri`` what do you think?
Distribute LLVM bitcode linker as a preview component
The self-contained LLVM bitcode linker was recently added in #117458. It is currently only in use to link the Nvidia ptx assembly tests when running rustc tests (local or CI). In fact, the linker itself is currently only usable for the `nvptx64-nvidia-cuda` target, but more targets will be supported in the future.
The reason a new linker was needed for the ptx format is that the [old one](https://github.com/denzp/rust-ptx-linker) has not been updated the last few years. It worked fine for a while, but as LLVM changed it broke and the nvptx tests was [disabled in rustc back in 2019](f8f9a2869c). It was ad-hoc patched and have been used in a sub-optimal state by the community until now.
If this PR is merged, the LLVM bitcode linker will be distributed as a preview component that can be used as a replacement for the old ptx-linker for development in addition to rustc tests. In addition to installing the `llvm-bitcode-linker` component, also the `llvm-tools` component must be installed as the `llvm-bitcode-linker` works by calling llvm tools.
Even though the LLVM bitcode linker is in its early stages it already now provides a lot of value over the old ptx-linker just by working and using up-to-date llvm tooling. By shipping it as a component it will be easier to gather user experience and improving it.
``@petrochenkov`` when installing as a component it will be installed in the self-contained folder and will not work with `-Clink-self-contained=no` (although for some reason I expect to be a bug `-Clink-self-contained=-linker` doesn't properly disable it). However, when building using `x.py build` it will be placed in the `lib/rustlib/<target>/bin` directory and will be available for internal tests even if `-Clink-self-contained=no` is passed.
CC: ``@Mark-Simulacrum`` as I very briefly discussed it with you some months ago https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/.E2.9C.94.20How.20to.20ship.20a.20new.20tool.20.28embedded.20linker.29.20to.20users.3F
Handle Miri sysroot entirely outside the Miri driver
(Extracted from https://github.com/rust-lang/miri/pull/3409)
This entirely moves the responsibility of setting miri-sysroot to whatever *invokes* the Miri driver. cargo-miri knows whether it is inside rustdoc or not and can adjust accordingly. I previously avoided doing that because there are a bunch of places that are invoking the driver (cargo-miri, the ui test suite, `./miri run`, `./x.py run miri`) and they all need to be adjusted now. But it is also somewhat less fragile as we usually have more information there -- and we can just decide that `./miri run file.rs --sysroot path` is not supported. The advantage of this is that the driver is reasonably clean and doesn't need magic environment variables like MIRI_SYSROOT, and we don't have to fight rustc_driver to use a different default sysroot. Everything is done in cargo-miri (and the other much simpler driver wrappers) where it can hopefully be debugged much better.
Miri on Windows: run .CRT$XLB linker section on thread-end
Hopefully fixes https://github.com/rust-lang/rust/issues/123583
First commit is originally by `@bjorn3`
r? `@oli-obk`
Cc `@ChrisDenton`
Better inline preview for postfix completion
Better inline preview for postfix completion, a proper implementation of c5686c8941.
Here editors may filter completion item with the text within `delete_range`, so we need to include the `receiver text` in the `lookup` (aka `FilterText` in LSP spec) for editors to find the completion item. (See https://github.com/rust-lang/rust-analyzer/issues/17036#issuecomment-2056614180, Thanks to [pascalkuthe](https://github.com/pascalkuthe))
