about summary refs log tree commit diff
AgeCommit message (Collapse)AuthorLines
2023-10-03Auto merge of #115301 - Zalathar:regions-vec, r=davidtwcobors-1214/+1070
coverage: Allow each coverage statement to have multiple code regions The original implementation of coverage instrumentation was built around the assumption that a coverage counter/expression would be associated with *up to one* code region. When it was discovered that *multiple* regions would sometimes need to share a counter, a workaround was found: for the remaining regions, the instrumentor would create a fresh expression that adds zero to the existing counter/expression. That got the job done, but resulted in some awkward code, and produces unnecessarily complicated coverage maps in the final binary. --- This PR removes that tension by changing `StatementKind::Coverage`'s code region field from `Option<CodeRegion>` to `Vec<CodeRegion>`. The changes on the codegen side are fairly straightforward. As long as each `CoverageKind::Counter` only injects one `llvm.instrprof.increment`, the rest of coverage codegen is happy to handle multiple regions mapped to the same counter/expression, with only minor option-to-vec adjustments. On the instrumentor/mir-transform side, we can get rid of the code that creates extra (x + 0) expressions. Instead we gather all of the code regions associated with a single BCB, and inject them all into one coverage statement. --- There are several patches here but they can be divided in to three phases: - Preparatory work - Actually switching over to multiple regions per coverage statement - Cleaning up So viewing the patches individually may be easier.
2023-10-03Auto merge of #116384 - matthiaskrgr:rollup-se332zs, r=matthiaskrgrbors-174/+242
Rollup of 5 pull requests Successful merges: - #114654 (Suggest `pin!()` instead of `Pin::new()` when appropriate) - #116261 (a small wf and clause cleanup) - #116282 (Fix broken links) - #116328 (Factor out common token generation in `fluent_messages`.) - #116379 (non_lifetime_binders: fix ICE in lint opaque-hidden-inferred-bound) r? `@ghost` `@rustbot` modify labels: rollup
2023-10-03Rollup merge of #116379 - fmease:opaq-hid-inf-bnds-non-lt-bndrs, ↵Matthias Krüger-7/+30
r=compiler-errors non_lifetime_binders: fix ICE in lint opaque-hidden-inferred-bound Opaque types like `impl for<T> Trait<T>` would previously lead to an ICE. r? `@compiler-errors`
2023-10-03Rollup merge of #116328 - nnethercote:rustc_fluent_macro, r=davidtwcoMatthias Krüger-40/+22
Factor out common token generation in `fluent_messages`. The failure and success cases are similar enough that they can share code. r? `@davidtwco`
2023-10-03Rollup merge of #116282 - rustaceanclub:master, r=davidtwcoMatthias Krüger-4/+4
Fix broken links The previous address is no longer available, replace it with the latest available one.
2023-10-03Rollup merge of #116261 - lcnr:wf-only-clause, r=davidtwcoMatthias Krüger-101/+81
a small wf and clause cleanup - remove `Clause::from_projection_clause`, instead use `ToPredicate` - change `predicate_obligations` to directly take a `Clause` - remove some unnecessary `&` - use clause in `min_specialization` checks where easily applicable
2023-10-03Rollup merge of #114654 - estebank:suggest-pin-macro, r=davidtwcoMatthias Krüger-22/+105
Suggest `pin!()` instead of `Pin::new()` when appropriate When encountering a type that needs to be pinned but that is `!Unpin`, suggest using the `pin!()` macro. Fix #57994.
2023-10-03non_lifetime_binders: fix ICE in lint opaque-hidden-inferred-boundLeón Orell Valerian Liehr-7/+30
2023-10-03Auto merge of #116376 - matthiaskrgr:rollup-b3d14gq, r=matthiaskrgrbors-127/+193
Rollup of 5 pull requests Successful merges: - #115863 (Add check_unused_messages in tidy) - #116210 (Ensure that `~const` trait bounds on associated functions are in const traits or impls) - #116358 (Rename both of the `Match` relations) - #116371 (Remove unused features from `rustc_llvm`.) - #116374 (Print normalized ty) r? `@ghost` `@rustbot` modify labels: rollup
2023-10-03Rollup merge of #116374 - ouz-a:correct_message, r=RalfJungMatthias Krüger-20/+30
Print normalized ty Inside `mir_assign_valid_types` we are comparing normalized type of `mir_place` but in debug message we are not printing the normalized value, this changes that.
2023-10-03Rollup merge of #116371 - nnethercote:rustc_llvm, r=bjorn3Matthias Krüger-4/+0
Remove unused features from `rustc_llvm`. r? `@bjorn3`
2023-10-03Rollup merge of #116358 - compiler-errors:match, r=lcnrMatthias Krüger-15/+24
Rename both of the `Match` relations Both of these names kinda were ambiguous. r? lcnr
2023-10-03Rollup merge of #116210 - Raekye:master, r=fee1-deadMatthias Krüger-34/+139
Ensure that `~const` trait bounds on associated functions are in const traits or impls Zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/How.20to.2Fshould.20I.20try.20to.20pinpoint.20ICEs.20related.20to.20effects.3F
2023-10-03Rollup merge of #115863 - chenyukang:yukang-add-message-tidy-check, r=davidtwcoMatthias Krüger-54/+0
Add check_unused_messages in tidy From https://github.com/rust-lang/rust/pull/115728#issuecomment-1715490553 The check is not 100% accurate, I guess it's enough for now.
2023-10-03Auto merge of #115025 - ouz-a:ouz_testing, r=lcnrbors-65/+282
Make subtyping explicit in MIR This adds new mir-opt that pushes new `ProjectionElem` called `ProjectionElem::Subtype(T)` to `Rvalue` of a subtyped assignment so we can unsoundness issues like https://github.com/rust-lang/rust/issues/107205 Addresses https://github.com/rust-lang/rust/issues/112651 r? `@lcnr`
2023-10-03print normalized tyouz-a-20/+30
2023-10-03Auto merge of #116372 - matthiaskrgr:rollup-ee9oxxa, r=matthiaskrgrbors-61/+235
Rollup of 6 pull requests Successful merges: - #113053 (add notes about non-compliant FP behavior on 32bit x86 targets) - #115726 (For a single impl candidate, try to unify it with error trait ref) - #116158 (Don't suggest nonsense suggestions for unconstrained type vars in `note_source_of_type_mismatch_constraint`) - #116351 (Add `must_use` on pointer equality functions) - #116355 (Clarify float rounding direction for signed zero) - #116361 (Bump stdarch submodule) r? `@ghost` `@rustbot` modify labels: rollup
2023-10-03Rollup merge of #116361 - eduardosm:bump-stdarch, r=AmanieuMatthias Krüger-0/+1
Bump stdarch submodule r? `@Amanieu`
2023-10-03Rollup merge of #116355 - orlp:signed-zero-rounding-mode, r=thomccMatthias Krüger-4/+6
Clarify float rounding direction for signed zero Closes https://github.com/rust-lang/rust/issues/116339.
2023-10-03Rollup merge of #116351 - asquared31415:ptr_eq_must_use, r=workingjubileeMatthias Krüger-0/+2
Add `must_use` on pointer equality functions `ptr == ptr` (like all use of `==`) has a similar warning, and these functions are simple convenience wrappers over that.
2023-10-03Rollup merge of #116158 - compiler-errors:unconstrained-type-var-sugg, ↵Matthias Krüger-2/+43
r=wesleywiser Don't suggest nonsense suggestions for unconstrained type vars in `note_source_of_type_mismatch_constraint` The way we do type inference for suggestions in `note_source_of_type_mismatch_constraint` is a bit strange. We compute the "ideal" method signature, which takes the receiver that we *want* and uses it to compute the types of the arguments that would have given us that receiver via type inference, and use *that* to suggest how to change an argument to make sure our receiver type is inferred correctly. The problem is that sometimes we have totally unconstrained arguments (well, they're constrained by things outside of the type checker per se, like associated types), and therefore type suggestions are happy to coerce anything to that unconstrained argument. This leads to bogus suggestions, like #116155. This is partly due to above, and partly due to the fact that `emit_type_mismatch_suggestions` doesn't double check that its suggestions are actually compatible with the program other than trying to satisfy the type mismatch. This adds a hack to make sure that at least the types are fully constrained, but I guess I could also rip out this logic altogether. There would be some sad diagnostics regressions though, such as `tests/ui/type/type-check/point-at-inference-4.rs`. Fixes #116155
2023-10-03Rollup merge of #115726 - compiler-errors:better-error-ref, r=estebankMatthias Krüger-34/+157
For a single impl candidate, try to unify it with error trait ref This allows us to point out an exact type mismatch when there's only one applicable impl. cc `@asquared31415` r? `@estebank`
2023-10-03Rollup merge of #113053 - RalfJung:x86_32-float, r=workingjubileeMatthias Krüger-21/+26
add notes about non-compliant FP behavior on 32bit x86 targets Based on ton of prior discussion (see all the issues linked from https://github.com/rust-lang/unsafe-code-guidelines/issues/237), the consensus seems to be that these targets are simply cursed and we cannot implement the desired semantics for them. I hope I properly understood what exactly the extent of the curse is here, let's make sure people with more in-depth FP knowledge take a close look! In particular for the tier 3 targets I have no clue which target is affected by which particular variant of the x86_32 FP curse. I assumed that `i686` meant SSE is used so the "floating point return value" is the only problem, while everything lower (`i586`, `i386`) meant x87 is used. I opened https://github.com/rust-lang/rust/issues/114479 to concisely describe and track the issue. Cc `@workingjubilee` `@thomcc` `@chorman0773` `@rust-lang/opsem` Fixes https://github.com/rust-lang/rust/issues/73288 Fixes https://github.com/rust-lang/rust/issues/72327
2023-10-03add notes about non-compliant FP behavior on 32bit x86 targetsRalf Jung-21/+26
2023-10-03Remove unused features from `rustc_llvm`.Nicholas Nethercote-4/+0
2023-10-03Auto merge of #116083 - cuviper:relnotes-1.73.0, r=Mark-Simulacrumbors-0/+117
Add release notes for 1.73.0 r? `@Mark-Simulacrum` cc `@rust-lang/release`
2023-10-02Fix a few typosMark Rousskov-2/+2
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
2023-10-03coverage: Remove `next_id` methods from counter/expression IDsZalathar-12/+2
When these methods were originally written, I wasn't aware that `newtype_index!` already supports addition with ordinary numbers, without needing to unwrap and re-wrap.
2023-10-03coverage: Remove code for making expression copies of BCB countersZalathar-14/+2
Now that coverage statements can have multiple code regions attached to them, this code is never used.
2023-10-03coverage: Store each BCB's code regions in one coverage statementZalathar-971/+842
If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-10-03coverage: Let each coverage statement hold a vector of code regionsZalathar-90/+96
This makes it possible for a `StatementKind::Coverage` to hold more than one code region, but that capability is not yet used.
2023-10-03coverage: Update comments/logs that referred to `CoverageSpan`Zalathar-20/+20
The concrete type `CoverageSpan` is no longer used outside of the `spans` module. This is a separate patch to avoid noise in the preceding patch that actually encapsulates coverage spans.
2023-10-03coverage: Encapsulate coverage spansZalathar-54/+63
By encapsulating the coverage spans in a struct, we can change the internal representation without disturbing existing call sites. This will be useful for grouping coverage spans by BCB. This patch includes some changes that were originally in #115912, which avoid the need for a particular test to deal with coverage spans at all. (Comments/logs referring to `CoverageSpan` are updated in a subsequent patch.)
2023-10-03coverage: Mappings for unused functions can all be zeroZalathar-73/+65
There is no need to include a dummy counter reference in the coverage mappings for an unused function.
2023-10-02Point out the actual mismatch errorMichael Goulet-1/+52
2023-10-02For a single impl candidate, try to unify it with error trait refMichael Goulet-34/+106
2023-10-02Auto merge of #102099 - InnovativeInventor:re-cold-land, r=nikicbors-13/+95
Rebased: Mark drop calls in landing pads cold instead of noinline I noticed that certain inlining optimizations were missing while staring at some compiled code output. I'd like to see this relanded, so I rebased the PR from `@erikdesjardins` (PR #94823). This PR reapplies https://github.com/rust-lang/rust/pull/92419, which was reverted in https://github.com/rust-lang/rust/pull/94402 due to https://github.com/rust-lang/rust/issues/94390. Fixes https://github.com/rust-lang/rust/issues/46515, fixes https://github.com/rust-lang/rust/issues/87055. Update: fixes #97217.
2023-10-02Bump stdarch submoduleEduardo Sánchez Muñoz-0/+1
2023-10-02Shuffle around some 1.73.0 relnotesJosh Stone-3/+3
2023-10-02Apply suggestions for 1.73.0 relnotesJosh Stone-2/+3
Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com> Co-authored-by: Urgau <3616612+Urgau@users.noreply.github.com>
2023-10-02Don't suggest nonsense suggestions for unconstrained type vars in ↵Michael Goulet-2/+43
note_source_of_type_mismatch_constraint
2023-10-02Rename both of the Match relationsMichael Goulet-15/+24
2023-10-02have better explanation for `relate_types`ouz-a-33/+40
2023-10-02change is_subtype to relate_typesouz-a-86/+127
2023-10-02Add docs, remove code, change subtyper codeouz-a-363/+106
2023-10-02subtyping_projectionsouz-a-5/+431
2023-10-02Auto merge of #116356 - tmandry:rollup-trfidc8, r=tmandrybors-107/+106
Rollup of 5 pull requests Successful merges: - #114453 (Print GHA log groups to stdout instead of stderr) - #114454 (Replace `HashMap` with `IndexMap` in pattern binding resolve ) - #116289 (Add missing #[inline] on AsFd impl for sys::unix::fs::File) - #116349 (ensure the parent path's existence on `x install`) - #116350 (Improve wording of `hint::black_box` docs) r? `@ghost` `@rustbot` modify labels: rollup
2023-10-02Rollup merge of #116350 - Nilstrieb:in-situ, r=Dylan-DPCTyler Mandry-1/+1
Improve wording of `hint::black_box` docs The wording is a bit confusing. squash of #109634
2023-10-02Rollup merge of #116349 - onur-ozkan:hfix, r=tmandryTyler Mandry-3/+3
ensure the parent path's existence on `x install` fixes https://github.com/rust-lang/rust/pull/116127#issuecomment-1743454109 cc `@tmandry`
2023-10-02Rollup merge of #116289 - linkmauve:patch-1, r=the8472Tyler Mandry-0/+1
Add missing #[inline] on AsFd impl for sys::unix::fs::File This operation should be extremely cheap, at most the `mov` of the underlying file descriptor, but due to this missing `#[inline]` it is currently a function call.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-24 05:13:45 +0000