jiebi/CodeConvo huggingface dataset:
Code change:
AssignmentLhsSized,        // L = X implies that L is Sized StructInitializerSized,    // S { ... } must be Sized VariableType(ast::NodeId), // Type of each variable must be Sized <ins> ReturnType,                // Return type must be Sized </ins> RepeatVec,                 // [T,..n] --> T must be Copy // Captures of variable the given id by a closure (span is the

Related discussion:
text: The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.
Code change:
if let Categorization::Local(local_id) = err.cmt.cat { let span = self.tcx.map.span(local_id); if let Ok(snippet) = self.tcx.sess.codemap().span_to_snippet(span) { <del> db.span_suggestion( span, &format!("to make the {} mutable, use `mut` as shown:", self.cmt_to_string(&err.cmt)), format!("mut {}", snippet)); </del> <ins> if snippet != "self" { db.span_suggestion( span, &format!("to make the {} mutable, use `mut` as shown:", self.cmt_to_string(&err.cmt)), format!("mut {}", snippet)); } </ins> } } }

Related discussion:
text: Output:
The argument is of type but it is, itself, immutable. You can't redefine to point at somebody else. The rest of the message is nonsensical because it fails to realize that is the specialest of special cases in terms of method signature parsing.
Code change:
parent_item: Option<LocalDefId>, report_on: ReportOn, ) { <ins> fn get_parent_if_enum_variant<'tcx>( tcx: TyCtxt<'tcx>, may_variant: LocalDefId, ) -> LocalDefId { if let Node::Variant(_) = tcx.hir_node_by_def_id(may_variant) && let Some(enum_did) = tcx.opt_parent(may_variant.to_def_id()) && let Some(enum_local_id) = enum_did.as_local() && let Node::Item(item) = tcx.hir_node_by_def_id(enum_local_id) && let ItemKind::Enum(_, _) = item.kind { enum_local_id } else { may_variant } } </ins> let Some(&first_item) = dead_codes.first() else { return; };

Related discussion:
text: <!-- 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: build cleanly Instead, this happened: Running the program shows the field is used: <!-- 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. --Rust version 1.77.0 (tested in playground) </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Derived code is intentionally ignored for dead code analysis - if you try just You'll get a note explaining this. The note doesn't seem to be attached for warnings, just
Ah, so it's intentional. Interesting. I assume the solution is to mark it with then.
claim
release-assignment so can claim it
Error: Parsing assign command in failed: ...'assignment' ' so Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim
Note that while getting a warning if is just derived but never explicitly used may be understandable (as discussed in other issues), you will get a warning if you do use it explicitly (see ) which, in my opinion, should not be the case.
As mentioned above, the fix for this issue is adding a note about how derived traits are intentionally ignored, not to stop ignoring them.
Code change:
} // Reverse scan: Sequence comes before `first`. <del> if subfirst.maybe_empty || seq_rep.op == quoted::KleeneOp::ZeroOrMore { </del> <ins> if subfirst.maybe_empty || seq_rep.op == quoted::KleeneOp::ZeroOrMore || seq_rep.op == quoted::KleeneOp::ZeroOrOne { </ins> // If sequence is potentially empty, then // union them (preserving first emptiness). first.add_all(&TokenSet { maybe_empty: true, ..subfirst });

Related discussion:
text: The following code will cause the compiler to fail: Playground link: It should error that the inner matcher can match an empty string and reject it, just as it does if is used in place of .
The fix should be very easy, since this was already fixed for repetitions in (original bug: ): Looks like just needs to be checked against , too.
cc
Note that with on the outside, this errors properly, although with inconsistent error messages: if the inner repetition uses only, the error is "repetition matches empty token tree", but it seems that if any of the repetitions are , then the error is "multiple successful parses".
The behaviour in my previous comment is because the check for "repetition matches empty token tree" is done at definition time, but does not catch ; this is caught at expansion time however. Ideally all of this will be moved to definition time and the expansion-time check should probably be a) corrected to address the first comment and b) possibly become an ICE, since it should never be encountered since the RFC 550 rules should eliminate all ambiguity at definition time?
Hmm... I don't really remember how most of this code works... Just grepping, but it looks like there are a couple of other places we might want to look at:
I've opened
Code change:
/// Loads the current context and calls a function with it. /// Do not nest these, as that will ICE. pub(crate) fn with<R>(f: impl FnOnce(&mut dyn Context) -> R) -> R { <del> let ptr = TLV.replace(std::ptr::null_mut()) as *mut &mut dyn Context; assert!(!ptr.is_null()); let ret = f(unsafe { *ptr }); TLV.set(ptr as _); ret </del> <ins> assert!(TLV.is_set()); TLV.with(|tlv| { let ptr = tlv.get(); assert!(!ptr.is_null()); f(unsafe { *(ptr as *mut &mut dyn Context) }) }) </ins> }

Related discussion:
text: is left set to a dangling pointer if unwinds. This is unsound because a later call to will use that dangling pointer. There is a similar issue with and unwinding. since you're on the Stable MIR cc list: cc
if you can add it as a dependency, using would probably be better than rolling your own version.
Yea, that makes sense. I think we should look into using it for the module, too, which is how we get a within the compiler itself
Code change:
#[stable(feature = "unicode_encode_char", since = "1.15.0")] #[inline] pub fn encode_utf8(self, dst: &mut [u8]) -> &mut str { <del> let code = self as u32; let len = self.len_utf8(); match (len, &mut dst[..]) { (1, [a, ..]) => { *a = code as u8; } (2, [a, b, ..]) => { *a = (code >> 6 & 0x1F) as u8 | TAG_TWO_B; *b = (code & 0x3F) as u8 | TAG_CONT; } (3, [a, b, c, ..]) => { *a = (code >> 12 & 0x0F) as u8 | TAG_THREE_B; *b = (code >> 6 & 0x3F) as u8 | TAG_CONT; *c = (code & 0x3F) as u8 | TAG_CONT; } (4, [a, b, c, d, ..]) => { *a = (code >> 18 & 0x07) as u8 | TAG_FOUR_B; *b = (code >> 12 & 0x3F) as u8 | TAG_CONT; *c = (code >> 6 & 0x3F) as u8 | TAG_CONT; *d = (code & 0x3F) as u8 | TAG_CONT; } _ => panic!( "encode_utf8: need {} bytes to encode U+{:X}, but the buffer has {}", len, code, dst.len(), ), }; // SAFETY: We just wrote UTF-8 content in, so converting to str is fine. unsafe { from_utf8_unchecked_mut(&mut dst[..len]) } </del> <ins> // SAFETY: `char` is not a surrogate, so this is valid UTF-8. unsafe { from_utf8_unchecked_mut(encode_utf8_raw(self as u32, dst)) } </ins> } /// Encodes this character as UTF-16 into the provided `u16` buffer,

Related discussion:
text: The type contains a (generalized-UTF-8-encoded) sequence of code point (including potentially surrogates) that doesn’t form a surrogate pair. doesn’t check for surrogate pairs. is a public method that is documented as returning a scalar value, therefore excluding all surrogates. Ok I looked into it, there are three different people involved. The original code in 2014 was YOLO Later in 2014, moved to duplicating logic instead. In 2015, PR which first imported WTF-8 support in libstd deduplicated that logic by adding a function that takes . (I knew that approach sounded familiar…) In 2016, PR changed the signature of and in passing removed . It made use + instead, presumably in the middle of updating many callers other.
Okay, so the fix would be to revert the part of that removed ?
That or copy into . I find them both not great, so meh.
Even with that done, there's still UB in another testcase: This is converting something to a before calling -- so probably the same issue as the above, just for a different encoding.
Code change:
/// /// [`to_ascii_uppercase`]: #method.to_ascii_uppercase #[stable(feature = "ascii_methods_on_intrinsics", since = "1.23.0")] <del> #[rustc_const_unstable(feature = "const_make_ascii", issue = "130698")] </del> <ins> #[rustc_const_stable(feature = "const_make_ascii", since = "CURRENT_RUSTC_VERSION")] </ins> #[inline] <ins> #[cfg_attr(bootstrap, rustc_allow_const_fn_unstable(const_mut_refs))] </ins> pub const fn make_ascii_uppercase(&mut self) { // FIXME(const-hack): We would like to simply iterate using `for` loops but this isn't currently allowed in constant expressions. let mut i = 0;

Related discussion:
text: Feature gate: This is a tracking issue for marking the and methods in , , , and as "const." [x] Implementation for : [x] Implementation for : [x] Implementation for and : [x] Final comment period (FCP) [x] Stabilization PRNone yet.
fcp merge / have been stable in const since 1.52. / are unblocked now by the stabilization of
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [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.
Can the methods be included in this? Similarly const stable / since 1.52.
Yes, that sounds like a good idea. I'll try adding another PR later.
:bell: This is now entering its final comment period, as per the . :bell:
stabilises this.
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. This will be merged soon.
Code change:
<ins> struct NotCopyable; fn func<F: FnMut() -> H, H: FnMut()>(_: F) {} fn parse() { let mut var = None; func(|| { // Shouldn't suggest `move ||.as_ref()` here move || { //~^ ERROR: cannot move out of `var` var = Some(NotCopyable); } }); } fn main() {} </ins>

Related discussion:
text: gives the error: Error0507 gives a wrong suggestion here:
Error: Label D-invalid-suggestion can only be set by Rust team members Please let know if you're having trouble with this bot.
modify labels: A-suggestion-diagnostics C-bug T-compiler
Code change:
<ins> // ignore-32bit // This test gives a different error on 32-bit architectures. union Transmute<T: Copy, U: Copy> { t: T, u: U, } trait Bar { fn bar(&self) -> u32; } struct Foo { foo: u32, bar: bool, } impl Bar for Foo { fn bar(&self) -> u32 { self.foo } } #[derive(Copy, Clone)] struct Fat<'a>(&'a Foo, &'static VTable); struct VTable { size: Foo, } const FOO: &dyn Bar = &Foo { foo: 128, bar: false, }; const G: Fat = unsafe { Transmute { t: FOO }.u }; //~^ ERROR it is undefined behavior to use this value fn main() {} </ins>

Related discussion:
text: <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Compiler error on but ICE on label +regression-from-stable-to-stable
cc
A previous (now-fixed) ICE with the same error message is
Thanks for the report! Would be good to get a better backtrace; this one seems to be missing many frames and there are no line numbers.
, I updated the backtrace in my first post. I used rustup to get the latest trunk version, and the one I have been using does not have line numbers. If there is a flag or configuration for rustup to get rustc binaries with line numbers, I would be happy to change the settings on my testing machine.
I think getting line numbers requires a debug build of the compiler, so it's not quite as easy as installing something via rustup.
Labeling .
Here's a backtrace with debug info: <details</details
Unfortunately, this bottoms out ; more digging will be needed to determine the true underlying cause of the error.
Here is the actual backtrace of the underlying CTFE/Miri error: <details</detailsIt points to this line: can handle pointer values just fine, so I think what is happening is that we are reading parts of a pointer value here, which indeed is not supported in CTFE.
So... I guess the fix is to make this kind of error also be permitted during validation and turn it into a proper validation error?
Permitting it at the top-level is no good, since then we don't know "where in the value" it arose. We need a version of that catches this error and turns it into a validation error with the current "path".
Oh... right, we should fix this in general, and not just wrap in .
Code change:
<ins> // ignore-32bit // This test gives a different error on 32-bit architectures. union Transmute<T: Copy, U: Copy> { t: T, u: U, } trait Bar { fn bar(&self) -> u32; } struct Foo { foo: u32, bar: bool, } impl Bar for Foo { fn bar(&self) -> u32 { self.foo } } #[derive(Copy, Clone)] struct Fat<'a>(&'a Foo, &'static VTable); struct VTable { size: Foo, } const FOO: &dyn Bar = &Foo { foo: 128, bar: false, }; const G: Fat = unsafe { Transmute { t: FOO }.u }; //~^ ERROR it is undefined behavior to use this value fn main() {} </ins>

Related discussion:
text: Maybe we should not have any automatic way to bubble up errors and require all sites to use ?
I think we should wrap it but put the wrapped thing into a helper function sow e can also use it for the other places. So basically, you want to use a different error type for validation, one that excludes all the other errors? I am open to refactorings here.
Let's start out with wrapping, and then I can experiment with the refactoring so we can have a look at the usability effect of it Instructions: wrap the call at in a macro invocation and capture the error. Emit a validation message about the fact that reading parts of a pointer is not possible during CTFE. Don't forget to add a test (the failing example from this issue works great as a test) and run the test with
There are quite a few calls in that will all have this problem, so ideally they should all be treated this way. To avoid code duplication, it will probably make sense to move this into a helper function.
Reopening this to track that is still called unguarded a few times in , so e.g. the issue can still arise with .
Code change:
offsets[usize::try_from(field).unwrap()], layout::FieldPlacement::Array { stride, .. } => { let len = base.len(self)?; <del> assert!(field < len, "Tried to access element {} of array/slice with length {}", field, len); </del> <ins> if field >= len { // This can be violated because this runs during promotion on code where the // type system has not yet ensured that such things don't happen. debug!("Tried to access element {} of array/slice with length {}", field, len); return err!(BoundsCheck { len, index: field }); } </ins> stride * field } layout::FieldPlacement::Union(count) => {

Related discussion:
text: Originally stumbled upon through the eval IRC bot: Here's the smallest reproduction I could get, Removing either the block or the borrow displays only a normal compiler error (not an ICE) trace
triage: P-high, assigned to ; removing I-nominated label
Code change:
LL | m!(); | ----- in this macro invocation <del> warning: `$crate` may not be imported </del> <ins> error: `$crate` may not be imported </ins> --> $DIR/dollar-crate-is-keyword.rs:9:9 | <del> LL |         use $crate; // OK </del> <ins> LL |         use $crate; </ins> |         ^^^^^^^^^^^ ... LL | m!(); | ----- in this macro invocation <del> | = note: `use $crate;` was erroneously allowed and will become a hard error in a future release warning: `$crate` may not be imported --> $DIR/dollar-crate-is-keyword.rs:11:9 </del> <ins> error: `$crate` may not be imported --> $DIR/dollar-crate-is-keyword.rs:10:9 </ins> | LL |         use $crate as $crate; |         ^^^^^^^^^^^^^^^^^^^^^ ... LL | m!(); | ----- in this macro invocation <del> | = note: `use $crate;` was erroneously allowed and will become a hard error in a future release error: aborting due to 2 previous errors </del> <ins> error: aborting due to 4 previous errors </ins>

Related discussion:
text: The warning was introduced in to avoid breakage from .
Presumably the next step is to make this an error by default.
Triage: Digging through all the linked issues is tough, and it's not clear to me exactly what this warning is or does. can you maybe elaborate a little?
This needs to be turned into an error, i.e. behave like basically:
Relevant code is here: Should be easy to turn that into and then do a crater run.
Code change:
/// ``` #[macro_export] macro_rules! write { <del> ($dst:expr, $($arg:tt)*) => ((&mut *$dst).write_fmt(format_args!($($arg)*))) </del> <ins> ($dst:expr, $($arg:tt)*) => ($dst.write_fmt(format_args!($($arg)*))) </ins> } /// Equivalent to the `write!` macro, except that a newline is appended after

Related discussion:
text: For clarity, the second call to ends up using the impl on . cc I had concerns about this kind of thing when these impls were being introduced but I thought I convinced myself that this kind of thing couldn't happen. Did something change in the way we designed these impls since then?
Possible solutions are to either remove the impl for or update to prevent it from invoking . Seems to me like the second is the better approach.
I believe the reason for the was because it was considered a good thing to require callers to explicitly pass references. I think we've actually gone back and forth on that a few times. Are we committed now to allowing callers to just say ?
Code change:
use libc::{mmap, munmap}; use libc::{sigaction, sighandler_t, SA_ONSTACK, SA_SIGINFO, SIGBUS, SIG_DFL}; use libc::{sigaltstack, SIGSTKSZ, SS_DISABLE}; <del> use libc::{MAP_ANON, MAP_PRIVATE, PROT_READ, PROT_WRITE, SIGSEGV}; </del> <ins> use libc::{MAP_ANON, MAP_PRIVATE, PROT_NONE, PROT_READ, PROT_WRITE, SIGSEGV}; use crate::sys::unix::os::page_size; </ins> use crate::sys_common::thread_info; #[cfg(any(target_os = "linux", target_os = "android"))]

Related discussion:
text: Rust's runtime installs a signal handler to distinguish stack overflows from other faults. This requires using an alternate signal stack (), which we create with the default size . That's usually quite small, 8KB or so depending on the target, but it's still plenty for what the handler is doing. There's currently no guard page like we have on normal stacks. That alternate stack is shared by all signals for a thread, so if a user installs any other signal handler, and they opt in with the flag , they'll be limited to the same tiny stack. If their handler happens to be more involved and overflows that stack, it may silently clobber other memory. If we had a guard page on the signal stack, that would cause a process abort instead. This was reported to the Security Response WG with a reproducer in . However, after discussion we decided to treat this as a normal issue for a few reasons: Setting a custom signal handler requires code. Signal handlers already run in a quite constrained environment, e.g. . It's unusual to use for signals other than , and if you choose so, you also bear responsibility to make sure that stack suffices. Nevertheless, as a defensive measure, it's still a reasonable idea to map a guard page when Rust is creating its signal stack, so an unexpected overflow will abort rather than silently corrupting memory. For full protection, that would also depend on the guard page not being skipped, but not all targets have stack probes yet (). Thanks to for reporting this in accordance with our , even though we have decided not to treat this as a security issue at this time. cc
cc This is another reason we perhaps shouldn't be registering the signal handler... cc
Code change:
// no-pretty-expanded FIXME #15189 // ignore-android FIXME #17520 <del> // ignore-msvc FIXME #28133 </del> <ins> // compile-flags:-g </ins> use std::env; use std::process::{Command, Stdio}; use std::str; <del> use std::ops::{Drop, FnMut, FnOnce}; </del> #[inline(never)] fn foo() {

Related discussion:
text: Symbol names are not properly supported yet on msvc, so backtraces are generally unhelpful. As a result, is currently disabled. This issue can be closed when it's been reenabled.
Code change:
types that do not implement `Drop` can still have drop glue, consider instead using `{$needs_drop}` to detect whether a type is trivially dropped lint_range_endpoint_out_of_range = range endpoint is out of range for `{$ty}` <del> .suggestion = use an inclusive range instead </del> <ins> lint_range_use_inclusive_range = use an inclusive range instead </ins> lint_overflowing_bin_hex = literal out of range for `{$ty}` .negative_note = the literal `{$lit}` (decimal `{$dec}`) does not fit into the type `{$ty}`

Related discussion:
text: <!-- 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: printing all numbers from 0 to 255 (inclusive) Instead, this happened: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The error is correct, 256 is indeed out of range for u8. You need to use .
You can run that code if you want, by allowing the lint: if you do you'll see that it will print nothing because the overflows and becomes , so it's which is empty. Examples like this where allowing the literal overflow would do something you don't want are exactly why this lint is deny-by-default
I've renamed this issue because the lint is correct. If there's anything to be done here, it would be to add a range-specific suggestion for this situation to help guide towards the correct code.
claim