-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 11 pull requests #126369
Rollup of 11 pull requests #126369
Conversation
This is the first time we have a lint with configuration exposed in `Cargo.toml`. When this was done, interest was expressed in using this for other cases in the future. To this end, we need to make the documentation for the lint configuration discoverable from the documentation for that lint.
At the suggestion of @Urgau
Since we support solaris 11 and macOs Sierra as minimum, we can get rid of the runtime overhead.
There is now no way to create a TyConst from an integer, so I propose making this method public unless there was a reason for keeping it otherwise.
…eyouxu Migrate `run-make/pgo-branch-weights` to `rmake` Part of rust-lang#121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html). This is a scary one and I expect things to break. Set as draft, because this isn't ready. - [x] There is this comment here, which suggests the test is excluded from the testing process due to a platform specific issue? I can't see anything here that would cause this test to not run... > // FIXME(mati865): MinGW GCC miscompiles compiler-rt profiling library but with Clang it works // properly. Since we only have GCC on the CI ignore the test for now." EDIT: This is specific to Windows-gnu. - [x] The Makefile has this line: ``` ifneq (,$(findstring x86,$(TARGET))) COMMON_FLAGS=-Clink-args=-fuse-ld=gold ``` I honestly can't tell whether this is checking if the target IS x86, or IS NOT. EDIT: It's checking if it IS x86. - [x] I don't know why the Makefile was trying to pass an argument directly in the Makefile instead of setting that "aaaaaaaaaaaa2bbbbbbbbbbbb2bbbbbbbbbbbbbbbbcc" input as a variable in the Rust program directly. I changed that, let me know if that was wrong. - [x] Trying to rewrite `cat "$(TMPDIR)/interesting.ll" | "$(LLVM_FILECHECK)" filecheck-patterns.txt` resulted in some butchery. For starters, in `tools.mk`, LLVM_FILECHECK corrects its own backslashes on Windows distributions, but there is no further mention of it, so I assume this is a preset environment variable... but is it really? Then, the command itself uses a Standard Input and a passed input file as an argument simultaneously, according to the [documentation](https://llvm.org/docs/CommandGuide/FileCheck.html#synopsis). try-job: aarch64-gnu
…, r=jieyouxu Rewrite `symlinked-extern`, `symlinked-rlib` and `symlinked-libraries` `run-make` tests in `rmake.rs` format Part of rust-lang#121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html). try-job: x86_64-msvc
…=lcnr Walk into alias-eq nested goals even if normalization fails Somewhat broken due to the fact that we don't handle aliases well, nor do we handle ambiguities well. Still want to put up this incremental piece, since it improves type errors for projections whose trait refs are not satisfied. r? lcnr
…=jackh726 Harmonize using root or leaf obligation in trait error reporting When rust-lang#121826 changed the error reporting to use root obligation and not the leafmost obligation, it didn't actually make sure that all the other diagnostics helper functions used the right obligation. Specifically, when reporting similar impl candidates we are looking for impls of the root obligation, but trying to match them against the trait ref of the leaf obligation. This does a few other miscellaneous changes. There's a lot more clean-up that could be done here, but working with this code is really grief-inducing due to how messy it has become over the years. Someone really needs to show it love. 😓 r? `@estebank` Fixes rust-lang#126129
…rors Urls to docs in rust_hir <!-- If this PR is related to an unstable feature or an otherwise tracked effort, please link to the relevant tracking issue here. If you don't know of a related tracking issue or there are none, feel free to ignore this. This PR will get automatically assigned to a reviewer. In case you would like a specific user to review your work, you can assign it to them by using r? <reviewer name> -->
Add Option::is_none_or ACP: rust-lang/libs-team#212
Add test for walking order dependent opaque type behaviour r? ``@lcnr`` adding the test for your comment here: https://github.com/rust-lang/rust/pull/122366/files#r1521124754
std::unix::fs::link using direct linkat call for Solaris. Since we support solaris 11 as minimum, we can get rid of the runtime overhead.
Move `MatchAgainstFreshVars` to old solver Small change I noticed when trying to uplift the relations to the new trait solver.
docs(rustc): Improve discoverable of Cargo docs In preparing Cargo's blog post for 1.80, I tried to find the documentation for the lint configuration and I couldn't. The link is only visible from the lint itself, which isn't where I started, and the side bar, which was collapsed for me. The first place I went was the docs for `unexpected_cfgs` because this is configuration for that lint. If using lint configuration were a one off, I could see skipping it here. However, when we discussed this with at least one T-compiler member, there was interest in using this for other lints in the future. To that end, it seems like we should be exposing this with the lint itself. The second place I checked was the `check-cfg` documentation. This now has a call out for the sub-page.
Make `try_from_target_usize` method public There is now no way to create a TyConst from an integer, so I propose making this method public unless there was a reason for keeping it otherwise.
If this fails it will probably be on the rmake PRs but there's no obvious reason to not give them a try in a rollup since it will be their first CI failure either way, I think. @bors r+ rollup=never p=11 |
by which I mean full merge tests, not the try builds, though the fact that they have been diligently checked with try-builds on the likely-to-cause-issues targets is a good reason to be optimistic. and a failure is a failure, ultimately. |
…kingjubilee Rollup of 11 pull requests Successful merges: - rust-lang#125165 (Migrate `run-make/pgo-branch-weights` to `rmake`) - rust-lang#125674 (Rewrite `symlinked-extern`, `symlinked-rlib` and `symlinked-libraries` `run-make` tests in `rmake.rs` format) - rust-lang#125688 (Walk into alias-eq nested goals even if normalization fails) - rust-lang#126142 (Harmonize using root or leaf obligation in trait error reporting) - rust-lang#126303 (Urls to docs in rust_hir) - rust-lang#126328 (Add Option::is_none_or) - rust-lang#126337 (Add test for walking order dependent opaque type behaviour) - rust-lang#126351 (std::unix::fs::link using direct linkat call for Solaris.) - rust-lang#126353 (Move `MatchAgainstFreshVars` to old solver) - rust-lang#126356 (docs(rustc): Improve discoverable of Cargo docs) - rust-lang#126362 (Make `try_from_target_usize` method public) r? `@ghost` `@rustbot` modify labels: rollup
💔 Test failed - checks-actions |
Successful merges:
run-make/pgo-branch-weights
tormake
#125165 (Migraterun-make/pgo-branch-weights
tormake
)symlinked-extern
,symlinked-rlib
andsymlinked-libraries
run-make
tests inrmake.rs
format #125674 (Rewritesymlinked-extern
,symlinked-rlib
andsymlinked-libraries
run-make
tests inrmake.rs
format)MatchAgainstFreshVars
to old solver #126353 (MoveMatchAgainstFreshVars
to old solver)try_from_target_usize
method public #126362 (Maketry_from_target_usize
method public)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup