jiebi/CodeConvo huggingface dataset:
Code change:
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 :

Related discussion:
text: use crate::{ cell::{Cell, UnsafeCell}, fmt, <ins> marker::PhantomData, </ins> mem::{self, MaybeUninit}, ops::{Deref, Drop}, panic::{RefUnwindSafe, UnwindSafe},
Code change:
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 :

Related discussion:
text: 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`?
Code change:
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 :

Related discussion:
text: /// 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.
Code change:
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

Related discussion:
text: 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> } }
Code change:
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

Related discussion:
text: } } <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);
Code change:
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

Related discussion:
text: 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.
Code change:
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

Related discussion:
text: } _ => { 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)) } }
Code change:
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

Related discussion:
text: } 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.
Code change:
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.

Related discussion:
text: _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
Code change:
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

Related discussion:
text: <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
Code change:
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

Related discussion:
text: #[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,
Code change:
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

Related discussion:
text: }; 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, } }
Code change:
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

Related discussion:
text: // 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) {
Code change:
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

Related discussion:
text: hir::MatchSource::AwaitDesugar | hir::MatchSource::TryDesugar => {} } } <del> Useful(unreachable_subpatterns) => { for span in unreachable_subpatterns { </del> <ins> Useful(unreachables) => { let mut unreachables: Vec<_> = unreachables.into_iter().flatten().collect(); // Emit lints in the order in which they occur in the file. unreachables.sort_unstable(); for span in unreachables { </ins> unreachable_pattern(cx.tcx, span, id, None); } }
Code change:
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

Related discussion:
text: (false | true, false | true) => {} } match (true, true) { <del> (true, false) => {} (false, true) => {} </del> <ins> (true, true) => {} (false, false) => {} </ins> (false | true, false | true) => {} } <ins> // https://github.com/rust-lang/rust/issues/76836 match None { Some(false) => {} None | Some(true | false) => {} //~ ERROR unreachable } </ins> // A subpattern that is unreachable in all branches is overall unreachable. match (true, true) { (false, true) => {}
Code change:
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

Related discussion:
text: |              ^ error: unreachable pattern <del> --> $DIR/exhaustiveness-unreachable-pattern.rs:89:15 </del> <ins> --> $DIR/exhaustiveness-unreachable-pattern.rs:88:19 | LL |                 | false) => {} |                   ^^^^^ error: unreachable pattern --> $DIR/exhaustiveness-unreachable-pattern.rs:96:15 </ins> | LL |             | true) => {} |               ^^^^ error: unreachable pattern <del> --> $DIR/exhaustiveness-unreachable-pattern.rs:95:15 </del> <ins> --> $DIR/exhaustiveness-unreachable-pattern.rs:102:15 </ins> | LL |             | true, |               ^^^^ <del> error: aborting due to 18 previous errors </del> <ins> error: aborting due to 19 previous errors </ins>
Code change:
Seaching for in the docs only surfaces . The solution seems to link from to so people can read more. However I'm not sure how to create a link between these since they live in separate crates. What's the right way to go about this? edit: if someone wants to pick this up, please do. This is probably a "good first issue" once we figure out how to link between the two. ! -- this is how I eventually learned about ; ideally it'd be easier to find. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
These can't use intra-doc links, so you need to use relative links. I think would work.
Mentoring instructions: At add a link to .
Could I take this on as my first issue?
please do!
Feel free to use the command to assign the issue to yourself and show you're working on it
claim
yay; thanks for landing this

Related discussion:
text: } /// Attribute macro applied to a static to register it as a global allocator. <ins> /// /// See also [`std::alloc::GlobalAlloc`](../std/alloc/trait.GlobalAlloc.html). </ins> #[stable(feature = "global_allocator", since = "1.28.0")] #[allow_internal_unstable(rustc_attrs)] #[rustc_builtin_macro]
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: Compiler doesn't generate any warnings Instead, this happened: Rustc says that is unused, even though it is declared as in asm. Adding arrows () fixes it <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Interesting bug! I used to determine that this bug has been around . and doing some debugging, I found that for all live nodes in , is never marked as being used in the RWU table. It only gets marked as read/written. , this is part of the information used to determine that is unused. That doesn't really make much sense though- does seem to fit the case where a variable is used as both an input and an output to some arbitrary assembly instruction. I'll go ahead and claim this. I have a solution in mind, just going to ask around zulip first before putting out a PR. claim

Related discussion:
text: } } hir::InlineAsmOperand::InOut { expr, .. } => { <del> succ = self.write_place(expr, succ, ACC_READ | ACC_WRITE); </del> <ins> succ = self.write_place(expr, succ, ACC_READ | ACC_WRITE | ACC_USE); </ins> } hir::InlineAsmOperand::SplitInOut { out_expr, .. } => { if let Some(expr) = out_expr {