-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 10 pull requests #119569
Rollup of 10 pull requests #119569
Conversation
trusting platform's SOMAXCONN instead of hardcoding to 128 otherwise.
Co-authored-by: León Orell Valerian Liehr <[email protected]>
Currently, this only works with `-Cpanic=abort`.
Only suggest `derive(PartialEq)` when both LHS and RHS types are the same, otherwise the suggestion is not useful.
librustdoc: fix typos
Enable address sanitizer for MSVC targets using INFERASANLIBS linker flag This enables address sanitizer for x86_64-pc-windows-msvc and i686-pc-windows-msvc targets when linked with the MSVC linker (link.exe) by leveraging the `/INFERASANLIBS` option to automatically find and link in Microsoft's address sanitizer runtime: <https://learn.microsoft.com/en-us/cpp/sanitizers/asan-runtime?view=msvc-170> Implements rust-lang/compiler-team#702 Fixes rust-lang#89339 (for MSVC targets using the MSVC linker only) Supercedes rust-lang#89369 Successful x86_64-msvc build showing the sanitizer tests working: https://github.com/rust-lang/rust/actions/runs/7228346880/job/19697628258?pr=118521
…lacrum std::net::bind using -1 for openbsd which in turn sets it to somaxconn. trusting platform's SOMAXCONN instead of hardcoding to 128 otherwise.
…, r=Amanieu Make named_asm_labels lint not trigger on unicode and trigger on format args Someone showed me some cursed code that used format args to create named labels, and rustc wasn't linting on that. Additionally while fixing that, I noticed that Unicode alphabetic characters were being used as part of labels, when they are not actually permitted in labels. r? ```@Amanieu```
macro_rules: Less hacky heuristic for using `tt` metavariable spans See the big comment on `fn maybe_use_metavar_location` for a more detailed description.
…n, r=fmease Make `derive(Trait)` suggestion more accurate Only suggest `derive(PartialEq)` when both LHS and RHS types are the same, otherwise the suggestion is not useful.
…=fmease Recover parentheses in range patterns Before: ```rs match n { (0).. => (), _ => () } ``` ``` error: expected one of `=>`, `if`, or `|`, found `..` --> src/lib.rs:3:12 | 3 | (0).. => (), | ^^ expected one of `=>`, `if`, or `|` ``` After: ``` error: range pattern bounds cannot have parentheses --> main.rs:3:5 | 3 | (0).. => (), | ^ ^ | help: remove these parentheses | 3 - (0).. => (), 3 + 0.. => (), | ``` This sets the groundwork for rust-lang#118625, which will extend the recovery to expressions like `(0 + 1)..` where users may tend to add parentheses to avoid dealing with precedence. --- ```@rustbot``` label +A-parser +A-patterns +A-diagnostics
…r=davidtwco Uplift some miscellaneous coroutine-specific machinery into `check_closure` This PR uplifts some of the logic in `check_fn` that is specific to checking coroutines, which always flows through `check_closure`. This is just some miscellaneous clean up that I've wanted to do, especially because I'm poking around this code to make it work for async closures.
…rait, r=compiler-errors Don't synthesize host effect args inside trait object types While we were indeed emitting an error for `~const` & `const` trait bounds in trait object types, we were still synthesizing host effect args for them. Since we don't record the original trait bound modifiers for dyn-Trait in `hir::TyKind::TraitObject` (unlike we do for let's say impl-Trait, `hir::TyKind::OpaqueTy`), AstConv just assumes `ty::BoundConstness::NotConst` in `conv_object_ty_poly_trait_ref` which given `<host> dyn ~const NonConstTrait` resulted in us not realizing that `~const` was used on a non-const trait which lead to a failed assertion in the end. Instead of updating `hir::TyKind::TraitObject` to track this kind of information, just strip the user-provided constness (similar to rust-lang#119505). Fixes rust-lang#119524.
…t, r=nikic Add codegen test for RVO on MaybeUninit Codegen test for rust-lang#90595. Currently, this only works with `-Cpanic=abort`, but hopefully in the [future](https://www.npopov.com/2024/01/01/This-year-in-LLVM-2023.html#writable-and-dead_on_unwind) it should also work in the presence of panics. r? ``@nikic``
@bors r- |
@bors force |
@bors r+ |
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#118521 (Enable address sanitizer for MSVC targets using INFERASANLIBS linker flag) - rust-lang#119026 (std::net::bind using -1 for openbsd which in turn sets it to somaxconn.) - rust-lang#119195 (Make named_asm_labels lint not trigger on unicode and trigger on format args) - rust-lang#119204 (macro_rules: Less hacky heuristic for using `tt` metavariable spans) - rust-lang#119362 (Make `derive(Trait)` suggestion more accurate) - rust-lang#119397 (Recover parentheses in range patterns) - rust-lang#119417 (Uplift some miscellaneous coroutine-specific machinery into `check_closure`) - rust-lang#119539 (Fix typos) - rust-lang#119540 (Don't synthesize host effect args inside trait object types) - rust-lang#119555 (Add codegen test for RVO on MaybeUninit) r? `@ghost` `@rustbot` modify labels: rollup
💥 Test timed out |
@bors retry |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 4c5ce1f0d5 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (f688dd6): 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)ResultsThis 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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeResultsThis 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.
Bootstrap: 668.115s -> 670.353s (0.33%) |
Regression appears to be within a noisy benchmark. |
Successful merges:
tt
metavariable spans #119204 (macro_rules: Less hacky heuristic for usingtt
metavariable spans)derive(Trait)
suggestion more accurate #119362 (Makederive(Trait)
suggestion more accurate)check_closure
#119417 (Uplift some miscellaneous coroutine-specific machinery intocheck_closure
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup