-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 #94824
Rollup of 7 pull requests #94824
Conversation
PR rust-lang#93918 made it so that `-static-libstdc++` was only set in one place, and was only set during linking, but accidentally also made it so that it is no longer passed when building LLD or sanitizers, only when building LLVM itself. This moves the logic for setting `-static-libstdc++` in the linker flags back to `configure_cmake` so that it takes effect for all CMake invocations in `native.rs`. As a side-effect, this also causes libstdc++ to be statically compiled into sanitizers and LLD if `llvm-tools-enabled` is set but `llvm-static-stdcpp` is not, even though previously it was only linked statically if `llvm-static-stdcpp` was set explicitly. But that seems more like the expected behavior anyway.
This change causes unstable lints to be ignored if the `unknown_lints` lint is allowed. To achieve this, it also changes lints to apply as soon as they are processed. Previously, lints in the same set were processed as a batch and then all simultaneously applied. Implementation of rust-lang/compiler-team#469
This also affects the `non_exhaustive_omitted_patterns` and `must_not_suspend` lints as they are not stable. This also changes the diagnostic level to pull from `unknown_lints` instead of always being allow or deny.
This updates the standard library's documentation to use the new syntax. The documentation is worthwhile to update as it should be more idiomatic (particularly for features like this, which are nice for users to get acquainted with). The general codebase is likely more hassle than benefit to update: it'll hurt git blame, and generally updates can be done by folks updating the code if (and when) that makes things more readable with the new format. A few places in the compiler and library code are updated (mostly just due to already having been done when this commit was first authored).
…-format!-macros, r=Mark-Simulacrum Use modern formatting for format! macros This updates the standard library's documentation to use the new format_args syntax. The documentation is worthwhile to update as it should be more idiomatic (particularly for features like this, which are nice for users to get acquainted with). The general codebase is likely more hassle than benefit to update: it'll hurt git blame, and generally updates can be done by folks updating the code if (and when) that makes things more readable with the new format. A few places in the compiler and library code are updated (mostly just due to already having been done when this commit was first authored). `eprintln!("{}", e)` becomes `eprintln!("{e}")`, but `eprintln!("{}", e.kind())` remains untouched.
…=tmandry Treat unstable lints as unknown This change causes unstable lints to be ignored if the `unknown_lints` lint is allowed. To achieve this, it also changes lints to apply as soon as they are processed. Previously, lints in the same set were processed as a batch and then all simultaneously applied. Implementation of rust-lang/compiler-team#469
…aaaa, r=petrochenkov [1/2] Implement macro meta-variable expressions See rust-lang#93545 (comment) The logic behind `length`, `index` and `count` was removed but the parsing code is still present, i.e., everything is simply ignored like `ignored`. r? ``@petrochenkov``
…mulacrum Statically compile libstdc++ everywhere if asked PR rust-lang#93918 made it so that `-static-libstdc++` was only set in one place, and was only set during linking, but accidentally also made it so that it is no longer passed when building LLD, only when building LLVM itself. This moves the logic for setting `-static-libstdc++` in the linker flags to `configure_cmake` so that it takes effect for all CMake invocations in `native.rs`. As a side-effect, this also causes libstdc++ to be statically compiled into sanitizers, whereas previously the `llvm-static-stdcpp` flag had no effect on sanitizers. It also makes it so that LLD will be compiled statically if `llvm-tools-enabled` is set, even though previously it was only linked statically if `llvm-static-stdcpp` was set explicitly. Both of these seem like they match expected behavior than what was there prior to rust-lang#93918.
…eta, r=michaelwoerister Only emit pointer-like metadata for `Box<T, A>` when `A` is ZST Basically copy the change in rust-lang#94043, but for debuginfo. r? ``@michaelwoerister`` Fixes rust-lang#94725
…n-DPC enable portable-simd doctests in Miri With rust-lang/miri#2013 we shouldn't need to disable these tests any more. :)
…st, r=notriddle Update browser-ui-test version It should help with rust-lang#93784 (the important PR helping in this regard is GuillaumeGomez/browser-UI-test#273). r? `@notriddle`
@bors r+ rollup=never p=5 |
📌 Commit 456135c has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (352e621): comparison url. Summary: This benchmark run shows 116 relevant regressions 😿 to instruction counts.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression |
@Dylan-DPC Unfortunately it seems there are many PRs that could plausibly contribute to the performance change: The overall regression seems low enough that I don't think we need to consider reverting though. Unfortunately we don't have a good process for determining the culprit in cases like this where many PRs seem somewhat equally likely to be the cause. |
@rylev ah.. how should we proceed with this? should I revert this rollup and re-merge the potential prs individually? (edit: or i guess just revert the 3 changes) |
@Dylan-DPC I think the perf regression is large enough for us to revert. If you have the time to try to revert the three plausible culprits, then you can go for it, but don't feel pressured to! |
that's fine i'll do it later today |
Successful merges:
Box<T, A>
whenA
is ZST #94728 (Only emit pointer-like metadata forBox<T, A>
whenA
is ZST)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup