jiebi/CodeConvo huggingface dataset:
Code change:
The following code sometimes causes a data race to be reported by Miri: Miri reports: The deallocation occurs when returns and its local variable gets deallocated. The read occurs here (I am fairly sure): This reads the contents of the field after the . But the moment the is done, the memory backing might be deallocated. That makes the read a potential use-after-free, and a race with the deallocation. Cc
The following patch fixes this: However, even with this patch, we still run into a problem like the gets deallocated while still runs. This is still UB even after my proposed because contains a field that is not inside an (the field). So that part of what points to is expected to stay live for the entire duration of the function call. Another alternative might be to put the entire into an rather than allocating it on the stack frame of .
Going to attach this to the 1.63 milestone, since this is in a newly stabilized feature -- we may wish to back out stabilization for a cycle or backport fixes.
Re-opening for beta backport.
The fix was backported in .

Related discussion:
text: rtabort!("thread result panicked on drop"); } // Book-keeping so the scope knows when it's done. <del> if let Some(scope) = self.scope { </del> <ins> if let Some(scope) = &self.scope { </ins> // Now that there will be no more user code running on this thread // that can use 'scope, mark the thread as 'finished'. // It's important we only do this after the `result` has been dropped,
Code change:
The following code sometimes causes a data race to be reported by Miri: Miri reports: The deallocation occurs when returns and its local variable gets deallocated. The read occurs here (I am fairly sure): This reads the contents of the field after the . But the moment the is done, the memory backing might be deallocated. That makes the read a potential use-after-free, and a race with the deallocation. Cc
The following patch fixes this: However, even with this patch, we still run into a problem like the gets deallocated while still runs. This is still UB even after my proposed because contains a field that is not inside an (the field). So that part of what points to is expected to stay live for the entire duration of the function call. Another alternative might be to put the entire into an rather than allocating it on the stack frame of .
Going to attach this to the 1.63 milestone, since this is in a newly stabilized feature -- we may wish to back out stabilization for a cycle or backport fixes.
Re-opening for beta backport.
The fix was backported in .

Related discussion:
text: /// See [`scope`] for details. #[stable(feature = "scoped_threads", since = "1.63.0")] pub struct Scope<'scope, 'env: 'scope> { <del> data: ScopeData, </del> <ins> data: Arc<ScopeData>, </ins> /// Invariance over 'scope, to make sure 'scope cannot shrink, /// which is necessary for soundness. ///
Code change:
The following code sometimes causes a data race to be reported by Miri: Miri reports: The deallocation occurs when returns and its local variable gets deallocated. The read occurs here (I am fairly sure): This reads the contents of the field after the . But the moment the is done, the memory backing might be deallocated. That makes the read a potential use-after-free, and a race with the deallocation. Cc
The following patch fixes this: However, even with this patch, we still run into a problem like the gets deallocated while still runs. This is still UB even after my proposed because contains a field that is not inside an (the field). So that part of what points to is expected to stay live for the entire duration of the function call. Another alternative might be to put the entire into an rather than allocating it on the stack frame of .
Going to attach this to the 1.63 milestone, since this is in a newly stabilized feature -- we may wish to back out stabilization for a cycle or backport fixes.
Re-opening for beta backport.
The fix was backported in .

Related discussion:
text: where F: for<'scope> FnOnce(&'scope Scope<'scope, 'env>) -> T, { <ins> // We put the `ScopeData` into an `Arc` so that other threads can finish their // `decrement_num_running_threads` even after this function returns. </ins> let scope = Scope { <del> data: ScopeData { </del> <ins> data: Arc::new(ScopeData { </ins> num_running_threads: AtomicUsize::new(0), main_thread: current(), a_thread_panicked: AtomicBool::new(false), <del> }, </del> <ins> }), </ins> env: PhantomData, scope: PhantomData, };
Code change:
The following code sometimes causes a data race to be reported by Miri: Miri reports: The deallocation occurs when returns and its local variable gets deallocated. The read occurs here (I am fairly sure): This reads the contents of the field after the . But the moment the is done, the memory backing might be deallocated. That makes the read a potential use-after-free, and a race with the deallocation. Cc
The following patch fixes this: However, even with this patch, we still run into a problem like the gets deallocated while still runs. This is still UB even after my proposed because contains a field that is not inside an (the field). So that part of what points to is expected to stay live for the entire duration of the function call. Another alternative might be to put the entire into an rather than allocating it on the stack frame of .
Going to attach this to the 1.63 milestone, since this is in a newly stabilized feature -- we may wish to back out stabilization for a cycle or backport fixes.
Re-opening for beta backport.
The fix was backported in .

Related discussion:
text: F: FnOnce() -> T + Send + 'scope, T: Send + 'scope, { <del> Ok(ScopedJoinHandle(unsafe { self.spawn_unchecked_(f, Some(&scope.data)) }?)) </del> <ins> Ok(ScopedJoinHandle(unsafe { self.spawn_unchecked_(f, Some(scope.data.clone())) }?)) </ins> } }
Code change:
This bug has already been identified but I wanted to open an issue for it. The following code should print first. () I believe there is an unanswered question: Should temporaries be dropped before the block? said this issue is being investigated at <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assign (I'm pretty sure you are working on this at )
I think they should, since this would be consistent with if/else. ()
Originally reported in: There are also some variations of it: I've made a little test case for it that doesn't rely on printf but instead can be ran as a run-pass test:
I believe the two tests in shall be comparing to . The reason is that actually extends the temporary to the end of the block at the moment, which is the desired outcome. cc
good point. What's important is that both the let-else and let-else free version are doing the same thing. Maybe one can add an additional block around the and then add a second to ensure it dropped after the block terminated? Edit: nvm, it's not possible as the .stdout files are for compiler output, not runtime output of the tests.
<details<summaryHere's another way to test, using Rc</summary</details
It might also be an idea to add a test for the inconsistency between if and if let: (no matter which side of the divide let else is on, make sure that there is no breakage of it in the future)
The above test for "drop before else block" failed on master. Reopening.
Allow me to notify that I am currently looking at how to drop values earlier inside the block.
So I was rebasing onto latest master and I wanted to share this as part of the diff: ! There has been great improvement by but it was no full fix, especially this still post-drops: prints: If you remove the it works now thanks to .
I think this is because the borrowed is assigned with extended lifetime. only breaks out towards the remainder scope. It turns out this is not sufficient. I will try to break out to further one scope up, say the parent remainder scope of the current one. I feel that this should suffice.
This is correct behavior I think. Anything accessible in the pattern needs to be in scope till the end of the block. Consider you can write . It shouldn't depend on whether the pattern matches since that is not known at compile time generally.
yeah it may not be dropped before the code after the construct terminates, but it can be dropped before the block.
I see. I think this is the non-temporary case, when the pattern doesn't match.

Related discussion:
text: initializer_span, else_block, visibility_scope, <ins> *remainder_scope, </ins> remainder_span, pattern, )
Code change:
This bug has already been identified but I wanted to open an issue for it. The following code should print first. () I believe there is an unanswered question: Should temporaries be dropped before the block? said this issue is being investigated at <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assign (I'm pretty sure you are working on this at )
I think they should, since this would be consistent with if/else. ()
Originally reported in: There are also some variations of it: I've made a little test case for it that doesn't rely on printf but instead can be ran as a run-pass test:
I believe the two tests in shall be comparing to . The reason is that actually extends the temporary to the end of the block at the moment, which is the desired outcome. cc
good point. What's important is that both the let-else and let-else free version are doing the same thing. Maybe one can add an additional block around the and then add a second to ensure it dropped after the block terminated? Edit: nvm, it's not possible as the .stdout files are for compiler output, not runtime output of the tests.
<details<summaryHere's another way to test, using Rc</summary</details
It might also be an idea to add a test for the inconsistency between if and if let: (no matter which side of the divide let else is on, make sure that there is no breakage of it in the future)
The above test for "drop before else block" failed on master. Reopening.
Allow me to notify that I am currently looking at how to drop values earlier inside the block.
So I was rebasing onto latest master and I wanted to share this as part of the diff: ! There has been great improvement by but it was no full fix, especially this still post-drops: prints: If you remove the it works now thanks to .
I think this is because the borrowed is assigned with extended lifetime. only breaks out towards the remainder scope. It turns out this is not sufficient. I will try to break out to further one scope up, say the parent remainder scope of the current one. I feel that this should suffice.
This is correct behavior I think. Anything accessible in the pattern needs to be in scope till the end of the block. Consider you can write . It shouldn't depend on whether the pattern matches since that is not known at compile time generally.
yeah it may not be dropped before the code after the construct terminates, but it can be dropped before the block.
I see. I think this is the non-temporary case, when the pattern doesn't match.

Related discussion:
text: } drops.add_entry(block, drop_idx); <del> // `build_drop_tree` doesn't have access to our source_info, so we </del> <ins> // `build_drop_trees` doesn't have access to our source_info, so we </ins> // create a dummy terminator now. `TerminatorKind::Resume` is used // because MIR type checking will panic if it hasn't been overwritten. self.cfg.terminate(block, source_info, TerminatorKind::Resume);
Code change:
This bug has already been identified but I wanted to open an issue for it. The following code should print first. () I believe there is an unanswered question: Should temporaries be dropped before the block? said this issue is being investigated at <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assign (I'm pretty sure you are working on this at )
I think they should, since this would be consistent with if/else. ()
Originally reported in: There are also some variations of it: I've made a little test case for it that doesn't rely on printf but instead can be ran as a run-pass test:
I believe the two tests in shall be comparing to . The reason is that actually extends the temporary to the end of the block at the moment, which is the desired outcome. cc
good point. What's important is that both the let-else and let-else free version are doing the same thing. Maybe one can add an additional block around the and then add a second to ensure it dropped after the block terminated? Edit: nvm, it's not possible as the .stdout files are for compiler output, not runtime output of the tests.
<details<summaryHere's another way to test, using Rc</summary</details
It might also be an idea to add a test for the inconsistency between if and if let: (no matter which side of the divide let else is on, make sure that there is no breakage of it in the future)
The above test for "drop before else block" failed on master. Reopening.
Allow me to notify that I am currently looking at how to drop values earlier inside the block.
So I was rebasing onto latest master and I wanted to share this as part of the diff: ! There has been great improvement by but it was no full fix, especially this still post-drops: prints: If you remove the it works now thanks to .
I think this is because the borrowed is assigned with extended lifetime. only breaks out towards the remainder scope. It turns out this is not sufficient. I will try to break out to further one scope up, say the parent remainder scope of the current one. I feel that this should suffice.
This is correct behavior I think. Anything accessible in the pattern needs to be in scope till the end of the block. Consider you can write . It shouldn't depend on whether the pattern matches since that is not known at compile time generally.
yeah it may not be dropped before the code after the construct terminates, but it can be dropped before the block.
I see. I think this is the non-temporary case, when the pattern doesn't match.

Related discussion:
text: // run-pass #![feature(let_else)] <ins> use std::fmt::Display; use std::rc::Rc; </ins> use std::sync::atomic::{AtomicU8, Ordering}; static TRACKER: AtomicU8 = AtomicU8::new(0);
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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --There are two crates here, and (which depends on ). library: consumer: The current output is (when running on ): <!-- The following is not always necessary. --Ideally the output should look like: We should not be suggesting private types to users, since macro hygiene does mean they can't write This is on the latest nightly, This was ran into in
this only happens with items and not ?
I included examples of and , and it seems to happen for both (see: )
Oh, my bad. I didn't read closely, my eyes just went directly to the macro item. Sorry. :sweat_smile:
For the record, this is not a macro problem. See that does not use macros: /// fn needsmeow<T: playground::Meow(t: T) {} /// fn main() { needsmeow(1usize); } /// (uses a doc comment to emulate two crates on playground) The reason is that  does not do any filtering for type privacy.

Related discussion:
text: if !self.report_similar_impl_candidates( impl_candidates, trait_ref, <ins> obligation.cause.body_id, </ins> &mut err, ) { // This is *almost* equivalent to
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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --There are two crates here, and (which depends on ). library: consumer: The current output is (when running on ): <!-- The following is not always necessary. --Ideally the output should look like: We should not be suggesting private types to users, since macro hygiene does mean they can't write This is on the latest nightly, This was ran into in
this only happens with items and not ?
I included examples of and , and it seems to happen for both (see: )
Oh, my bad. I didn't read closely, my eyes just went directly to the macro item. Sorry. :sweat_smile:
For the record, this is not a macro problem. See that does not use macros: /// fn needsmeow<T: playground::Meow(t: T) {} /// fn main() { needsmeow(1usize); } /// (uses a doc comment to emulate two crates on playground) The reason is that  does not do any filtering for type privacy.

Related discussion:
text: self.report_similar_impl_candidates( impl_candidates, trait_ref, <ins> obligation.cause.body_id, </ins> &mut err, ); }
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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --There are two crates here, and (which depends on ). library: consumer: The current output is (when running on ): <!-- The following is not always necessary. --Ideally the output should look like: We should not be suggesting private types to users, since macro hygiene does mean they can't write This is on the latest nightly, This was ran into in
this only happens with items and not ?
I included examples of and , and it seems to happen for both (see: )
Oh, my bad. I didn't read closely, my eyes just went directly to the macro item. Sorry. :sweat_smile:
For the record, this is not a macro problem. See that does not use macros: /// fn needsmeow<T: playground::Meow(t: T) {} /// fn main() { needsmeow(1usize); } /// (uses a doc comment to emulate two crates on playground) The reason is that  does not do any filtering for type privacy.

Related discussion:
text: &self, impl_candidates: Vec<ImplCandidate<'tcx>>, trait_ref: ty::PolyTraitRef<'tcx>, <ins> body_id: hir::HirId, </ins> err: &mut Diagnostic, ) -> bool;
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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --There are two crates here, and (which depends on ). library: consumer: The current output is (when running on ): <!-- The following is not always necessary. --Ideally the output should look like: We should not be suggesting private types to users, since macro hygiene does mean they can't write This is on the latest nightly, This was ran into in
this only happens with items and not ?
I included examples of and , and it seems to happen for both (see: )
Oh, my bad. I didn't read closely, my eyes just went directly to the macro item. Sorry. :sweat_smile:
For the record, this is not a macro problem. See that does not use macros: /// fn needsmeow<T: playground::Meow(t: T) {} /// fn main() { needsmeow(1usize); } /// (uses a doc comment to emulate two crates on playground) The reason is that  does not do any filtering for type privacy.

Related discussion:
text: &self, impl_candidates: Vec<ImplCandidate<'tcx>>, trait_ref: ty::PolyTraitRef<'tcx>, <ins> body_id: hir::HirId, </ins> err: &mut Diagnostic, ) -> bool { let report = |mut candidates: Vec<TraitRef<'tcx>>, err: &mut Diagnostic| {
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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --There are two crates here, and (which depends on ). library: consumer: The current output is (when running on ): <!-- The following is not always necessary. --Ideally the output should look like: We should not be suggesting private types to users, since macro hygiene does mean they can't write This is on the latest nightly, This was ran into in
this only happens with items and not ?
I included examples of and , and it seems to happen for both (see: )
Oh, my bad. I didn't read closely, my eyes just went directly to the macro item. Sorry. :sweat_smile:
For the record, this is not a macro problem. See that does not use macros: /// fn needsmeow<T: playground::Meow(t: T) {} /// fn main() { needsmeow(1usize); } /// (uses a doc comment to emulate two crates on playground) The reason is that  does not do any filtering for type privacy.

Related discussion:
text: || self.tcx.is_builtin_derive(def_id) }) .filter_map(|def_id| self.tcx.impl_trait_ref(def_id)) <del> // Avoid mentioning type parameters. .filter(|trait_ref| !matches!(trait_ref.self_ty().kind(), ty::Param(_))) </del> <ins> .filter(|trait_ref| { let self_ty = trait_ref.self_ty(); // Avoid mentioning type parameters. if let ty::Param(_) = self_ty.kind() { false } // Avoid mentioning types that are private to another crate else if let ty::Adt(def, _) = self_ty.peel_refs().kind() { // FIXME(compiler-errors): This could be generalized, both to // be more granular, and probably look past other `#[fundamental]` // types, too. self.tcx .visibility(def.did()) .is_accessible_from(body_id.owner.to_def_id(), self.tcx) } else { true } }) </ins> .collect(); return report(normalized_impl_candidates, err); }
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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --There are two crates here, and (which depends on ). library: consumer: The current output is (when running on ): <!-- The following is not always necessary. --Ideally the output should look like: We should not be suggesting private types to users, since macro hygiene does mean they can't write This is on the latest nightly, This was ran into in
this only happens with items and not ?
I included examples of and , and it seems to happen for both (see: )
Oh, my bad. I didn't read closely, my eyes just went directly to the macro item. Sorry. :sweat_smile:
For the record, this is not a macro problem. See that does not use macros: /// fn needsmeow<T: playground::Meow(t: T) {} /// fn main() { needsmeow(1usize); } /// (uses a doc comment to emulate two crates on playground) The reason is that  does not do any filtering for type privacy.

Related discussion:
text: <ins> pub trait Meow { fn meow(&self) {} } pub struct GlobalMeow; impl Meow for GlobalMeow {} pub(crate) struct PrivateMeow; impl Meow for PrivateMeow {} </ins>