jiebi/CodeConvo huggingface dataset:
Code change:
I believe the intention in let-else is that this code should be considered syntactically invalid, but it compiles successfully today. If you replace with , it correctly fails to parse.
I believe here is the missing case for ExprKind::ConstBlock: This should be changed to an exhaustive match so that future new ExprKind variants are forced to touch this code. Some other unhandled cases that can end in : ExprKind::Become ExprKind::FormatArgs ExprKind::IncludedBytes ExprKind::InlineAsm ExprKind::MacCall ExprKind::OffsetOf ExprKind::Yeet

Related discussion:
text: | Range(_, Some(e), _) | Ret(Some(e)) | Unary(_, e) <del> | Yield(Some(e)) => { </del> <ins> | Yield(Some(e)) | Yeet(Some(e)) | Become(e) => { </ins> expr = e; } Closure(closure) => { expr = &closure.body; } Gen(..) | Block(..) | ForLoop(..) | If(..) | Loop(..) | Match(..) | Struct(..) <del> | TryBlock(..) | While(..) => break Some(expr), _ => break None, </del> <ins> | TryBlock(..) | While(..) | ConstBlock(_) => break Some(expr), // FIXME: These can end in `}`, but changing these would break stable code. InlineAsm(_) | OffsetOf(_, _) | MacCall(_) | IncludedBytes(_) | FormatArgs(_) => { break None; } Break(_, None) | Range(_, None, _) | Ret(None) | Yield(None) | Array(_) | Call(_, _) | MethodCall(_) | Tup(_) | Lit(_) | Cast(_, _) | Type(_, _) | Await(_, _) | Field(_, _) | Index(_, _, _) | Underscore | Path(_, _) | Continue(_) | Repeat(_, _) | Paren(_) | Try(_) | Yeet(None) | Err => break None, </ins> } } }
Code change:
I believe the intention in let-else is that this code should be considered syntactically invalid, but it compiles successfully today. If you replace with , it correctly fails to parse.
I believe here is the missing case for ExprKind::ConstBlock: This should be changed to an exhaustive match so that future new ExprKind variants are forced to touch this code. Some other unhandled cases that can end in : ExprKind::Become ExprKind::FormatArgs ExprKind::IncludedBytes ExprKind::InlineAsm ExprKind::MacCall ExprKind::OffsetOf ExprKind::Yeet

Related discussion:
text: <ins> #![feature(inline_const)] #![feature(yeet_expr)] #![allow(incomplete_features)] // Necessary for now, while explicit_tail_calls is incomplete #![feature(explicit_tail_calls)] fn a() { let foo = { 1 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn b() { let foo = for i in 1..2 { break; } else { //~^ ERROR `for...else` loops are not supported return; }; } fn c() { let foo = if true { 1 } else { 0 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn d() { let foo = loop { break; } else { //~^ ERROR loop...else` loops are not supported return; }; } fn e() { let foo = match true { true => 1, false => 0 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } struct X {a: i32} fn f() { let foo = X { a: 1 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn g() { let foo = while false { break; } else { //~^ ERROR `while...else` loops are not supported return; }; } fn h() { let foo = const { 1 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn i() { let foo = &{ 1 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn j() { let bar = 0; let foo = bar = { 1 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn k() { let foo = 1 + { 1 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn l() { let foo = 1..{ 1 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn m() { let foo = return { () } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn n() { let foo = -{ 1 } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn o() -> Result<(), ()> { let foo = do yeet { () } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return Ok(()); }; } fn p() { let foo = become { () } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn q() { let foo = |x: i32| { x } else { //~^ ERROR right curly brace `}` before `else` in a `let...else` statement not allowed return; }; } fn main() {} </ins>
Code change:
and currently store pointers as , which is not ideal: They should really work with pointers and strict provenance APIs like , , etc. See a PR fixing a similar issue for some context: (note: in that one I ended up rewriting the whole thing, I think this issue requires far less changes). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(I do plan to work on this, but if you want to work on this instead — feel free to , I can mentor you) <subcc
claim
Could you briefly describe and , also a comprehensive insight about this issue would greatly help, although I had a look at which currently is an . If I understand correctly, we are building a for this and aim to improve existing implementations as seen in languages like C++ by making it more strict, and there is some discussion that can basically do most of what C++ can and this addition might have some diverging path. Let me know, so I can move forward!
claim
Hi strict provenance means that we aren't doing pointer-int conversions and only operate through pointer types like suggested by OP. and currently use which doesn't work under strict provenance. If you'd like I can work on this issue.
Did you mean to mentor me for the same? I would be happy to learn!
is already working on this issue, is this right? Let's not override other people working on it already unless they agree or it's been several weeks with no response.
Hi yes I am working on this issue. This is my first time contributing so it will take me sometime. I will reassign the issue to me.
claim
Hi Just checking in :) Are you still working on this issue?
Yup I am still working on this issue :)
Let us know on Zulip if you need any help
with this resolved, I think rustc is free from "fuzzy provenance casts" :)
Awesome :-)

Related discussion:
text: use std::mem; use std::num::NonZeroUsize; use std::ops::{ControlFlow, Deref}; <ins> use std::ptr::NonNull; </ins> /// An entity in the Rust type system, which can be one of /// several kinds (types, lifetimes, and consts).
Code change:
and currently store pointers as , which is not ideal: They should really work with pointers and strict provenance APIs like , , etc. See a PR fixing a similar issue for some context: (note: in that one I ended up rewriting the whole thing, I think this issue requires far less changes). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(I do plan to work on this, but if you want to work on this instead — feel free to , I can mentor you) <subcc
claim
Could you briefly describe and , also a comprehensive insight about this issue would greatly help, although I had a look at which currently is an . If I understand correctly, we are building a for this and aim to improve existing implementations as seen in languages like C++ by making it more strict, and there is some discussion that can basically do most of what C++ can and this addition might have some diverging path. Let me know, so I can move forward!
claim
Hi strict provenance means that we aren't doing pointer-int conversions and only operate through pointer types like suggested by OP. and currently use which doesn't work under strict provenance. If you'd like I can work on this issue.
Did you mean to mentor me for the same? I would be happy to learn!
is already working on this issue, is this right? Let's not override other people working on it already unless they agree or it's been several weeks with no response.
Hi yes I am working on this issue. This is my first time contributing so it will take me sometime. I will reassign the issue to me.
claim
Hi Just checking in :) Are you still working on this issue?
Yup I am still working on this issue :)
Let us know on Zulip if you need any help
with this resolved, I think rustc is free from "fuzzy provenance casts" :)
Awesome :-)

Related discussion:
text: /// `Region` and `Const` are all interned. #[derive(Copy, Clone, PartialEq, Eq, Hash)] pub struct GenericArg<'tcx> { <del> ptr: NonZeroUsize, </del> <ins> ptr: NonNull<()>, </ins> marker: PhantomData<(Ty<'tcx>, ty::Region<'tcx>, ty::Const<'tcx>)>, } <ins> #[cfg(parallel_compiler)] unsafe impl<'tcx> rustc_data_structures::sync::DynSend for GenericArg<'tcx> where &'tcx (Ty<'tcx>, ty::Region<'tcx>, ty::Const<'tcx>): rustc_data_structures::sync::DynSend { } #[cfg(parallel_compiler)] unsafe impl<'tcx> rustc_data_structures::sync::DynSync for GenericArg<'tcx> where &'tcx (Ty<'tcx>, ty::Region<'tcx>, ty::Const<'tcx>): rustc_data_structures::sync::DynSync { } unsafe impl<'tcx> Send for GenericArg<'tcx> where &'tcx (Ty<'tcx>, ty::Region<'tcx>, ty::Const<'tcx>): Send { } unsafe impl<'tcx> Sync for GenericArg<'tcx> where &'tcx (Ty<'tcx>, ty::Region<'tcx>, ty::Const<'tcx>): Sync { } </ins> impl<'tcx> IntoDiagnosticArg for GenericArg<'tcx> { fn into_diagnostic_arg(self) -> DiagnosticArgValue<'static> { self.to_string().into_diagnostic_arg()
Code change:
and currently store pointers as , which is not ideal: They should really work with pointers and strict provenance APIs like , , etc. See a PR fixing a similar issue for some context: (note: in that one I ended up rewriting the whole thing, I think this issue requires far less changes). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(I do plan to work on this, but if you want to work on this instead — feel free to , I can mentor you) <subcc
claim
Could you briefly describe and , also a comprehensive insight about this issue would greatly help, although I had a look at which currently is an . If I understand correctly, we are building a for this and aim to improve existing implementations as seen in languages like C++ by making it more strict, and there is some discussion that can basically do most of what C++ can and this addition might have some diverging path. Let me know, so I can move forward!
claim
Hi strict provenance means that we aren't doing pointer-int conversions and only operate through pointer types like suggested by OP. and currently use which doesn't work under strict provenance. If you'd like I can work on this issue.
Did you mean to mentor me for the same? I would be happy to learn!
is already working on this issue, is this right? Let's not override other people working on it already unless they agree or it's been several weeks with no response.
Hi yes I am working on this issue. This is my first time contributing so it will take me sometime. I will reassign the issue to me.
claim
Hi Just checking in :) Are you still working on this issue?
Yup I am still working on this issue :)
Let us know on Zulip if you need any help
with this resolved, I think rustc is free from "fuzzy provenance casts" :)
Awesome :-)

Related discussion:
text: GenericArgKind::Lifetime(lt) => { // Ensure we can use the tag bits. assert_eq!(mem::align_of_val(&*lt.0.0) & TAG_MASK, 0); <del> (REGION_TAG, lt.0.0 as *const ty::RegionKind<'tcx> as usize) </del> <ins> (REGION_TAG, NonNull::from(lt.0.0).cast()) </ins> } GenericArgKind::Type(ty) => { // Ensure we can use the tag bits. assert_eq!(mem::align_of_val(&*ty.0.0) & TAG_MASK, 0); <del> (TYPE_TAG, ty.0.0 as *const WithCachedTypeInfo<ty::TyKind<'tcx>> as usize) </del> <ins> (TYPE_TAG, NonNull::from(ty.0.0).cast()) </ins> } GenericArgKind::Const(ct) => { // Ensure we can use the tag bits. assert_eq!(mem::align_of_val(&*ct.0.0) & TAG_MASK, 0); <del> (CONST_TAG, ct.0.0 as *const WithCachedTypeInfo<ty::ConstData<'tcx>> as usize) </del> <ins> (CONST_TAG, NonNull::from(ct.0.0).cast()) </ins> } }; <del> GenericArg { ptr: unsafe { NonZeroUsize::new_unchecked(ptr | tag) }, marker: PhantomData } </del> <ins> GenericArg { ptr: ptr.map_addr(|addr| addr | tag), marker: PhantomData } </ins> } }
Code change:
and currently store pointers as , which is not ideal: They should really work with pointers and strict provenance APIs like , , etc. See a PR fixing a similar issue for some context: (note: in that one I ended up rewriting the whole thing, I think this issue requires far less changes). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(I do plan to work on this, but if you want to work on this instead — feel free to , I can mentor you) <subcc
claim
Could you briefly describe and , also a comprehensive insight about this issue would greatly help, although I had a look at which currently is an . If I understand correctly, we are building a for this and aim to improve existing implementations as seen in languages like C++ by making it more strict, and there is some discussion that can basically do most of what C++ can and this addition might have some diverging path. Let me know, so I can move forward!
claim
Hi strict provenance means that we aren't doing pointer-int conversions and only operate through pointer types like suggested by OP. and currently use which doesn't work under strict provenance. If you'd like I can work on this issue.
Did you mean to mentor me for the same? I would be happy to learn!
is already working on this issue, is this right? Let's not override other people working on it already unless they agree or it's been several weeks with no response.
Hi yes I am working on this issue. This is my first time contributing so it will take me sometime. I will reassign the issue to me.
claim
Hi Just checking in :) Are you still working on this issue?
Yup I am still working on this issue :)
Let us know on Zulip if you need any help
with this resolved, I think rustc is free from "fuzzy provenance casts" :)
Awesome :-)

Related discussion:
text: impl<'tcx> GenericArg<'tcx> { #[inline] pub fn unpack(self) -> GenericArgKind<'tcx> { <del> let ptr = self.ptr.get(); </del> <ins> let ptr = unsafe { self.ptr.map_addr(|addr| NonZeroUsize::new_unchecked(addr.get() & !TAG_MASK)) }; </ins> // SAFETY: use of `Interned::new_unchecked` here is ok because these // pointers were originally created from `Interned` types in `pack()`, // and this is just going in the other direction. unsafe { <del> match ptr & TAG_MASK { </del> <ins> match self.ptr.addr().get() & TAG_MASK { </ins> REGION_TAG => GenericArgKind::Lifetime(ty::Region(Interned::new_unchecked( <del> &*((ptr & !TAG_MASK) as *const ty::RegionKind<'tcx>), </del> <ins> ptr.cast::<ty::RegionKind<'tcx>>().as_ref(), </ins> ))), TYPE_TAG => GenericArgKind::Type(Ty(Interned::new_unchecked( <del> &*((ptr & !TAG_MASK) as *const WithCachedTypeInfo<ty::TyKind<'tcx>>), </del> <ins> ptr.cast::<WithCachedTypeInfo<ty::TyKind<'tcx>>>().as_ref(), </ins> ))), CONST_TAG => GenericArgKind::Const(ty::Const(Interned::new_unchecked( <del> &*((ptr & !TAG_MASK) as *const WithCachedTypeInfo<ty::ConstData<'tcx>>), </del> <ins> ptr.cast::<WithCachedTypeInfo<ty::ConstData<'tcx>>>().as_ref(), </ins> ))), _ => intrinsics::unreachable(), }
Code change:
and currently store pointers as , which is not ideal: They should really work with pointers and strict provenance APIs like , , etc. See a PR fixing a similar issue for some context: (note: in that one I ended up rewriting the whole thing, I think this issue requires far less changes). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(I do plan to work on this, but if you want to work on this instead — feel free to , I can mentor you) <subcc
claim
Could you briefly describe and , also a comprehensive insight about this issue would greatly help, although I had a look at which currently is an . If I understand correctly, we are building a for this and aim to improve existing implementations as seen in languages like C++ by making it more strict, and there is some discussion that can basically do most of what C++ can and this addition might have some diverging path. Let me know, so I can move forward!
claim
Hi strict provenance means that we aren't doing pointer-int conversions and only operate through pointer types like suggested by OP. and currently use which doesn't work under strict provenance. If you'd like I can work on this issue.
Did you mean to mentor me for the same? I would be happy to learn!
is already working on this issue, is this right? Let's not override other people working on it already unless they agree or it's been several weeks with no response.
Hi yes I am working on this issue. This is my first time contributing so it will take me sometime. I will reassign the issue to me.
claim
Hi Just checking in :) Are you still working on this issue?
Yup I am still working on this issue :)
Let us know on Zulip if you need any help
with this resolved, I think rustc is free from "fuzzy provenance casts" :)
Awesome :-)

Related discussion:
text: use std::mem; use std::num::NonZeroUsize; use std::ops::ControlFlow; <ins> use std::ptr::NonNull; </ins> use std::{fmt, str}; pub use crate::ty::diagnostics::*;
Code change:
and currently store pointers as , which is not ideal: They should really work with pointers and strict provenance APIs like , , etc. See a PR fixing a similar issue for some context: (note: in that one I ended up rewriting the whole thing, I think this issue requires far less changes). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(I do plan to work on this, but if you want to work on this instead — feel free to , I can mentor you) <subcc
claim
Could you briefly describe and , also a comprehensive insight about this issue would greatly help, although I had a look at which currently is an . If I understand correctly, we are building a for this and aim to improve existing implementations as seen in languages like C++ by making it more strict, and there is some discussion that can basically do most of what C++ can and this addition might have some diverging path. Let me know, so I can move forward!
claim
Hi strict provenance means that we aren't doing pointer-int conversions and only operate through pointer types like suggested by OP. and currently use which doesn't work under strict provenance. If you'd like I can work on this issue.
Did you mean to mentor me for the same? I would be happy to learn!
is already working on this issue, is this right? Let's not override other people working on it already unless they agree or it's been several weeks with no response.
Hi yes I am working on this issue. This is my first time contributing so it will take me sometime. I will reassign the issue to me.
claim
Hi Just checking in :) Are you still working on this issue?
Yup I am still working on this issue :)
Let us know on Zulip if you need any help
with this resolved, I think rustc is free from "fuzzy provenance casts" :)
Awesome :-)

Related discussion:
text: #[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash)] pub struct Term<'tcx> { <del> ptr: NonZeroUsize, </del> <ins> ptr: NonNull<()>, </ins> marker: PhantomData<(Ty<'tcx>, Const<'tcx>)>, } <ins> #[cfg(parallel_compiler)] unsafe impl<'tcx> rustc_data_structures::sync::DynSend for Term<'tcx> where &'tcx (Ty<'tcx>, Const<'tcx>): rustc_data_structures::sync::DynSend { } #[cfg(parallel_compiler)] unsafe impl<'tcx> rustc_data_structures::sync::DynSync for Term<'tcx> where &'tcx (Ty<'tcx>, Const<'tcx>): rustc_data_structures::sync::DynSync { } unsafe impl<'tcx> Send for Term<'tcx> where &'tcx (Ty<'tcx>, Const<'tcx>): Send {} unsafe impl<'tcx> Sync for Term<'tcx> where &'tcx (Ty<'tcx>, Const<'tcx>): Sync {} </ins> impl Debug for Term<'_> { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { let data = if let Some(ty) = self.ty() {
Code change:
and currently store pointers as , which is not ideal: They should really work with pointers and strict provenance APIs like , , etc. See a PR fixing a similar issue for some context: (note: in that one I ended up rewriting the whole thing, I think this issue requires far less changes). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(I do plan to work on this, but if you want to work on this instead — feel free to , I can mentor you) <subcc
claim
Could you briefly describe and , also a comprehensive insight about this issue would greatly help, although I had a look at which currently is an . If I understand correctly, we are building a for this and aim to improve existing implementations as seen in languages like C++ by making it more strict, and there is some discussion that can basically do most of what C++ can and this addition might have some diverging path. Let me know, so I can move forward!
claim
Hi strict provenance means that we aren't doing pointer-int conversions and only operate through pointer types like suggested by OP. and currently use which doesn't work under strict provenance. If you'd like I can work on this issue.
Did you mean to mentor me for the same? I would be happy to learn!
is already working on this issue, is this right? Let's not override other people working on it already unless they agree or it's been several weeks with no response.
Hi yes I am working on this issue. This is my first time contributing so it will take me sometime. I will reassign the issue to me.
claim
Hi Just checking in :) Are you still working on this issue?
Yup I am still working on this issue :)
Let us know on Zulip if you need any help
with this resolved, I think rustc is free from "fuzzy provenance casts" :)
Awesome :-)

Related discussion:
text: impl<'tcx> Term<'tcx> { #[inline] pub fn unpack(self) -> TermKind<'tcx> { <del> let ptr = self.ptr.get(); </del> <ins> let ptr = unsafe { self.ptr.map_addr(|addr| NonZeroUsize::new_unchecked(addr.get() & !TAG_MASK)) }; </ins> // SAFETY: use of `Interned::new_unchecked` here is ok because these // pointers were originally created from `Interned` types in `pack()`, // and this is just going in the other direction. unsafe { <del> match ptr & TAG_MASK { </del> <ins> match self.ptr.addr().get() & TAG_MASK { </ins> TYPE_TAG => TermKind::Ty(Ty(Interned::new_unchecked( <del> &*((ptr & !TAG_MASK) as *const WithCachedTypeInfo<ty::TyKind<'tcx>>), </del> <ins> ptr.cast::<WithCachedTypeInfo<ty::TyKind<'tcx>>>().as_ref(), </ins> ))), CONST_TAG => TermKind::Const(ty::Const(Interned::new_unchecked( <del> &*((ptr & !TAG_MASK) as *const WithCachedTypeInfo<ty::ConstData<'tcx>>), </del> <ins> ptr.cast::<WithCachedTypeInfo<ty::ConstData<'tcx>>>().as_ref(), </ins> ))), _ => core::intrinsics::unreachable(), }