Question:
... as documented. The problem: this line from the documentation: The weak count as reported by is 0 when the strong count is 0, even if there are still outstanding weak references: The combination of these two means that getting a pointer from is not enough to guarantee that it's safe to use in . Instead, you have to know that (if it originated from a strong reference) you still have an outstanding strong reference to the allocation, because otherwise the (exposed) weak count is 0, and thus calling is "documented UB". To properly document when this is intuitively allowed (i.e. it's allowed because I got the pointer from and have called more than , so there are still "unowned" raw weak references to claim) (which lines up with what the implementation allows), we need to expose (probably docs only) the fact that there is still being a weak reference count behind the hood being tracked until all of the s have been dropped. This will probably also require guaranteeing that doesn't drop its weak reference and become dangling "early" (e.g. note that failed, decrement the (real) weak count (potentially deallocating the place), and become a dangling weak via internal mutability) and that on a "zombie" increments the (real) weak count and creates a new "zombie" , not a dangling .
(I don't know if C-bug is the correct label for a "documentation bug," but it was the closest template to correct.)
I guess that means the internal weak count rather than the user-visible .
That's obviously the intent and what the implementation shows is the case, but when considering documented properties of an API, you have to only consider the documented API. A correct resolution to the issue would be to adjust the documentation to clarify that the weak count is referring to the hidden internal weak count that's not exposed (except conceptually for the safety of /). cc who wrote these methods and docs
Yes, it's meant as the actual number of weak pointers pointing there (including the ones „frozen“ to raw pointers), not what some method returns (if it's currently in the form of the raw pointer, you really can't even call the method, so I'm not sure if that part can even apply). I agree it could probably be documented better. I'd try to fix the docs, but considering I've already updated them like 3 times during the review and they still haven't ended up entirely correct, I'll probably ask if you want to give it a go first, as obviously the docs aren't my strong ability :-).
The main thing this requires is actually specifying how the "internal" weak count works, and guarnateeing that we don't do "clever" things with converting "zombie "s into dangling s. I really don't know the best way to do this or even where to do this, since it basically only impacts how and when is allowed to be called.
:thinking: Maybe just getting rid of the „weak count“ term altogether and try to describe it in a way that the pointer preserves the ownership of the , or that it's an alternative form of and it can be turned back if it still has the ownership. Or maybe just point out that the „weak count“ is meant in its natural meaning, not referring to the method.
Ok, looking into this, how about wording like this? On the intoraw: And on the : Do you think this would be better?
Yeah, I think that wording captures the semantics properly.
Thanks. I'll get around to submitting the changes some time soonish.

/// This can be used to safely get a strong reference (by calling [`upgrade`] /// later) or to deallocate the weak count by dropping the `Weak<T>`. /// <del> /// It takes ownership of one weak count (with the exception of pointers created by [`new`], /// as these don't have any corresponding weak count). </del> <ins> /// It takes ownership of one weak reference (with the exception of pointers created by [`new`], /// as these don't own anything; the method still works on them). </ins> /// /// # Safety /// <del> /// The pointer must have originated from the [`into_raw`]  and must still own its potential /// weak reference count. </del> <ins> /// The pointer must have originated from the [`into_raw`] and must still own its potential /// weak reference. </ins> /// <del> /// It is allowed for the strong count to be 0 at the time of calling this, but the weak count /// must be non-zero or the pointer must have originated from a dangling `Weak<T>` (one created /// by [`new`]). </del> <ins> /// It is allowed for the strong count to be 0 at the time of calling this. Nevertheless, this /// takes ownership of one weak reference currently represented as a raw pointer (the weak /// count is not modified by this operation) and therefore it must be paired with a previous /// call to [`into_raw`]. </ins> /// /// # Examples ///


Question:
... as documented. The problem: this line from the documentation: The weak count as reported by is 0 when the strong count is 0, even if there are still outstanding weak references: The combination of these two means that getting a pointer from is not enough to guarantee that it's safe to use in . Instead, you have to know that (if it originated from a strong reference) you still have an outstanding strong reference to the allocation, because otherwise the (exposed) weak count is 0, and thus calling is "documented UB". To properly document when this is intuitively allowed (i.e. it's allowed because I got the pointer from and have called more than , so there are still "unowned" raw weak references to claim) (which lines up with what the implementation allows), we need to expose (probably docs only) the fact that there is still being a weak reference count behind the hood being tracked until all of the s have been dropped. This will probably also require guaranteeing that doesn't drop its weak reference and become dangling "early" (e.g. note that failed, decrement the (real) weak count (potentially deallocating the place), and become a dangling weak via internal mutability) and that on a "zombie" increments the (real) weak count and creates a new "zombie" , not a dangling .
(I don't know if C-bug is the correct label for a "documentation bug," but it was the closest template to correct.)
I guess that means the internal weak count rather than the user-visible .
That's obviously the intent and what the implementation shows is the case, but when considering documented properties of an API, you have to only consider the documented API. A correct resolution to the issue would be to adjust the documentation to clarify that the weak count is referring to the hidden internal weak count that's not exposed (except conceptually for the safety of /). cc who wrote these methods and docs
Yes, it's meant as the actual number of weak pointers pointing there (including the ones „frozen“ to raw pointers), not what some method returns (if it's currently in the form of the raw pointer, you really can't even call the method, so I'm not sure if that part can even apply). I agree it could probably be documented better. I'd try to fix the docs, but considering I've already updated them like 3 times during the review and they still haven't ended up entirely correct, I'll probably ask if you want to give it a go first, as obviously the docs aren't my strong ability :-).
The main thing this requires is actually specifying how the "internal" weak count works, and guarnateeing that we don't do "clever" things with converting "zombie "s into dangling s. I really don't know the best way to do this or even where to do this, since it basically only impacts how and when is allowed to be called.
:thinking: Maybe just getting rid of the „weak count“ term altogether and try to describe it in a way that the pointer preserves the ownership of the , or that it's an alternative form of and it can be turned back if it still has the ownership. Or maybe just point out that the „weak count“ is meant in its natural meaning, not referring to the method.
Ok, looking into this, how about wording like this? On the intoraw: And on the : Do you think this would be better?
Yeah, I think that wording captures the semantics properly.
Thanks. I'll get around to submitting the changes some time soonish.

/// Consumes the `Weak<T>` and turns it into a raw pointer. /// <del> /// This converts the weak pointer into a raw pointer, preserving the original weak count. It /// can be turned back into the `Weak<T>` with [`from_raw`]. </del> <ins> /// This converts the weak pointer into a raw pointer, while still preserving the ownership of /// one weak reference (the weak count is not modified by this operation). It can be turned /// back into the `Weak<T>` with [`from_raw`]. </ins> /// /// The same restrictions of accessing the target of the pointer as with /// [`as_ptr`] apply.


Question:
... as documented. The problem: this line from the documentation: The weak count as reported by is 0 when the strong count is 0, even if there are still outstanding weak references: The combination of these two means that getting a pointer from is not enough to guarantee that it's safe to use in . Instead, you have to know that (if it originated from a strong reference) you still have an outstanding strong reference to the allocation, because otherwise the (exposed) weak count is 0, and thus calling is "documented UB". To properly document when this is intuitively allowed (i.e. it's allowed because I got the pointer from and have called more than , so there are still "unowned" raw weak references to claim) (which lines up with what the implementation allows), we need to expose (probably docs only) the fact that there is still being a weak reference count behind the hood being tracked until all of the s have been dropped. This will probably also require guaranteeing that doesn't drop its weak reference and become dangling "early" (e.g. note that failed, decrement the (real) weak count (potentially deallocating the place), and become a dangling weak via internal mutability) and that on a "zombie" increments the (real) weak count and creates a new "zombie" , not a dangling .
(I don't know if C-bug is the correct label for a "documentation bug," but it was the closest template to correct.)
I guess that means the internal weak count rather than the user-visible .
That's obviously the intent and what the implementation shows is the case, but when considering documented properties of an API, you have to only consider the documented API. A correct resolution to the issue would be to adjust the documentation to clarify that the weak count is referring to the hidden internal weak count that's not exposed (except conceptually for the safety of /). cc who wrote these methods and docs
Yes, it's meant as the actual number of weak pointers pointing there (including the ones „frozen“ to raw pointers), not what some method returns (if it's currently in the form of the raw pointer, you really can't even call the method, so I'm not sure if that part can even apply). I agree it could probably be documented better. I'd try to fix the docs, but considering I've already updated them like 3 times during the review and they still haven't ended up entirely correct, I'll probably ask if you want to give it a go first, as obviously the docs aren't my strong ability :-).
The main thing this requires is actually specifying how the "internal" weak count works, and guarnateeing that we don't do "clever" things with converting "zombie "s into dangling s. I really don't know the best way to do this or even where to do this, since it basically only impacts how and when is allowed to be called.
:thinking: Maybe just getting rid of the „weak count“ term altogether and try to describe it in a way that the pointer preserves the ownership of the , or that it's an alternative form of and it can be turned back if it still has the ownership. Or maybe just point out that the „weak count“ is meant in its natural meaning, not referring to the method.
Ok, looking into this, how about wording like this? On the intoraw: And on the : Do you think this would be better?
Yeah, I think that wording captures the semantics properly.
Thanks. I'll get around to submitting the changes some time soonish.

result } <del> /// Converts a raw pointer previously created by [`into_raw`] back into /// `Weak<T>`. </del> <ins> /// Converts a raw pointer previously created by [`into_raw`] back into `Weak<T>`. </ins> /// /// This can be used to safely get a strong reference (by calling [`upgrade`] /// later) or to deallocate the weak count by dropping the `Weak<T>`. /// <del> /// It takes ownership of one weak count (with the exception of pointers created by [`new`], /// as these don't have any corresponding weak count). </del> <ins> /// It takes ownership of one weak reference (with the exception of pointers created by [`new`], /// as these don't own anything; the method still works on them). </ins> /// /// # Safety /// /// The pointer must have originated from the [`into_raw`] and must still own its potential <del> /// weak reference count. /// /// It is allowed for the strong count to be 0 at the time of calling this, but the weak count /// must be non-zero or the pointer must have originated from a dangling `Weak<T>` (one created /// by [`new`]). </del> <ins> /// weak reference. </ins> /// <ins> /// It is allowed for the strong count to be 0 at the time of calling this. Nevertheless, this /// takes ownership of one weak reference currently represented as a raw pointer (the weak /// count is not modified by this operation) and therefore it must be paired with a previous /// call to [`into_raw`]. </ins> /// # Examples /// /// ```


Question:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .

Greater | // `{ 42 } > 3` GreaterEqual | // `{ 42 } >= 3` AssignOp(_) | // `{ 42 } +=` <del> LAnd | // `{ 42 } &&foo` </del> As | // `{ 42 } as usize` // Equal | // `{ 42 } == { 42 }`    Accepting these here would regress incorrect // NotEqual | // `{ 42 } != { 42 }  struct literals parser recovery.


Question:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .

// want to keep their span info to improve diagnostics in these cases in a later stage. (true, Some(AssocOp::Multiply)) | // `{ 42 } *foo = bar;` or `{ 42 } * 3` (true, Some(AssocOp::Subtract)) | // `{ 42 } -5` <del> (true, Some(AssocOp::LAnd)) | // `{ 42 } &&x` (#61475) </del> (true, Some(AssocOp::Add)) // `{ 42 } + 42 // If the next token is a keyword, then the tokens above *are* unambiguously incorrect: // `if x { a } else { b } && if y { c } else { d }` <del> if !self.look_ahead(1, |t| t.is_reserved_ident()) => { </del> <ins> if !self.look_ahead(1, |t| t.is_used_keyword()) => { // These cases are ambiguous and can't be identified in the parser alone. let sp = self.sess.source_map().start_point(self.token.span); self.sess.ambiguous_block_expr_parse.borrow_mut().insert(sp, lhs.span); false } (true, Some(AssocOp::LAnd)) => { // `{ 42 } &&x` (#61475) or `{ 42 } && if x { 1 } else { 0 }`. Separated from the // above due to #74233. </ins> // These cases are ambiguous and can't be identified in the parser alone. let sp = self.sess.source_map().start_point(self.token.span); self.sess.ambiguous_block_expr_parse.borrow_mut().insert(sp, lhs.span);


Question:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .

} self.suggest_boxing_when_appropriate(err, expr, expected, expr_ty); self.suggest_missing_await(err, expr, expected, expr_ty); <ins> self.suggest_missing_parentheses(err, expr); </ins> self.note_need_for_fn_pointer(err, expected, expr_ty); }


Question:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .

} } <ins> fn suggest_missing_parentheses(&self, err: &mut DiagnosticBuilder<'_>, expr: &hir::Expr<'_>) { let sp = self.tcx.sess.source_map().start_point(expr.span); if let Some(sp) = self.tcx.sess.parse_sess.ambiguous_block_expr_parse.borrow().get(&sp) { // `{ 42 } &&x` (#61475) or `{ 42 } && if x { 1 } else { 0 }` self.tcx.sess.parse_sess.expr_parentheses_needed(err, *sp, None); } } </ins> fn note_need_for_fn_pointer( &self, err: &mut DiagnosticBuilder<'_>,


Question:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .

<ins> // This is not autofixable because we give extra suggestions to end the first expression with `;`. fn foo(a: Option<u32>, b: Option<u32>) -> bool { if let Some(x) = a { true } else { false } //~^ ERROR mismatched types //~| ERROR mismatched types && //~ ERROR mismatched types if let Some(y) = a { true } else { false } } fn main() {} </ins>


Question:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .

<ins> error[E0308]: mismatched types --> $DIR/expr-as-stmt-2.rs:3:26 | LL |     if let Some(x) = a { true } else { false } |     ---------------------^^^^------------------ help: consider using a semicolon here |     |                    | |     |                    expected `()`, found `bool` |     expected this to be `()` error[E0308]: mismatched types --> $DIR/expr-as-stmt-2.rs:3:40 | LL |     if let Some(x) = a { true } else { false } |     -----------------------------------^^^^^--- help: consider using a semicolon here |     |                                  | |     |                                  expected `()`, found `bool` |     expected this to be `()` error[E0308]: mismatched types --> $DIR/expr-as-stmt-2.rs:6:5 | LL |   fn foo(a: Option<u32>, b: Option<u32>) -> bool { |                                             ---- expected `bool` because of return type LL |       if let Some(x) = a { true } else { false } |       ------------------------------------------ help: parentheses are required to parse this as an expression: `(if let Some(x) = a { true } else { false })` ... LL | /     && LL | |     if let Some(y) = a { true } else { false } | |______________________________________________^ expected `bool`, found `&&bool` error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0308`. </ins>


Question:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .

//~^ ERROR mismatched types } <del> fn qux(a: Option<u32>, b: Option<u32>) -> bool { (if let Some(x) = a { true } else { false }) && //~ ERROR expected expression if let Some(y) = a { true } else { false } } </del> fn moo(x: u32) -> bool { (match x { _ => 1,


Question:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .

//~^ ERROR mismatched types } <del> fn qux(a: Option<u32>, b: Option<u32>) -> bool { if let Some(x) = a { true } else { false } && //~ ERROR expected expression if let Some(y) = a { true } else { false } } </del> fn moo(x: u32) -> bool { match x { _ => 1,


Question:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .

|     | |     help: parentheses are required to parse this as an expression: `({ 42 })` <del> error: expected expression, found `&&` --> $DIR/expr-as-stmt.rs:30:5 | LL |     if let Some(x) = a { true } else { false } |     ------------------------------------------ help: parentheses are required to parse this as an expression: `(if let Some(x) = a { true } else { false })` LL |     && |     ^^ expected expression </del> error: expected expression, found `>` <del> --> $DIR/expr-as-stmt.rs:37:7 </del> <ins> --> $DIR/expr-as-stmt.rs:31:7 </ins> | LL |     } > 0 |       ^ expected expression


Question:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .

|     | |     help: parentheses are required to parse this as an expression: `({ 3 })` <del> error: aborting due to 10 previous errors </del> <ins> error: aborting due to 9 previous errors </ins> Some errors have detailed explanations: E0308, E0614. For more information about an error, try `rustc --explain E0308`.


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --The bug exists in the beta, nightly, and stable build channels. : The error and the backtrace provided are produced by the stable build. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
reduced: Edit: you can actually omit the enum declaration and it still crashes :thinking: `
oh, sorry, I've already got a fix. I'll post it soon. Though it may not be the best one.
Great! You should tweak not losing diags. For further reference, you could do when you work on an issue to avoid conflicts.
okay, thanks. Better late than never… claim
This is caused by , I believe. 1.44 emits errors w/o ICE'ing but 1.45 hits it. godbolt (1.44): godbolt (1.45):
Let's keep this open to track stable/beta backports.
The reference suggested this to be possible, which is how I came to suggest it to OP. We wanted to avoid naming them to not suggest any specific content.
here is another one: (assuming related)
The stable fix is reverted, and the nightly one is also but introduced another fix. I keep this open when that PR is beta-nominated, just in case.
We don't backport the fix in favor of this comment: So I'm just going to close this as fixed.

pat_src: PatternSource, bindings: &mut SmallVec<[(PatBoundCtx, FxHashSet<Ident>); 1]>, ) { <ins> let is_tuple_struct_pat = matches!(pat.kind, PatKind::TupleStruct(_, _)); </ins> // Visit all direct subpatterns of this pattern. pat.walk(&mut |pat| { debug!("resolve_pattern pat={:?} node={:?}", pat, pat.kind); match pat.kind { <del> PatKind::Ident(bmode, ident, ref sub) => { </del> <ins> // In tuple struct patterns ignore the invalid `ident @ ...`. // It will be handled as an error by the AST lowering. PatKind::Ident(bmode, ident, ref sub) if !(is_tuple_struct_pat && sub.as_ref().filter(|p| p.is_rest()).is_some()) => { </ins> // First try to resolve the identifier as some existing entity, // then fall back to a fresh binding. let has_sub = sub.is_some();


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --The bug exists in the beta, nightly, and stable build channels. : The error and the backtrace provided are produced by the stable build. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
reduced: Edit: you can actually omit the enum declaration and it still crashes :thinking: `
oh, sorry, I've already got a fix. I'll post it soon. Though it may not be the best one.
Great! You should tweak not losing diags. For further reference, you could do when you work on an issue to avoid conflicts.
okay, thanks. Better late than never… claim
This is caused by , I believe. 1.44 emits errors w/o ICE'ing but 1.45 hits it. godbolt (1.44): godbolt (1.45):
Let's keep this open to track stable/beta backports.
The reference suggested this to be possible, which is how I came to suggest it to OP. We wanted to avoid naming them to not suggest any specific content.
here is another one: (assuming related)
The stable fix is reverted, and the nightly one is also but introduced another fix. I keep this open when that PR is beta-nominated, just in case.
We don't backport the fix in favor of this comment: So I'm just going to close this as fixed.

<ins> enum E { A(u8, u8), } fn main() { let e = E::A(2, 3); match e { E::A(x @ ..) => {  //~ ERROR `x @` is not allowed in a tuple x //~ ERROR cannot find value `x` in this scope } }; } </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --The bug exists in the beta, nightly, and stable build channels. : The error and the backtrace provided are produced by the stable build. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
reduced: Edit: you can actually omit the enum declaration and it still crashes :thinking: `
oh, sorry, I've already got a fix. I'll post it soon. Though it may not be the best one.
Great! You should tweak not losing diags. For further reference, you could do when you work on an issue to avoid conflicts.
okay, thanks. Better late than never… claim
This is caused by , I believe. 1.44 emits errors w/o ICE'ing but 1.45 hits it. godbolt (1.44): godbolt (1.45):
Let's keep this open to track stable/beta backports.
The reference suggested this to be possible, which is how I came to suggest it to OP. We wanted to avoid naming them to not suggest any specific content.
here is another one: (assuming related)
The stable fix is reverted, and the nightly one is also but introduced another fix. I keep this open when that PR is beta-nominated, just in case.
We don't backport the fix in favor of this comment: So I'm just going to close this as fixed.

<ins> error[E0425]: cannot find value `x` in this scope --> $DIR/issue-74539.rs:9:13 | LL |             x |             ^ help: a local variable with a similar name exists: `e` error: `x @` is not allowed in a tuple struct --> $DIR/issue-74539.rs:8:14 | LL |         E::A(x @ ..) => { |              ^^^^^^ this is only allowed in slice patterns | = help: remove this and bind each tuple field independently help: if you don't need to use the contents of x, discard the tuple's remaining fields | LL |         E::A(..) => { |              ^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0425`. </ins>


Question:
I tried to compile this code: I expected the code to compile Instead, it failed to compile with this lifetime error: If I change the function in these ways it compiles. This compiles successfully on Stable Rust 1.45.0 back to 1.26.0 (when lifetimes were stabilized) This fails to compile on these versions(haven't tried previous ones in the same channels): 1.46.0-beta.2 (2020-07-23 ) 1.47.0-nightly (2020-07-28 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Let’s find the culprit for this. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Assigning as and removing .
Regressed in which is a roll-up, likely
cc in case you want to fix this is a follow-up of
The explicit lifetimes are edit: the lt of doesn't matter
assigning to but they will probably need to delegate as there time is limited in near future.
Will look into this today. claim
This code compiles in Rust 1.17 but not in Rust 1.18+: unifies DerefMut/IndexMut to use the "fix-up" path originally used when performing method calls, so it broadens the bug to assignments as well.
Okay, this is an issue near convertplaceoptomutable. Just re-infer the index type and re-do the coercion is sufficient to fix the regionck failure (). However I am not sure why the existing code does not work. This piece of code is last touched in . cc do you have any clue why the existing approach does not work well with regionck?
Hmm.. I would not have expected that code to have to change, since the failure seems to try to make the anonymous lifetime on in the method match , which it should not. I think your patch is sound, but touching the "wrong" thing. Basically now we are creating new lifetimes for the index, when I would have thought that the container type's reference's lifetime needs adjustment. So looking at , I'm guessing is taking the wrong region and should instead invent a new one?
This issue is not related to anonymous lifetime actually, if you spell out the lifetime explicitly it's still the same. The root cause has been identified and that line actually is the culprit, a detailed analysis can be found in .
I a couple of examples of workarounds that allowed the function to compile, with the same signature.

use rustc_span::symbol::{sym, Ident}; use rustc_span::Span; use rustc_trait_selection::autoderef::Autoderef; <ins> use std::slice; </ins> impl<'a, 'tcx> FnCtxt<'a, 'tcx> { /// Type-check `*oprnd_expr` with `oprnd_expr` type-checked already.


Question:
I tried to compile this code: I expected the code to compile Instead, it failed to compile with this lifetime error: If I change the function in these ways it compiles. This compiles successfully on Stable Rust 1.45.0 back to 1.26.0 (when lifetimes were stabilized) This fails to compile on these versions(haven't tried previous ones in the same channels): 1.46.0-beta.2 (2020-07-23 ) 1.47.0-nightly (2020-07-28 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Let’s find the culprit for this. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Assigning as and removing .
Regressed in which is a roll-up, likely
cc in case you want to fix this is a follow-up of
The explicit lifetimes are edit: the lt of doesn't matter
assigning to but they will probably need to delegate as there time is limited in near future.
Will look into this today. claim
This code compiles in Rust 1.17 but not in Rust 1.18+: unifies DerefMut/IndexMut to use the "fix-up" path originally used when performing method calls, so it broadens the bug to assignments as well.
Okay, this is an issue near convertplaceoptomutable. Just re-infer the index type and re-do the coercion is sufficient to fix the regionck failure (). However I am not sure why the existing code does not work. This piece of code is last touched in . cc do you have any clue why the existing approach does not work well with regionck?
Hmm.. I would not have expected that code to have to change, since the failure seems to try to make the anonymous lifetime on in the method match , which it should not. I think your patch is sound, but touching the "wrong" thing. Basically now we are creating new lifetimes for the index, when I would have thought that the container type's reference's lifetime needs adjustment. So looking at , I'm guessing is taking the wrong region and should instead invent a new one?
This issue is not related to anonymous lifetime actually, if you spell out the lifetime explicitly it's still the same. The root cause has been identified and that line actually is the culprit, a detailed analysis can be found in .
I a couple of examples of workarounds that allowed the function to compile, with the same signature.

} match expr.kind { <del> hir::ExprKind::Index(ref base_expr, ref index_expr) => { // We need to get the final type in case dereferences were needed for the trait // to apply (#72002). let index_expr_ty = self.typeck_results.borrow().expr_ty_adjusted(index_expr); self.convert_place_op_to_mutable( PlaceOp::Index, expr, base_expr, &[index_expr_ty], ); </del> <ins> hir::ExprKind::Index(ref base_expr, ..) => { self.convert_place_op_to_mutable(PlaceOp::Index, expr, base_expr); </ins> } hir::ExprKind::Unary(hir::UnOp::UnDeref, ref base_expr) => { <del> self.convert_place_op_to_mutable(PlaceOp::Deref, expr, base_expr, &[]); </del> <ins> self.convert_place_op_to_mutable(PlaceOp::Deref, expr, base_expr); </ins> } _ => {} }


Question:
I tried to compile this code: I expected the code to compile Instead, it failed to compile with this lifetime error: If I change the function in these ways it compiles. This compiles successfully on Stable Rust 1.45.0 back to 1.26.0 (when lifetimes were stabilized) This fails to compile on these versions(haven't tried previous ones in the same channels): 1.46.0-beta.2 (2020-07-23 ) 1.47.0-nightly (2020-07-28 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Let’s find the culprit for this. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Assigning as and removing .
Regressed in which is a roll-up, likely
cc in case you want to fix this is a follow-up of
The explicit lifetimes are edit: the lt of doesn't matter
assigning to but they will probably need to delegate as there time is limited in near future.
Will look into this today. claim
This code compiles in Rust 1.17 but not in Rust 1.18+: unifies DerefMut/IndexMut to use the "fix-up" path originally used when performing method calls, so it broadens the bug to assignments as well.
Okay, this is an issue near convertplaceoptomutable. Just re-infer the index type and re-do the coercion is sufficient to fix the regionck failure (). However I am not sure why the existing code does not work. This piece of code is last touched in . cc do you have any clue why the existing approach does not work well with regionck?
Hmm.. I would not have expected that code to have to change, since the failure seems to try to make the anonymous lifetime on in the method match , which it should not. I think your patch is sound, but touching the "wrong" thing. Basically now we are creating new lifetimes for the index, when I would have thought that the container type's reference's lifetime needs adjustment. So looking at , I'm guessing is taking the wrong region and should instead invent a new one?
This issue is not related to anonymous lifetime actually, if you spell out the lifetime explicitly it's still the same. The root cause has been identified and that line actually is the culprit, a detailed analysis can be found in .
I a couple of examples of workarounds that allowed the function to compile, with the same signature.

op: PlaceOp, expr: &hir::Expr<'_>, base_expr: &hir::Expr<'_>, <del> arg_tys: &[Ty<'tcx>], </del> ) { <del> debug!("convert_place_op_to_mutable({:?}, {:?}, {:?}, {:?})", op, expr, base_expr, arg_tys); </del> <ins> debug!("convert_place_op_to_mutable({:?}, {:?}, {:?})", op, expr, base_expr); </ins> if !self.typeck_results.borrow().is_method_call(expr) { debug!("convert_place_op_to_mutable - builtin, nothing to do"); return;


Question:
I tried to compile this code: I expected the code to compile Instead, it failed to compile with this lifetime error: If I change the function in these ways it compiles. This compiles successfully on Stable Rust 1.45.0 back to 1.26.0 (when lifetimes were stabilized) This fails to compile on these versions(haven't tried previous ones in the same channels): 1.46.0-beta.2 (2020-07-23 ) 1.47.0-nightly (2020-07-28 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Let’s find the culprit for this. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Assigning as and removing .
Regressed in which is a roll-up, likely
cc in case you want to fix this is a follow-up of
The explicit lifetimes are edit: the lt of doesn't matter
assigning to but they will probably need to delegate as there time is limited in near future.
Will look into this today. claim
This code compiles in Rust 1.17 but not in Rust 1.18+: unifies DerefMut/IndexMut to use the "fix-up" path originally used when performing method calls, so it broadens the bug to assignments as well.
Okay, this is an issue near convertplaceoptomutable. Just re-infer the index type and re-do the coercion is sufficient to fix the regionck failure (). However I am not sure why the existing code does not work. This piece of code is last touched in . cc do you have any clue why the existing approach does not work well with regionck?
Hmm.. I would not have expected that code to have to change, since the failure seems to try to make the anonymous lifetime on in the method match , which it should not. I think your patch is sound, but touching the "wrong" thing. Basically now we are creating new lifetimes for the index, when I would have thought that the container type's reference's lifetime needs adjustment. So looking at , I'm guessing is taking the wrong region and should instead invent a new one?
This issue is not related to anonymous lifetime actually, if you spell out the lifetime explicitly it's still the same. The root cause has been identified and that line actually is the culprit, a detailed analysis can be found in .
I a couple of examples of workarounds that allowed the function to compile, with the same signature.

.expect("place op takes something that is not a ref") .ty; <ins> let arg_ty = match op { PlaceOp::Deref => None, PlaceOp::Index => { // We would need to recover the `T` used when we resolve `<_ as Index<T>>::index` // in try_index_step. This is the subst at index 1. // // Note: we should *not* use `expr_ty` of index_expr here because autoderef // during coercions can cause type of index_expr to differ from `T` (#72002). // We also could not use `expr_ty_adjusted` of index_expr because reborrowing // during coercions can also cause type of index_expr to differ from `T`, // which can potentially cause regionck failure (#74933). Some(self.typeck_results.borrow().node_substs(expr.hir_id).type_at(1)) } }; let arg_tys = match arg_ty { None => &[], Some(ref ty) => slice::from_ref(ty), }; </ins> let method = self.try_mutable_overloaded_place_op(expr.span, base_ty, arg_tys, op); let method = match method { Some(ok) => self.register_infer_ok_obligations(ok),


Question:
I tried to compile this code: I expected the code to compile Instead, it failed to compile with this lifetime error: If I change the function in these ways it compiles. This compiles successfully on Stable Rust 1.45.0 back to 1.26.0 (when lifetimes were stabilized) This fails to compile on these versions(haven't tried previous ones in the same channels): 1.46.0-beta.2 (2020-07-23 ) 1.47.0-nightly (2020-07-28 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Let’s find the culprit for this. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Assigning as and removing .
Regressed in which is a roll-up, likely
cc in case you want to fix this is a follow-up of
The explicit lifetimes are edit: the lt of doesn't matter
assigning to but they will probably need to delegate as there time is limited in near future.
Will look into this today. claim
This code compiles in Rust 1.17 but not in Rust 1.18+: unifies DerefMut/IndexMut to use the "fix-up" path originally used when performing method calls, so it broadens the bug to assignments as well.
Okay, this is an issue near convertplaceoptomutable. Just re-infer the index type and re-do the coercion is sufficient to fix the regionck failure (). However I am not sure why the existing code does not work. This piece of code is last touched in . cc do you have any clue why the existing approach does not work well with regionck?
Hmm.. I would not have expected that code to have to change, since the failure seems to try to make the anonymous lifetime on in the method match , which it should not. I think your patch is sound, but touching the "wrong" thing. Basically now we are creating new lifetimes for the index, when I would have thought that the container type's reference's lifetime needs adjustment. So looking at , I'm guessing is taking the wrong region and should instead invent a new one?
This issue is not related to anonymous lifetime actually, if you spell out the lifetime explicitly it's still the same. The root cause has been identified and that line actually is the culprit, a detailed analysis can be found in .
I a couple of examples of workarounds that allowed the function to compile, with the same signature.

<ins> // check-pass // // rust-lang/rust#74933: Lifetime error when indexing with borrowed index use std::ops::{Index, IndexMut}; struct S(V); struct K<'a>(&'a ()); struct V; impl<'a> Index<&'a K<'a>> for S { type Output = V; fn index(&self, _: &'a K<'a>) -> &V { &self.0 } } impl<'a> IndexMut<&'a K<'a>> for S { fn index_mut(&mut self, _: &'a K<'a>) -> &mut V { &mut self.0 } } impl V { fn foo(&mut self) {} } fn test(s: &mut S, k: &K<'_>) { s[k] = V; s[k].foo(); } fn main() { let mut s = S(V); let k = K(&()); test(&mut s, &k); } </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --It is very finicky to reproduce. is as minimal as I could get without significantly changing the structure of the macro or having other errors cover it up. Apologies for the mess! Updated 2020-08-04: I got it down to a total of only 130 lines of code. Please review the improved output below. Instructions: the project: The ICE was triggered by change in , where I simply changed the scoping on a nested inner generated by a macro from public to private. : On stable, errors regarding scoping are printed (this error is repeated many times): On nightly, a backtrace occurs. <details<summary<strongBacktrace</strong</summary<p</p</details<details<summary<strongcargo expand with pub struct (updated 2020-08-04)</strong</summary<p</p</details
I have reduced this reproducer from about 500 lines of code total to 130 lines total. There are more syntax errors in it now, but the panic still triggers before them. Most of the other things I could change create an error that short circuits the compiler before the panic could trigger. EDIT: I also just updated the backtrace, because I didn't ask for a backtrace last time.
Let's get a MCVE and bisect the culprit PR. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Minimized:
is the likely cause.
Assigning as and removing .

) = binding.kind { let def_id = (&*self).parent(ctor_def_id).expect("no parent for a constructor"); <del> if let Some(fields) = self.field_names.get(&def_id) { let first_field = fields.first().expect("empty field list in the map"); return Some(fields.iter().fold(first_field.span, |acc, field| acc.to(field.span))); } </del> <ins> let fields = self.field_names.get(&def_id)?; let first_field = fields.first()?; // Handle `struct Foo()` return Some(fields.iter().fold(first_field.span, |acc, field| acc.to(field.span))); </ins> } None }


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --It is very finicky to reproduce. is as minimal as I could get without significantly changing the structure of the macro or having other errors cover it up. Apologies for the mess! Updated 2020-08-04: I got it down to a total of only 130 lines of code. Please review the improved output below. Instructions: the project: The ICE was triggered by change in , where I simply changed the scoping on a nested inner generated by a macro from public to private. : On stable, errors regarding scoping are printed (this error is repeated many times): On nightly, a backtrace occurs. <details<summary<strongBacktrace</strong</summary<p</p</details<details<summary<strongcargo expand with pub struct (updated 2020-08-04)</strong</summary<p</p</details
I have reduced this reproducer from about 500 lines of code total to 130 lines total. There are more syntax errors in it now, but the panic still triggers before them. Most of the other things I could change create an error that short circuits the compiler before the panic could trigger. EDIT: I also just updated the backtrace, because I didn't ask for a backtrace last time.
Let's get a MCVE and bisect the culprit PR. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Minimized:
is the likely cause.
Assigning as and removing .

<ins> // Regression test for issue #75062 // Tests that we don't ICE on a privacy error for a fieldless tuple struct. mod foo { struct Bar(); } fn main() { foo::Bar(); //~ ERROR tuple struct } </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --It is very finicky to reproduce. is as minimal as I could get without significantly changing the structure of the macro or having other errors cover it up. Apologies for the mess! Updated 2020-08-04: I got it down to a total of only 130 lines of code. Please review the improved output below. Instructions: the project: The ICE was triggered by change in , where I simply changed the scoping on a nested inner generated by a macro from public to private. : On stable, errors regarding scoping are printed (this error is repeated many times): On nightly, a backtrace occurs. <details<summary<strongBacktrace</strong</summary<p</p</details<details<summary<strongcargo expand with pub struct (updated 2020-08-04)</strong</summary<p</p</details
I have reduced this reproducer from about 500 lines of code total to 130 lines total. There are more syntax errors in it now, but the panic still triggers before them. Most of the other things I could change create an error that short circuits the compiler before the panic could trigger. EDIT: I also just updated the backtrace, because I didn't ask for a backtrace last time.
Let's get a MCVE and bisect the culprit PR. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Minimized:
is the likely cause.
Assigning as and removing .

<ins> error[E0603]: tuple struct `Bar` is private --> $DIR/issue-75062-fieldless-tuple-struct.rs:9:10 | LL |     foo::Bar(); |          ^^^ private tuple struct | note: the tuple struct `Bar` is defined here --> $DIR/issue-75062-fieldless-tuple-struct.rs:5:5 | LL |     struct Bar(); |     ^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0603`. </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --The following code compiles just fine but when trying to run on it I get the error described below <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Making this even more strange, this does not panic with instead.
<details<summaryBacktrace</summary</detailsRustdoc code:
The main function is not necessary, it also crashes on
Yeah this one is beyond me, I have no idea why this is breaking.
This never worked with ; on it says the feature isn't recognized and on it crashes.
Huh, I built that last code snippet in the Rust Playground and it compiled fine:
yes, it only crashes with rustdoc, which isn't available on the playground.
Oops, I missed that part. Sorry about that!
Feel free to ping me on all issues related to const generics claim
Thanks for fixing this!

TyKind::Slice(ref ty) => Slice(box ty.clean(cx)), TyKind::Array(ref ty, ref length) => { let def_id = cx.tcx.hir().local_def_id(length.hir_id); <del> let length = match cx.tcx.const_eval_poly(def_id.to_def_id()) { Ok(length) => { print_const(cx, ty::Const::from_value(cx.tcx, length, cx.tcx.types.usize)) } Err(_) => cx .sess() .source_map() .span_to_snippet(cx.tcx.def_span(def_id)) .unwrap_or_else(|_| "_".to_string()), }; </del> <ins> // NOTE(min_const_generics): We can't use `const_eval_poly` for constants // as we currently do not supply the parent generics to anonymous constants // but do allow `ConstKind::Param`. // // `const_eval_poly` tries to to first substitute generic parameters which // results in an ICE while manually constructing the constant and using `eval` // does nothing for `ConstKind::Param`. let ct = ty::Const::from_anon_const(cx.tcx, def_id); let param_env = cx.tcx.param_env(def_id); let length = print_const(cx, ct.eval(cx.tcx, param_env)); </ins> Array(box ty.clean(cx), length) } TyKind::Tup(ref tys) => Tuple(tys.clean(cx)),


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --The following code compiles just fine but when trying to run on it I get the error described below <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Making this even more strange, this does not panic with instead.
<details<summaryBacktrace</summary</detailsRustdoc code:
The main function is not necessary, it also crashes on
Yeah this one is beyond me, I have no idea why this is breaking.
This never worked with ; on it says the feature isn't recognized and on it crashes.
Huh, I built that last code snippet in the Rust Playground and it compiled fine:
yes, it only crashes with rustdoc, which isn't available on the playground.
Oops, I missed that part. Sorry about that!
Feel free to ping me on all issues related to const generics claim
Thanks for fixing this!

<ins> // ignore-tidy-linelength #![feature(min_const_generics)] #![crate_name = "foo"] // @has foo/type.CellIndex.html '//pre[@class="rust typedef"]' 'type CellIndex<const D: usize> = [i64; D];' pub type CellIndex<const D: usize> = [i64; D]; </ins>


Question:
to in the implementation of . This is correct for simple types like , but when 's implementation accesses borrowed data, this might lead to accessing already dropped data:
and also use in their impl. But I can't reproduce this problem with either of those instead of . Not sure why only seems to have this problem. Edit: Probably because contains in a , which doesn't implement . Adding a should fix that. (Testing that now.)
I think the problem is that puts no lifetime constraint on , so you can write any arbitrarily short-lived to the cell. It would have to at least outlive the reference.
Cc likely this affects upstream once_cell as well?
That's also the case for a Vec: This compiles fine. (As it should.) Replacing with from above here does give an error though, like it should. Looks like dropck does understand that 's is going to drop s. Looks like is what made that work properly for Vec and Box:
Oh, yeah, you're right
Doesn't look like it: the crate uses instead of :

use crate::{ cell::{Cell, UnsafeCell}, fmt, <ins> marker::PhantomData, </ins> mem::{self, MaybeUninit}, ops::{Deref, Drop}, panic::{RefUnwindSafe, UnwindSafe},


Question:
to in the implementation of . This is correct for simple types like , but when 's implementation accesses borrowed data, this might lead to accessing already dropped data:
and also use in their impl. But I can't reproduce this problem with either of those instead of . Not sure why only seems to have this problem. Edit: Probably because contains in a , which doesn't implement . Adding a should fix that. (Testing that now.)
I think the problem is that puts no lifetime constraint on , so you can write any arbitrarily short-lived to the cell. It would have to at least outlive the reference.
Cc likely this affects upstream once_cell as well?
That's also the case for a Vec: This compiles fine. (As it should.) Replacing with from above here does give an error though, like it should. Looks like dropck does understand that 's is going to drop s. Looks like is what made that work properly for Vec and Box:
Oh, yeah, you're right
Doesn't look like it: the crate uses instead of :

once: Once, // Whether or not the value is initialized is tracked by `state_and_queue`. value: UnsafeCell<MaybeUninit<T>>, <ins> /// `PhantomData` to make sure dropck understands we're dropping T in our Drop impl. /// /// ```compile_fail,E0597 /// #![feature(once_cell)] /// /// use std::lazy::SyncOnceCell; /// /// struct A<'a>(&'a str); /// /// impl<'a> Drop for A<'a> { ///     fn drop(&mut self) {} /// } /// /// let cell = SyncOnceCell::new(); /// { ///     let s = String::new(); ///     let _ = cell.set(A(&s)); /// } /// ``` _marker: PhantomData<T>, </ins> } // Why do we need `T: Send`?


Question:
to in the implementation of . This is correct for simple types like , but when 's implementation accesses borrowed data, this might lead to accessing already dropped data:
and also use in their impl. But I can't reproduce this problem with either of those instead of . Not sure why only seems to have this problem. Edit: Probably because contains in a , which doesn't implement . Adding a should fix that. (Testing that now.)
I think the problem is that puts no lifetime constraint on , so you can write any arbitrarily short-lived to the cell. It would have to at least outlive the reference.
Cc likely this affects upstream once_cell as well?
That's also the case for a Vec: This compiles fine. (As it should.) Replacing with from above here does give an error though, like it should. Looks like dropck does understand that 's is going to drop s. Looks like is what made that work properly for Vec and Box:
Oh, yeah, you're right
Doesn't look like it: the crate uses instead of :

/// Creates a new empty cell. #[unstable(feature = "once_cell", issue = "74465")] pub const fn new() -> SyncOnceCell<T> { <del> SyncOnceCell { once: Once::new(), value: UnsafeCell::new(MaybeUninit::uninit()) } </del> <ins> SyncOnceCell { once: Once::new(), value: UnsafeCell::new(MaybeUninit::uninit()), _marker: PhantomData, } </ins> } /// Gets the reference to the underlying value.


Question:
Between nightly-2020-09-05 and nightly-2020-09-06, libproc_macro stopped preserving the jointness of a trailing joint punctuation token in a TokenStream (likely ; This breaks some real-world code such as the following, though only with old versions of some libraries as far as I have found. I don't know which behavior above is correct but I would like it to be intentionally decided so that we know what behavior to implement in proc-macro2. fails to compile since nightly-2020-09-06:
This has also broken 's webrender-wrench, which relied on this behavior in one of the dependencies. -- do you think a revert makes sense perhaps? Is there a patch expected soon-ish?
Marking this as P-critical based on the

self.index = index; } <del> pub fn look_ahead(&self, n: usize) -> Option<&TokenTree> { self.stream.0[self.index..].get(n).map(|(tree, _)| tree) </del> <ins> pub fn look_ahead(&self, n: usize) -> Option<TokenTree> { self.stream.0[self.index..].get(n).map(|(tree, _)| tree.clone()) </ins> } }


Question:
Between nightly-2020-09-05 and nightly-2020-09-06, libproc_macro stopped preserving the jointness of a trailing joint punctuation token in a TokenStream (likely ; This breaks some real-world code such as the following, though only with old versions of some libraries as far as I have found. I don't know which behavior above is correct but I would like it to be intentionally decided so that we know what behavior to implement in proc-macro2. fails to compile since nightly-2020-09-06:
This has also broken 's webrender-wrench, which relied on this behavior in one of the dependencies. -- do you think a revert makes sense perhaps? Is there a patch expected soon-ish?
Marking this as P-critical based on the

} } <del> impl FromInternal<( TreeAndJoint, Option<&'_ tokenstream::TokenTree>, &'_ ParseSess, &'_ mut Vec<Self>, )> for TokenTree<Group, Punct, Ident, Literal> </del> <ins> impl FromInternal<(TreeAndJoint, &'_ ParseSess, &'_ mut Vec<Self>)> for TokenTree<Group, Punct, Ident, Literal> </ins> { fn from_internal( <del> ((tree, is_joint), look_ahead, sess, stack): ( TreeAndJoint, Option<&tokenstream::TokenTree>, &ParseSess, &mut Vec<Self>, ), </del> <ins> ((tree, is_joint), sess, stack): (TreeAndJoint, &ParseSess, &mut Vec<Self>), </ins> ) -> Self { use rustc_ast::token::*; <del> let joint = is_joint == Joint && matches!(look_ahead, Some(tokenstream::TokenTree::Token(t)) if t.is_op()); </del> <ins> let joint = is_joint == Joint; </ins> let Token { kind, span } = match tree { tokenstream::TokenTree::Delimited(span, delim, tts) => { let delimiter = Delimiter::from_internal(delim);


Question:
Between nightly-2020-09-05 and nightly-2020-09-06, libproc_macro stopped preserving the jointness of a trailing joint punctuation token in a TokenStream (likely ; This breaks some real-world code such as the following, though only with old versions of some libraries as far as I have found. I don't know which behavior above is correct but I would like it to be intentionally decided so that we know what behavior to implement in proc-macro2. fails to compile since nightly-2020-09-06:
This has also broken 's webrender-wrench, which relied on this behavior in one of the dependencies. -- do you think a revert makes sense perhaps? Is there a patch expected soon-ish?
Marking this as P-critical based on the

loop { let tree = iter.stack.pop().or_else(|| { let next = iter.cursor.next_with_joint()?; <del> let lookahead = iter.cursor.look_ahead(0); Some(TokenTree::from_internal((next, lookahead, self.sess, &mut iter.stack))) </del> <ins> Some(TokenTree::from_internal((next, self.sess, &mut iter.stack))) </ins> })?; // A hack used to pass AST fragments to attribute and derive macros // as a single nonterminal token instead of a token stream.


Question:
Between nightly-2020-09-05 and nightly-2020-09-06, libproc_macro stopped preserving the jointness of a trailing joint punctuation token in a TokenStream (likely ; This breaks some real-world code such as the following, though only with old versions of some libraries as far as I have found. I don't know which behavior above is correct but I would like it to be intentionally decided so that we know what behavior to implement in proc-macro2. fails to compile since nightly-2020-09-06:
This has also broken 's webrender-wrench, which relied on this behavior in one of the dependencies. -- do you think a revert makes sense perhaps? Is there a patch expected soon-ish?
Marking this as P-critical based on the

} _ => { let tt = TokenTree::Token(self.token.take()); <del> let is_joint = self.bump(); </del> <ins> let mut is_joint = self.bump(); if !self.token.is_op() { is_joint = NonJoint; } </ins> Ok((tt, is_joint)) } }


Question:
Between nightly-2020-09-05 and nightly-2020-09-06, libproc_macro stopped preserving the jointness of a trailing joint punctuation token in a TokenStream (likely ; This breaks some real-world code such as the following, though only with old versions of some libraries as far as I have found. I don't know which behavior above is correct but I would like it to be intentionally decided so that we know what behavior to implement in proc-macro2. fails to compile since nightly-2020-09-06:
This has also broken 's webrender-wrench, which relied on this behavior in one of the dependencies. -- do you think a revert makes sense perhaps? Is there a patch expected soon-ish?
Marking this as P-critical based on the

} let frame = &self.token_cursor.frame; <del> match frame.tree_cursor.look_ahead(dist - 1) { </del> <ins> looker(&match frame.tree_cursor.look_ahead(dist - 1) { </ins> Some(tree) => match tree { <del> TokenTree::Token(token) => looker(token), </del> <ins> TokenTree::Token(token) => token, </ins> TokenTree::Delimited(dspan, delim, _) => { <del> looker(&Token::new(token::OpenDelim(delim.clone()), dspan.open)) </del> <ins> Token::new(token::OpenDelim(delim), dspan.open) </ins> } }, <del> None => looker(&Token::new(token::CloseDelim(frame.delim), frame.span.close)), } </del> <ins> None => Token::new(token::CloseDelim(frame.delim), frame.span.close), }) </ins> } /// Returns whether any of the given keywords are `dist` tokens ahead of the current one.


Question:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for saturating operations. The feature gate for the issue is . <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implement the proposal: [x] FCP [x] Stabilization PR: <!-- Include any open questions that need to be answered before the feature can be stabilised. --
Just needed when dealing with time intervals. Also, unresloved questions seem to be from another tracking issue?
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
I am very happy to see this stabilized. One thing I wanted to discuss is the documentation: it currently mentions two associated constants: But both are currently unstable. Should they be stabilized at the same time? Or should the documentation updated? It seems a bit weird that the documentation for stable methods is mentioning unstable features and therefore the code examples cannot be executed and verified on stable. This is really a newbie question, I don't know what is the correct approach here. I am pretty sure such circumstances have happened before? Also, once that question is resolved, I would be very glad to do the stabilization PR. It's my first tracking issue and it would kind of be a personal accomplishment :+1:
is being stabilized at the same time: still needs to be stabilized. it's suggested that that constant should probably not be part of the same tracking issue as the other constants there (, etc.). Feel free to send a PR that stabilizes just , then we can do an FCP on that PR and we'll remove it from that tracking issue. Feel free to make that PR without waiting for . In this specific case I don't think it's a problem if this gets stabilized while the docs still refer to something unstable. is pretty clear and uncontroversial. Even if it's unstable, it's still the best way we have to refer to the maximum value of a . (And it'll probably be stable anyway in ~two weeks.)

#![cfg_attr(bootstrap, feature(doc_spotlight))] #![cfg_attr(not(bootstrap), feature(doc_notable_trait))] #![feature(duration_consts_2)] <del> #![feature(duration_saturating_ops)] </del> #![feature(extended_key_value_attributes)] #![feature(extern_types)] #![feature(fundamental)]


Question:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for saturating operations. The feature gate for the issue is . <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implement the proposal: [x] FCP [x] Stabilization PR: <!-- Include any open questions that need to be answered before the feature can be stabilised. --
Just needed when dealing with time intervals. Also, unresloved questions seem to be from another tracking issue?
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
I am very happy to see this stabilized. One thing I wanted to discuss is the documentation: it currently mentions two associated constants: But both are currently unstable. Should they be stabilized at the same time? Or should the documentation updated? It seems a bit weird that the documentation for stable methods is mentioning unstable features and therefore the code examples cannot be executed and verified on stable. This is really a newbie question, I don't know what is the correct approach here. I am pretty sure such circumstances have happened before? Also, once that question is resolved, I would be very glad to do the stabilization PR. It's my first tracking issue and it would kind of be a personal accomplishment :+1:
is being stabilized at the same time: still needs to be stabilized. it's suggested that that constant should probably not be part of the same tracking issue as the other constants there (, etc.). Feel free to send a PR that stabilizes just , then we can do an FCP on that PR and we'll remove it from that tracking issue. Feel free to make that PR without waiting for . In this specific case I don't think it's a problem if this gets stabilized while the docs still refer to something unstable. is pretty clear and uncontroversial. Even if it's unstable, it's still the best way we have to refer to the maximum value of a . (And it'll probably be stable anyway in ~two weeks.)

/// # Examples /// /// ``` <del> /// #![feature(duration_saturating_ops)] </del> /// #![feature(duration_constants)] /// use std::time::Duration; /// /// assert_eq!(Duration::new(0, 0).saturating_add(Duration::new(0, 1)), Duration::new(0, 1)); /// assert_eq!(Duration::new(1, 0).saturating_add(Duration::new(u64::MAX, 0)), Duration::MAX); /// ``` <del> #[unstable(feature = "duration_saturating_ops", issue = "76416")] </del> <ins> #[stable(feature = "duration_saturating_ops", since = "1.53.0")] </ins> #[inline] #[rustc_const_unstable(feature = "duration_consts_2", issue = "72440")] pub const fn saturating_add(self, rhs: Duration) -> Duration {


Question:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for saturating operations. The feature gate for the issue is . <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implement the proposal: [x] FCP [x] Stabilization PR: <!-- Include any open questions that need to be answered before the feature can be stabilised. --
Just needed when dealing with time intervals. Also, unresloved questions seem to be from another tracking issue?
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
I am very happy to see this stabilized. One thing I wanted to discuss is the documentation: it currently mentions two associated constants: But both are currently unstable. Should they be stabilized at the same time? Or should the documentation updated? It seems a bit weird that the documentation for stable methods is mentioning unstable features and therefore the code examples cannot be executed and verified on stable. This is really a newbie question, I don't know what is the correct approach here. I am pretty sure such circumstances have happened before? Also, once that question is resolved, I would be very glad to do the stabilization PR. It's my first tracking issue and it would kind of be a personal accomplishment :+1:
is being stabilized at the same time: still needs to be stabilized. it's suggested that that constant should probably not be part of the same tracking issue as the other constants there (, etc.). Feel free to send a PR that stabilizes just , then we can do an FCP on that PR and we'll remove it from that tracking issue. Feel free to make that PR without waiting for . In this specific case I don't think it's a problem if this gets stabilized while the docs still refer to something unstable. is pretty clear and uncontroversial. Even if it's unstable, it's still the best way we have to refer to the maximum value of a . (And it'll probably be stable anyway in ~two weeks.)

/// # Examples /// /// ``` <del> /// #![feature(duration_saturating_ops)] </del> /// #![feature(duration_zero)] /// use std::time::Duration; /// /// assert_eq!(Duration::new(0, 1).saturating_sub(Duration::new(0, 0)), Duration::new(0, 1)); /// assert_eq!(Duration::new(0, 0).saturating_sub(Duration::new(0, 1)), Duration::ZERO); /// ``` <del> #[unstable(feature = "duration_saturating_ops", issue = "76416")] </del> <ins> #[stable(feature = "duration_saturating_ops", since = "1.53.0")] </ins> #[inline] #[rustc_const_unstable(feature = "duration_consts_2", issue = "72440")] pub const fn saturating_sub(self, rhs: Duration) -> Duration {


Question:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for saturating operations. The feature gate for the issue is . <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implement the proposal: [x] FCP [x] Stabilization PR: <!-- Include any open questions that need to be answered before the feature can be stabilised. --
Just needed when dealing with time intervals. Also, unresloved questions seem to be from another tracking issue?
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
I am very happy to see this stabilized. One thing I wanted to discuss is the documentation: it currently mentions two associated constants: But both are currently unstable. Should they be stabilized at the same time? Or should the documentation updated? It seems a bit weird that the documentation for stable methods is mentioning unstable features and therefore the code examples cannot be executed and verified on stable. This is really a newbie question, I don't know what is the correct approach here. I am pretty sure such circumstances have happened before? Also, once that question is resolved, I would be very glad to do the stabilization PR. It's my first tracking issue and it would kind of be a personal accomplishment :+1:
is being stabilized at the same time: still needs to be stabilized. it's suggested that that constant should probably not be part of the same tracking issue as the other constants there (, etc.). Feel free to send a PR that stabilizes just , then we can do an FCP on that PR and we'll remove it from that tracking issue. Feel free to make that PR without waiting for . In this specific case I don't think it's a problem if this gets stabilized while the docs still refer to something unstable. is pretty clear and uncontroversial. Even if it's unstable, it's still the best way we have to refer to the maximum value of a . (And it'll probably be stable anyway in ~two weeks.)

/// # Examples /// /// ``` <del> /// #![feature(duration_saturating_ops)] </del> /// #![feature(duration_constants)] /// use std::time::Duration; /// /// assert_eq!(Duration::new(0, 500_000_001).saturating_mul(2), Duration::new(1, 2)); /// assert_eq!(Duration::new(u64::MAX - 1, 0).saturating_mul(2), Duration::MAX); /// ``` <del> #[unstable(feature = "duration_saturating_ops", issue = "76416")] </del> <ins> #[stable(feature = "duration_saturating_ops", since = "1.53.0")] </ins> #[inline] #[rustc_const_unstable(feature = "duration_consts_2", issue = "72440")] pub const fn saturating_mul(self, rhs: u32) -> Duration {


Question:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for saturating operations. The feature gate for the issue is . <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implement the proposal: [x] FCP [x] Stabilization PR: <!-- Include any open questions that need to be answered before the feature can be stabilised. --
Just needed when dealing with time intervals. Also, unresloved questions seem to be from another tracking issue?
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
I am very happy to see this stabilized. One thing I wanted to discuss is the documentation: it currently mentions two associated constants: But both are currently unstable. Should they be stabilized at the same time? Or should the documentation updated? It seems a bit weird that the documentation for stable methods is mentioning unstable features and therefore the code examples cannot be executed and verified on stable. This is really a newbie question, I don't know what is the correct approach here. I am pretty sure such circumstances have happened before? Also, once that question is resolved, I would be very glad to do the stabilization PR. It's my first tracking issue and it would kind of be a personal accomplishment :+1:
is being stabilized at the same time: still needs to be stabilized. it's suggested that that constant should probably not be part of the same tracking issue as the other constants there (, etc.). Feel free to send a PR that stabilizes just , then we can do an FCP on that PR and we'll remove it from that tracking issue. Feel free to make that PR without waiting for . In this specific case I don't think it's a problem if this gets stabilized while the docs still refer to something unstable. is pretty clear and uncontroversial. Even if it's unstable, it's still the best way we have to refer to the maximum value of a . (And it'll probably be stable anyway in ~two weeks.)

#![feature(div_duration)] #![feature(duration_consts_2)] #![feature(duration_constants)] <del> #![feature(duration_saturating_ops)] </del> #![feature(duration_zero)] #![feature(exact_size_is_empty)] #![feature(extern_types)]


Question:
The code below does not compile on new versions of (bisect below) searched nightlies: from nightly-2020-09-11 to nightly-2020-09-12 regressed nightly: nightly-2020-09-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc
We probably just need to and likewise for Sync. Conceptually it's no different to a &mut T, so that should be reasonable.
can we assign the issue to you given that you've already provided a PR?
I'm going to self-assign, I don't expect to hit any roadblocks with the PR though, it's already bors-ready.

_marker: PhantomData<&'a mut T>, } <ins> unsafe impl<'a, T> Sync for DormantMutRef<'a, T> where &'a mut T: Sync {} unsafe impl<'a, T> Send for DormantMutRef<'a, T> where &'a mut T: Send {} </ins> impl<'a, T> DormantMutRef<'a, T> { /// Capture a unique borrow, and immediately reborrow it. For the compiler, /// the lifetime of the new reference is the same as the lifetime of the


Question:
The code below does not compile on new versions of (bisect below) searched nightlies: from nightly-2020-09-11 to nightly-2020-09-12 regressed nightly: nightly-2020-09-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc
We probably just need to and likewise for Sync. Conceptually it's no different to a &mut T, so that should be reasonable.
can we assign the issue to you given that you've already provided a PR?
I'm going to self-assign, I don't expect to hit any roadblocks with the PR though, it's already bors-ready.

} #[test] <ins> #[allow(dead_code)] fn test_sync() { fn map<T: Sync>(v: &BTreeMap<T, T>) -> impl Sync + '_ { v } fn into_iter<T: Sync>(v: BTreeMap<T, T>) -> impl Sync { v.into_iter() } fn into_keys<T: Sync + Ord>(v: BTreeMap<T, T>) -> impl Sync { v.into_keys() } fn into_values<T: Sync + Ord>(v: BTreeMap<T, T>) -> impl Sync { v.into_values() } fn drain_filter<T: Sync + Ord>(v: &mut BTreeMap<T, T>) -> impl Sync + '_ { v.drain_filter(|_, _| false) } fn iter<T: Sync>(v: &BTreeMap<T, T>) -> impl Sync + '_ { v.iter() } fn iter_mut<T: Sync>(v: &mut BTreeMap<T, T>) -> impl Sync + '_ { v.iter_mut() } fn keys<T: Sync>(v: &BTreeMap<T, T>) -> impl Sync + '_ { v.keys() } fn values<T: Sync>(v: &BTreeMap<T, T>) -> impl Sync + '_ { v.values() } fn values_mut<T: Sync>(v: &mut BTreeMap<T, T>) -> impl Sync + '_ { v.values_mut() } fn range<T: Sync + Ord>(v: &BTreeMap<T, T>) -> impl Sync + '_ { v.range(..) } fn range_mut<T: Sync + Ord>(v: &mut BTreeMap<T, T>) -> impl Sync + '_ { v.range_mut(..) } fn entry<T: Sync + Ord + Default>(v: &mut BTreeMap<T, T>) -> impl Sync + '_ { v.entry(Default::default()) } fn occupied_entry<T: Sync + Ord + Default>(v: &mut BTreeMap<T, T>) -> impl Sync + '_ { match v.entry(Default::default()) { Occupied(entry) => entry, _ => unreachable!(), } } fn vacant_entry<T: Sync + Ord + Default>(v: &mut BTreeMap<T, T>) -> impl Sync + '_ { match v.entry(Default::default()) { Vacant(entry) => entry, _ => unreachable!(), } } } #[test] #[allow(dead_code)] fn test_send() { fn map<T: Send>(v: BTreeMap<T, T>) -> impl Send { v } fn into_iter<T: Send>(v: BTreeMap<T, T>) -> impl Send { v.into_iter() } fn into_keys<T: Send + Ord>(v: BTreeMap<T, T>) -> impl Send { v.into_keys() } fn into_values<T: Send + Ord>(v: BTreeMap<T, T>) -> impl Send { v.into_values() } fn drain_filter<T: Send + Ord>(v: &mut BTreeMap<T, T>) -> impl Send + '_ { v.drain_filter(|_, _| false) } fn iter<T: Send + Sync>(v: &BTreeMap<T, T>) -> impl Send + '_ { v.iter() } fn iter_mut<T: Send + Sync>(v: &mut BTreeMap<T, T>) -> impl Send + '_ { v.iter_mut() } fn keys<T: Send + Sync>(v: &BTreeMap<T, T>) -> impl Send + '_ { v.keys() } fn values<T: Send + Sync>(v: &BTreeMap<T, T>) -> impl Send + '_ { v.values() } fn values_mut<T: Send + Sync>(v: &mut BTreeMap<T, T>) -> impl Send + '_ { v.values_mut() } fn range<T: Send + Sync + Ord>(v: &BTreeMap<T, T>) -> impl Send + '_ { v.range(..) } fn range_mut<T: Send + Sync + Ord>(v: &mut BTreeMap<T, T>) -> impl Send + '_ { v.range_mut(..) } fn entry<T: Send + Ord + Default>(v: &mut BTreeMap<T, T>) -> impl Send + '_ { v.entry(Default::default()) } fn occupied_entry<T: Send + Ord + Default>(v: &mut BTreeMap<T, T>) -> impl Send + '_ { match v.entry(Default::default()) { Occupied(entry) => entry, _ => unreachable!(), } } fn vacant_entry<T: Send + Ord + Default>(v: &mut BTreeMap<T, T>) -> impl Send + '_ { match v.entry(Default::default()) { Vacant(entry) => entry, _ => unreachable!(), } } } #[test] </ins> fn test_occupied_entry_key() { let mut a = BTreeMap::new(); let key = "hello there";


Question:
The match remains exhaustive with highlighted pattern removed, but it does not produce any warnings: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I know where the problem comes from: this bit of code tries to handle unreachable sub-or-patterns diagnostics, but it's a bit of a hack. What remains is to come up with a better solution. claim

<del> //! Note: most of the tests relevant to this file can be found (at the time of writing) in //! src/tests/ui/pattern/usefulness. </del> <ins> //! Note: tests specific to this file can be found in: //!     - ui/pattern/usefulness //!     - ui/or-patterns //!     - ui/consts/const_in_pattern //!     - ui/rfc-2008-non-exhaustive //!     - probably many others //! I (Nadrieril) prefer to put new tests in `ui/pattern/usefulness` unless there's a specific //! reason not to, for example if they depend on a particular feature like or_patterns. </ins> //! //! This file includes the logic for exhaustiveness and usefulness checking for //! pattern-matching. Specifically, given a list of patterns for a type, we can


Question:
The match remains exhaustive with highlighted pattern removed, but it does not produce any warnings: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I know where the problem comes from: this bit of code tries to handle unreachable sub-or-patterns diagnostics, but it's a bit of a hack. What remains is to come up with a better solution. claim

#[derive(Clone, Debug)] crate enum Usefulness<'tcx> { <del> /// Carries a list of unreachable subpatterns. Used only in the presence of or-patterns. Useful(Vec<Span>), </del> <ins> /// Carries, for each column in the matrix, a set of sub-branches that have been found to be /// unreachable. Used only in the presence of or-patterns, otherwise it stays empty. Useful(Vec<FxHashSet<Span>>), </ins> /// Carries a list of witnesses of non-exhaustiveness. UsefulWithWitness(Vec<Witness<'tcx>>), NotUseful,


Question:
The match remains exhaustive with highlighted pattern removed, but it does not produce any warnings: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I know where the problem comes from: this bit of code tries to handle unreachable sub-or-patterns diagnostics, but it's a bit of a hack. What remains is to come up with a better solution. claim

}; UsefulWithWitness(new_witnesses) } <ins> Useful(mut unreachables) => { if !unreachables.is_empty() { // When we apply a constructor, there are `arity` columns of the matrix that // corresponded to its arguments. All the unreachables found in these columns // will, after `apply`, come from the first column. So we take the union of all // the corresponding sets and put them in the first column. // Note that `arity` may be 0, in which case we just push a new empty set. let len = unreachables.len(); let arity = ctor_wild_subpatterns.len(); let mut unioned = FxHashSet::default(); for set in unreachables.drain((len - arity)..) { unioned.extend(set) } unreachables.push(unioned); } Useful(unreachables) } </ins> x => x, } }


Question:
The match remains exhaustive with highlighted pattern removed, but it does not produce any warnings: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I know where the problem comes from: this bit of code tries to handle unreachable sub-or-patterns diagnostics, but it's a bit of a hack. What remains is to come up with a better solution. claim

// If the first pattern is an or-pattern, expand it. if let Some(vs) = v.expand_or_pat() { <del> // We need to push the already-seen patterns into the matrix in order to detect redundant // branches like `Some(_) | Some(0)`. We also keep track of the unreachable subpatterns. let mut matrix = matrix.clone(); // `Vec` of all the unreachable branches of the current or-pattern. let mut unreachable_branches = Vec::new(); // Subpatterns that are unreachable from all branches. E.g. in the following case, the last // `true` is unreachable only from one branch, so it is overall reachable. </del> <ins> // We expand the or pattern, trying each of its branches in turn and keeping careful track // of possible unreachable sub-branches. // // If two branches have detected some unreachable sub-branches, we need to be careful. If // they were detected in columns that are not the current one, we want to keep only the // sub-branches that were unreachable in _all_ branches. Eg. in the following, the last // `true` is unreachable in the second branch of the first or-pattern, but not otherwise. // Therefore we don't want to lint that it is unreachable. </ins> // // ``` // match (true, true) {