-
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 7 pull requests #108386
Rollup of 7 pull requests #108386
Conversation
Make sure to quote batch file arguments that contain command prompt special characters. Additionally add `/d` command line parameter to disable any commands that may change the way variable expansion works.
…rmat in items fields
I always have to look at the git blame for that file to find the git command in the commit message (luckily that commit isn't in the file :D), putting it directly in the file makes it easier to find. Maybe we should mention the config in some other place as well.
This makes the check for when associated type bounds more accurate
…unds-in-bad-position, r=cjgillot Ban associated type bounds in bad positions We should not try to lower associated type bounds into TAITs in positions where `impl Trait` is not allowed (except for in `where` clauses, like `where T: Trait<Assoc: Bound>`). This is achieved by using the same `rustc_ast_lowering` machinery as impl-trait does to characterize positions as universal/existential/disallowed. Fixes rust-lang#106077 Split out the first commit into rust-lang#108066, since it's not really related.
Correctly handle aggregates in DataflowConstProp The previous implementation from rust-lang#107411 flooded target of an aggregate assignment with `Bottom`, corresponding to the `deinit` that the interpreter does. As a consequence, when assigning `target = Enum::Variant#i(...)` all the `(target as Variant#j)` were at `Bottom` while they should have been `Top`. This PR replaces that flooding with `Top`. Aside, it corrects a second bug where the wrong place would be used to assign to enum variant fields, resulting to nothing happening. Fixes rust-lang#108166
Windows: Quote more batch file arguments Make sure to always quote batch file arguments that contain command prompt special characters. Additionally add `/d` command line parameter to disable any autorun scripts that may change the way variable expansion works. This makes it more consistent across systems and may help avoid surprises. ## Background Info [`CreateProcess`](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw) with the `lpApplicationName` set can only be used to run `.exe` files and not script files such as `.bat`. However, for historical reasons, we do have special handling so that `.bat` files will be correctly run with `cmd.exe` as the application. In Windows, command line arguments are passed as a single string (not an array). Applications can parse this string however they like but most follow the standard MSVC C/C++ convention. But `cmd.exe` uses different argument parsing rules to other Windows programs (because it emulates old DOS). This PR aims to help smooth over some of the differences. r? libs
…rts2, r=notriddle rustdoc: Prevent duplicated imports Fixes rust-lang#108163. Interestingly enough, the AST is providing us an import for each corresponding item, even though the `Res` links to multiple ones each time, which leaded to the same import being duplicated. So in this PR, I decided to prevent the add of the import before the clean pass. However, I originally took a different path by instead filtering after cleaning the path. You can see it [here](https://github.com/rust-lang/rust/compare/master...GuillaumeGomez:rust:fix-duplicated-imports?expand=1). Only the second commit differs. I think this approach is better though, but at least we can compare both if we want. The first commit adds the check for duplicated items in the rustdoc-json output as asked in rust-lang#108163. cc `@aDotInTheVoid` r? `@notriddle`
…ogfooding, r=oli-obk Use associated type bounds in some places in the compiler Use associated type bounds for some nested `impl Trait<Assoc = impl Trait2>` cases. I'm generally keen to introduce new lang features that are more mature into the compiler, but maybe let's see what others think? Side-note: I was surprised that the only use-cases of nested impl trait in the compiler are just iterator related?!
…commits, r=compiler-errors Add git config command to `.git-blame-ignore-revs` I always have to look at the git blame for that file to find the git command in the commit message (luckily that commit isn't in the file :D), putting it directly in the file makes it easier to find. Maybe we should mention the config in some other place as well.
…ompiler-errors hir-analysis: make where-clause-on-main diagnostic translatable
@bors r+ rollup=never p=7 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR: previous master: 8b1dbf728a In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (eb909d8): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
@rustbot label: +perf-regression-triaged |
Successful merges:
.git-blame-ignore-revs
#108358 (Add git config command to.git-blame-ignore-revs
)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup