-
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 10 pull requests #132094
Rollup of 10 pull requests #132094
Conversation
The `x86_64-pc-nto-qnx710` and `i586-pc-nto-qnx700` targets have `pc` in their target triple names, but the vendor was set to the default `"unknown"`.
- remove a redundant check, because we always emit the "better diagnostic" now - clean up the comments a bit
As part of the "arbitrary self types v2" project, we are going to replace the current `Receiver` trait with a new mechanism based on a new, different `Receiver` trait. This PR renames the old trait to get it out the way. Naming is hard. Options considered included: * HardCodedReceiver (because it should only be used for things in the standard library, and hence is sort-of hard coded) * LegacyReceiver * TargetLessReceiver * OldReceiver These are all bad names, but fortunately this will be temporary. Assuming the new mechanism proceeds to stabilization as intended, the legacy trait will be removed altogether. Although we expect this trait to be used only in the standard library, we suspect it may be in use elsehwere, so we're landing this change separately to identify any surprising breakages. It's known that this trait is used within the Rust for Linux project; a patch is in progress to remove their dependency. This is a part of the arbitrary self types v2 project, rust-lang/rfcs#3519 rust-lang#44874 r? @wesleywiser
double_parens filter_map_identity needless_question_mark redundant_guards
…esleywiser Rename Receiver -> LegacyReceiver As part of the "arbitrary self types v2" project, we are going to replace the current `Receiver` trait with a new mechanism based on a new, different `Receiver` trait. This PR renames the old trait to get it out the way. Naming is hard. Options considered included: * HardCodedReceiver (because it should only be used for things in the standard library, and hence is sort-of hard coded) * LegacyReceiver * TargetLessReceiver * OldReceiver These are all bad names, but fortunately this will be temporary. Assuming the new mechanism proceeds to stabilization as intended, the legacy trait will be removed altogether. Although we expect this trait to be used only in the standard library, we suspect it may be in use elsehwere, so we're landing this change separately to identify any surprising breakages. It's known that this trait is used within the Rust for Linux project; a patch is in progress to remove their dependency. This is a part of the arbitrary self types v2 project, rust-lang/rfcs#3519 rust-lang#44874 r? `@wesleywiser`
…wesleywiser Fix `target_vendor` in QNX Neutrino targets The `x86_64-pc-nto-qnx710` and `i586-pc-nto-qnx700` targets have `pc` in their target triple names, but the vendor was set to the default `"unknown"`. CC target maintainers `@flba-eb,` `@gh-tr,` `@jonathanpallant` and `@japaric`
…ype-err, r=lcnr Deeply normalize `TypeTrace` when reporting type error in new solver Normalize the values that come from the `TypeTrace` for various type mismatches. Side-note: We can't normalize the `TypeError` itself bc it may come from instantiated binders, so it may reference values from within the probe... r? lcnr
…piler-errors minor `*dyn` cast cleanup Small follow-up to rust-lang#130234 to remove a redundant check and clean up comments. No functional changes. Also, explain why casts cannot drop the principal even though coercions can, and add a test because apparently we didn't have one already. r? `@WaffleLapkin` or `@compiler-errors`
…mpiler-errors Prevent overflowing enum cast from ICEing Fixes rust-lang#131902
…jieyouxu Don't allow test revisions that conflict with built in cfgs Fixes rust-lang#128964 Sorry `@heysujal` I started working on this about 1 minute before your comment by complete coincidence 😅
…-errors,Swatinem coverage: Pass coverage mappings to LLVM as separate structs Instead of trying to cram *N* different kinds of coverage mapping data into a single list for FFI, pass *N* different lists of simpler structs. This avoids the need to fill unused fields with dummy values, and avoids the need to tag structs with their underlying kind. It also lets us call the dedicated LLVM constructors for each different mapping type, instead of having to go through the complex general-purpose constructor. Even though this adds multiple new structs to the FFI surface area, the resulting C++ code is simpler and shorter. --- I've structured this mostly as a single atomic patch, rather than a series of incremental changes, because that avoids the need to make fiddly fixes to code that is about to be deleted anyway.
…rcote,Mark-Simulacrum HashStable for rustc_feature::Features: stop hashing compile-time constant It seems like back in rust-lang@542bc75 this was added as "hash the boolean value of each lang feature", but then in rust-lang@1487bd6 this got split into first hashing a sequence of `bool`s (representing all the features) and then hashing all the feature names... but the list of feature names is a compile-time constant, so it seems entirely unnecessary to hash them? Cc `@Mark-Simulacrum` who wrote the second of the commits mentioned above. Cc `@nnethercote`
…ieyouxu Print safety correctly in extern static items Fixes rust-lang#132080 r? spastorino or anyone really
@bors r+ rollup=never p=10 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: b8bb2968ce In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (55b7f8e): comparison URL. Overall result: ❌ regressions - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (secondary -3.2%)This 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.
CyclesResults (primary -0.9%, secondary -0.3%)This 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 785.689s -> 780.14s (-0.71%) |
I'm not very familiar with perf results, but reducing one family of benchmarks by 0.2% looks like noise to me. |
The tiny regressions to syn were reverted soon after. @rustbot label: +perf-regression-triaged |
Successful merges:
target_vendor
in QNX Neutrino targets #131169 (Fixtarget_vendor
in QNX Neutrino targets)TypeTrace
when reporting type error in new solver #131756 (Deeply normalizeTypeTrace
when reporting type error in new solver)*dyn
cast cleanup #131898 (minor*dyn
cast cleanup)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup