Rollup of 12 pull requests #123968
Merged
Rollup of 12 pull requests #123968
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…cessors}` Now with GAT!
Does not necessarily change much, but we never overwrite it, so I see no reason for it to be in the `Successors` trait. (+we already have a similar `is_cyclic`)
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, 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.
Signed-off-by: mountcount <cuimoman@outlook.com>
Now with RPITIT instead of GAT!
…mponent, r=Mark-Simulacrum Distribute LLVM bitcode linker as a preview component The self-contained LLVM bitcode linker was recently added in rust-lang#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](rust-lang@f8f9a28). 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
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?
Fix some typos in doc
…mpiler-errors 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``
…n-diagnostic, r=jieyouxu Migrate some diagnostics in `rustc_resolve` to session diagnostic Hello, I migrated some diagnostics in `rustc_resolve` to session diagnostic. r? ``@davidtwco``
…errors 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.
…ieyouxu 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.
…es, r=fmease Don't leak unnameable types in `-> _` recover Fixes rust-lang#123899
…aelwoerister 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.
…r=fmease `rustc_data_structures::graph` mini refactor Who doesn't love to breathe dust from the ancient times?
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.
…boet disable create_dir_all_bare test on all(miri, windows)
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 023084804e In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Apr 15, 2024
|
Finished benchmarking commit (99d0186): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 676.684s -> 677.52s (0.12%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
rustc_resolveto session diagnostic #123896 (Migrate some diagnostics inrustc_resolveto session diagnostic)base_n. #123922 (Remove magic constants when usingbase_n.)-> _recover #123931 (Don't leak unnameable types in-> _recover)rustc_data_structures::graphmini refactor #123934 (rustc_data_structures::graphmini refactor)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup