-
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 7 pull requests #125331
Rollup of 7 pull requests #125331
Conversation
Fix rust-lang#124819, where a if-less block causes a wrong output. It is caused by get_return_block in get_fn_decl. In get_return_block, when a else-less if expression is the tail expression, the check for next_node will keep iterating. So it is necessary to make a early return in the check.
This currently has no effect, but is expected to be useful when expanding support for branch coverage and MC/DC coverage.
Some of these cases currently don't occur in practice, but are included for completeness, and to avoid having to add them later as branch coverage and MC/DC coverage start building more complex expressions.
…d lifetimes ``` error: lifetime may not live long enough --> $DIR/ex3-both-anon-regions-both-are-structs-2.rs:7:5 | LL | fn foo(mut x: Ref, y: Ref) { | ----- - has type `Ref<'_, '1>` | | | has type `Ref<'_, '2>` LL | x.b = y.b; | ^^^^^^^^^ assignment requires that `'1` must outlive `'2` | help: consider introducing a named lifetime parameter | LL | fn foo<'a>(mut x: Ref<'a, 'a>, y: Ref<'a, 'a>) { | ++++ ++++++++ ++++++++ ``` As can be seen above, it currently doesn't try to compare the `ty::Ty` lifetimes that diverged vs the `hir::Ty` to correctly suggest the following ``` help: consider introducing a named lifetime parameter | LL | fn foo<'a>(mut x: Ref<'_, 'a>, y: Ref<'_, 'a>) { | ++++ ++++++++ ++++++++ ``` but I believe this to still be an improvement over the status quo. CC rust-lang#40990.
``` error: lifetime may not live long enough --> f205.rs:8:16 | 7 | fn resolve_symbolic_reference(&self, reference: Option<Reference>) -> Option<Reference> { | - --------- has type `Option<Reference<'1>>` | | | let's call the lifetime of this reference `'2` 8 | return reference; | ^^^^^^^^^ method was supposed to return data with lifetime `'2` but it is returning data with lifetime `'1` | help: consider introducing a named lifetime parameter | 7 | fn resolve_symbolic_reference<'a>(&'a self, reference: Option<Reference<'a>>) -> Option<Reference<'a>> { | ++++ ++ ++++ ++++ ``` The correct suggestion would be ``` help: consider introducing a named lifetime parameter | 7 | fn resolve_symbolic_reference<'a>(&self, reference: Option<Reference<'a>>) -> Option<Reference<'a>> { | ++++ ++++ ++++ ``` but we are not doing the analysis to detect that yet. If we constrain `&'a self`, then the return type with a borrow will implicitly take its lifetime from `'a`, it is better to make it explicit in the suggestion, in case that `&self` *doesn't* need to be `'a`, but the return does.
… `run-rustfix` ``` error: lifetime may not live long enough --> $DIR/lt-ref-self.rs:12:9 | LL | fn ref_self(&self, f: &u32) -> &u32 { | - - let's call the lifetime of this reference `'1` | | | let's call the lifetime of this reference `'2` LL | f | ^ method was supposed to return data with lifetime `'2` but it is returning data with lifetime `'1` | help: consider introducing a named lifetime parameter and update trait if needed | LL | fn ref_self<'b>(&'b self, f: &'b u32) -> &'b u32 { | ++++ ++ ++ ++ ```
…ceiver Do not suggest constraining the `&self` param, but rather the return type. If that is wrong (because it is not sufficient), a follow up error will tell the user to fix it. This way we lower the chances of *over* constraining, but still get the cake of "correctly" contrained in two steps. This is a correct suggestion: ``` error: lifetime may not live long enough --> $DIR/ex3-both-anon-regions-return-type-is-anon.rs:9:9 | LL | fn foo<'a>(&self, x: &i32) -> &i32 { | - - let's call the lifetime of this reference `'1` | | | let's call the lifetime of this reference `'2` LL | x | ^ method was supposed to return data with lifetime `'2` but it is returning data with lifetime `'1` | help: consider introducing a named lifetime parameter and update trait if needed | LL | fn foo<'a>(&self, x: &'a i32) -> &'a i32 { | ++ ++ ``` While this is incomplete because it should suggestino `&'a self` ``` error: lifetime may not live long enough --> $DIR/ex3-both-anon-regions-self-is-anon.rs:7:19 | LL | fn foo<'a>(&self, x: &Foo) -> &Foo { | - - let's call the lifetime of this reference `'1` | | | let's call the lifetime of this reference `'2` LL | if true { x } else { self } | ^ method was supposed to return data with lifetime `'2` but it is returning data with lifetime `'1` | help: consider introducing a named lifetime parameter and update trait if needed | LL | fn foo<'a>(&self, x: &'a Foo) -> &'a Foo { | ++ ++ ``` but the follow up error is ``` error: lifetime may not live long enough --> tests/ui/lifetimes/lifetime-errors/ex3-both-anon-regions-self-is-anon.rs:7:30 | 6 | fn foo<'a>(&self, x: &'a Foo) -> &'a Foo { | -- - let's call the lifetime of this reference `'1` | | | lifetime `'a` defined here 7 | if true { x } else { self } | ^^^^ method was supposed to return data with lifetime `'a` but it is returning data with lifetime `'1` | help: consider introducing a named lifetime parameter and update trait if needed | 6 | fn foo<'a>(&'a self, x: &'a Foo) -> &'a Foo { | ++ ```
Suggest setting lifetime in borrowck error involving types with elided lifetimes ``` error: lifetime may not live long enough --> $DIR/ex3-both-anon-regions-both-are-structs-2.rs:7:5 | LL | fn foo(mut x: Ref, y: Ref) { | ----- - has type `Ref<'_, '1>` | | | has type `Ref<'_, '2>` LL | x.b = y.b; | ^^^^^^^^^ assignment requires that `'1` must outlive `'2` | help: consider introducing a named lifetime parameter | LL | fn foo<'a>(mut x: Ref<'a, 'a>, y: Ref<'a, 'a>) { | ++++ ++++++++ ++++++++ ``` As can be seen above, it currently doesn't try to compare the `ty::Ty` lifetimes that diverged vs the `hir::Ty` to correctly suggest the following ``` help: consider introducing a named lifetime parameter | LL | fn foo<'a>(mut x: Ref<'_, 'a>, y: Ref<'_, 'a>) { | ++++ ++++++++ ++++++++ ``` but I believe this to still be an improvement over the status quo. Fix rust-lang#40990.
Check whether the next_node is else-less if in get_return_block Fix rust-lang#124819
coverage: Memoize and simplify counter expressions When creating coverage counter expressions as part of coverage instrumentation, we often end up creating obviously-redundant expressions like `c1 + (c0 - c1)`, which is equivalent to just `c0`. To avoid doing so, this PR checks when we would create an expression matching one of 5 patterns, and uses the simplified form instead: - `(a - b) + b` → `a`. - `(a + b) - b` → `a`. - `(a + b) - a` → `b`. - `a + (b - a)` → `b`. - `a - (a - b)` → `b`. Of all the different ways to combine 3 operands and 2 operators, these are the patterns that allow simplification. (Some of those patterns currently don't occur in practice, but are included anyway for completeness, to avoid having to add them later as branch coverage and MC/DC coverage support expands.) --- This PR also adds memoization for newly-created (or newly-simplified) counter expressions, to avoid creating duplicates. This currently makes no difference to the final mappings, but is expected to be useful for MC/DC coverage of match expressions, as proposed by rust-lang#124278 (comment).
Remove `Rvalue::CheckedBinaryOp` Zulip conversation: <https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/intrinsics.20vs.20binop.2Funop/near/438729996> cc `@RalfJung` While it's a draft, r? ghost
…e8472 add some codegen tests for issue 120493 I forgot to add these in rust-lang#123878.
…eature-gate, r=pnkfelix Add an experimental feature gate for global registration See rust-lang#125119 for the tracking issue.
…mples-whitespaces, r=jieyouxu Migrate `run-make/rustdoc-scrape-examples-whitespace` to `rmake.rs` Part of rust-lang#121876. r? `@jieyouxu`
@bors r+ rollup=never p=7 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 474bee7bf5 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (be71fd4): comparison URL. Overall result: ✅ improvements - no action needed@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)Results (primary 1.1%, secondary 2.0%)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 -1.1%, secondary -5.0%)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: 670.162s -> 672.136s (0.29%) |
Successful merges:
Rvalue::CheckedBinaryOp
#125173 (RemoveRvalue::CheckedBinaryOp
)run-make/rustdoc-scrape-examples-whitespace
tormake.rs
#125318 (Migraterun-make/rustdoc-scrape-examples-whitespace
tormake.rs
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup