jiebi/CodeConvo huggingface dataset:
Change:
let mut base = self; let mut acc = 1; <del> let mut prev_base = self; let mut base_oflo = false; while exp > 0 { </del> <ins> while exp > 1 { </ins> if (exp & 1) == 1 { <del> if base_oflo { // ensure overflow occurs in the same manner it // would have otherwise (i.e. signal any exception // it would have otherwise). acc = acc * (prev_base * prev_base); } else { acc = acc * base; } </del> <ins> acc = acc * base; </ins> } <del> prev_base = base; let (new_base, new_base_oflo) = base.overflowing_mul(base); base = new_base; base_oflo = new_base_oflo; </del> exp /= 2; <ins> base = base * base; </ins> } <ins> // Deal with the final bit of the exponent separately, since // squaring the base afterwards is not necessary and may cause a // needless overflow. if exp == 1 { acc = acc * base; } </ins> acc }

Discussion:
Today I learned that eight to the power of eight is zero. Who'da thunk? Incorrect: :arrowright: :x: :arrowright: :x: :arrowright: :x: Correct: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: Oddly enough, this one breaks the pattern: :arrowright: overflow :whitecheck_mark: Haven't bothered with further cases; at this point it's probably best to just look at the implementation and see what's going on.
was supposed to fix this; looks like it missed the unsigned version?
says that is on nightly.
I meant that fixed this for pow() on signed integers, but not on unsigned integers; it looks like the implementation is copy-pasted for some reason.
Could I take a stab at this?
Sure; feel free to ask if you have questions.
Is overflow checking off in the libcore tests? It'd be nice to be able to write some standard tests for overflow, but they seem to not panic even on cases that should right now.
Overflow checking in unit tests () reflects whether the whole compiler was built in debug or release mode. If you need to specify the overflow mode, you can use a separate test which explicitly specifies , like .
This has since been fixed, in , which it looks like also a test, so closing.
Change:
<ins> // min-lldb-version: 310 // We have to ignore android because of this issue: // https://github.com/rust-lang/rust/issues/74847 // ignore-android // compile-flags:-g // === GDB TESTS =================================================================================== // gdb-command:run // gdb-command:info args // gdb-check:No arguments. // gdb-command:continue // === LLDB TESTS ================================================================================== // lldb-command:run // lldb-command:frame variable // lldbg-check:(unsigned long) = 111 (unsigned long) = 222 // lldbr-check:(unsigned long) = 111 (unsigned long) = 222 // lldb-command:continue #![feature(naked_functions)] #![feature(omit_gdb_pretty_printer_section)] #![omit_gdb_pretty_printer_section] fn main() { naked(111, 222); } #[naked] fn naked(x: usize, y: usize) { zzz(); // #break } fn zzz() { () } </ins>

Discussion:
When compiling () The generated assembly includes a prologue with unexpected 's (as well as a trailing , already reported in ) Expected behaviour would be to have no prologue (and prevent compilation of a function that is not as this would require implementing an undefined ABI, contrarily to what seems to happen ). This is treacherous, as it dereferences some memory locations that may not be accessible, as happened to me and led to hours of debugging to finally figure out the compiled function was not the one defined. cc
IIRC this is invalid and rustc should reject such a function, naked functions can't take arguments and the compiler should probably enforce that.
Hmm, my understanding of the RFC (“The following variant is not an error because the C calling convention is well-defined and it is thus possible for the programmer to write a conforming function”, even if the example is not with an argument) would mean that if the function is declared , then the function can actually respect the said ABI, thus should be well-formed?
Is there an update on this? I was hit by this issue as well. I hit the problem when compiling a tock app (baremetal-ish and jumped to by the tock OS) A naked function with arguments would produce this prolog (RV32): Which would result in an invalid access as s0 would be 0. Removing the arguments would remove the prologue and fix the problem. Removing the naked cfg would also work as teh stack pointer was already setup by the OS and result in this. If arguments with naked functions aren't supported rustc should generate an error as this is a difficult problem to debug.
This is an LLVM bug. Has it been reported upstream?
Change:
} ty::FnDef(did, substs) => { <del> let obligations = self.nominal_obligations(did, substs); </del> <ins> let obligations = self.nominal_obligations_without_const(did, substs); </ins> self.out.extend(obligations); }

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: () I expected to see this happen: Successful compilation Instead, this happened: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.65.0 <!-- Provide the version you are using that has the regression. --: modify labels: +regression-from-stable-to-beta -regression-untriaged
This became an error due to ( <details<summaryBisect info</summarysearched nightlies: from nightly-2022-09-18 to nightly-2022-11-07 regressed nightly: nightly-2022-09-23 searched commit range: regressed commit: bisected with <a href=''cargo-bisect-rustc</av0.6.4 Host triple: I used on the following file </details
Assigning priority as by the Prioritization Working Group.
awaiting beta backport
Can this be closed now that beta backport () is complete?
Change:
<ins> // This test ensures that the documentation list markers are correctly placed. // It also serves as a regression test for <https://github.com/rust-lang/rust/issues/130622>. go-to: "file://" + |DOC_PATH| + "/test_docs/long_list/index.html" show-text: true // 0.3em assert-css: (".docblock li p:not(last-child)", {"margin-bottom": "4.8px"}) assert-css: (".docblock li p + p:last-child", {"margin-bottom": "0px"}) // 0.4em assert-css: (".docblock li", {"margin-bottom": "6.4px"}) </ins>

Discussion:
<!-- 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 ran the following commands: <details<summaryOn 2024-10-01, this renders like this</summary! </details<details<summaryOn 2024-10-02, this renders like this</summary! </detailsNote that the bullet points are spaced farther apart. I'm assuming this is a regression?
I think this is a consequence of which was intended to address . GG is adding a UI regression test for the spacing in for . cc
It's indeed something that we changed on purpose.
Little modification: the changes are improving the situation but introducing some new other issues. Talking about it currently to figure out what's the best solution.
I opened Please don't hesitate to take a look. Hopefully I was able to improve the current situation without going back to the original issue.
Certainly seems better than before!
Change:
("(len: %i, cap: %i)" % (length, cap))) def children(self): <ins> saw_inaccessible = False </ins> (length, data_ptr, cap) = rustpp.extract_length_ptr_and_cap_from_std_vec(self.__val) gdb_ptr = data_ptr.get_wrapped_value() for index in xrange(0, length): <del> yield (str(index), (gdb_ptr + index).dereference()) </del> <ins> if saw_inaccessible: return try: # rust-lang/rust#64343: passing deref expr to `str` allows # catching exception on garbage pointer str((gdb_ptr + index).dereference()) yield (str(index), (gdb_ptr + index).dereference()) except RuntimeError: saw_inaccessible = True yield (str(index), "inaccessible") </ins> class RustStdVecDequePrinter(object):

Discussion:
Related WIP pull request:
I'm getting this when running reliably:
This test is also failing for me with GDB 8.3 on Arch. Same error. As of GDB 8.3, batch mode causes GDB to exit with non-zero exit status if a command failed, per We either need to execute the "failing" command (the print that accesses invalid memory) from python in gdb and ignore the exception thrown, or ignore the return code of gdb for this test.
pre-triage: not certain what priority to assign (tempted to do P-medium). Leaving nominated for dicsussion of priority at T-compiler meeting. Also, I think I'll nominate for discussion there too.
topic is too big to handle in triage meeting. Plan is now to allocate steering meeting to topic; see:
for now, tagging P-high because this is causing pain for T-release. Hopefully we'll figure something out in the aforementioned planning meeting. Removing nomination.
there's a planning meeting scheduled Oct 18th to discuss debuginfo; this will hopefully be addressed as part of that. See
self-assigning to at least look into this as part of prep work for aforementioned planning meeting.
I'm confused by . AFAIK the issue here is the test is not compatible with more recent GDB versions, could you elaborate?
I believe the impression in the planning meeting was that a rustc change broke this test -- if it is a GDB version issue we can likely work to fix the test and bump GDB version requirements.
This was definitely a change to GDB that made the test fail. It still does the expected behavior, but GDB now returns a failure return code.
adding to assignee list to deal with the test suite stuff to T-release. (See also )
Of potential interest: This bug does not reproduce for me on a build with in the ; I have to turn the setting back to its default of to reproduce the problem.
Change:
DiagnosticId::Error(s) => s, DiagnosticId::Lint(s) => s, }; <del> let explanation = je.registry.as_ref().and_then(|registry| registry.find_description(&s)); </del> <ins> let je_result = je.registry.as_ref().map(|registry| registry.try_find_description(&s)).unwrap(); </ins> <del> DiagnosticCode { code: s, explanation } </del> <ins> DiagnosticCode { code: s, explanation: je_result.unwrap_or(None) } </ins> }) } }

Discussion:
The functionality (does anyone still uses this now that it's ?) gives the same "no extended information" message for real error codes that don't have a "long" explanation written, and nonexistent codes. These messages should be disambiguated (as "no extended information for E0XXX" vs. "E0XXX does not exist" or similar). I thought this would be straightforward to implement: we (which get successfully , although the ), only to when macroexpanding the arrays . So this should, you would think, just be a matter of editing reflect that, and making the care. But when I actually do this (zackmdavis/rust ... my changes to seem to have absolutely no effect (!?!); we still get a even though I thought my code pretty clearly said otherwise, on more than one day that I've looked at this. I hereby give up in despair, bafflement, and tears. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The diagnostic registration is "just" a macrorules macro now so I suspect this is pretty simple to implement per the suggested path in the issue description; I'm going to mark as E-easy and E-mentor with myself as the mentor. You'll want to edit the array definitions to have the type or so and add in the short diagnostics. Once that's done, if you run you'll likely hit an error in the use site of from . Fixing that'll mostly involve fixing up the diagnostics registry in ; I would store the long diagnostics and short diagnostics separately, adding a field like . Once this is done, there might be a few more type errors to clean up but that should mostly be a matter of making types match up I would hope. Let me know if you have any questions; here on this issue or feel free to open up a PR with some initial work and I can try and provide feedback there.
One additional thing that we should probably add as part of this work is an error if the same diagnostic code is registered twice (cc ).

I imagine this would mostly be a matter of inserting all the codes into an FxHashSet and panicking if there's one inserted twice; an ICE here is fine since it'll definitely be caught in CI.
Hey, If this still needs fixed, I would love to work on this. I will probably be reaching out before to long for some guidance. claim
Shoot not sure if I read what was happening in this thread all the way. are you working on this already?
I'm not; go for it! (Although ... I thought I remembered seeing an issue recently where people were discussing moving away from the numeric error codes, but I can't find it. was that a real thing?)
Maybe you are referring to this conversation on Zulip? https://rust-
Change:
maybe_did.unwrap_or(did) }) } <del> // Tuple struct constructors across crates are identified as // DefFn types, so we explicitly handle that case here. Some(&def::DefFn(did, _, _)) if !is_local(did) => { match csearch::get_tuple_struct_definition_if_ctor( &self.tcx.sess.cstore, did) { Some(did) => guard(did), None => {} } } </del> _ => {} } }

Discussion:
compiles fine (other than the dead code warning for ), but is not:
I hit this as well, I would love a fix :+1:
Change:
skol_br, tainted_region); <ins> let issue_32330 = if let &ty::ReVar(vid) = tainted_region { match self.region_vars.var_origin(vid) { RegionVariableOrigin::EarlyBoundRegion(_, _, issue_32330) => { issue_32330.map(Box::new) } _ => None } } else { None }; </ins> if overly_polymorphic { debug!("Overly polymorphic!"); return Err(TypeError::RegionsOverlyPolymorphic(skol_br, <del> tainted_region)); </del> <ins> tainted_region, issue_32330)); </ins> } else { debug!("Not as polymorphic!"); return Err(TypeError::RegionsInsufficientlyPolymorphic(skol_br, <del> tainted_region)); </del> <ins> tainted_region, issue_32330)); </ins> } } }

Discussion:
This code: Produces this internal compiler error: Interestingly, changing to or causes the code compile fine (modulo unused variable warnings). : Backtrace:
This is a regression in 1.17.0-beta. Earlier versions give:
Duplicate of .

Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.
Change:
// Unlike `mem::transmute`, a MIR `Transmute` is well-formed // for any two `Sized` types, just potentially UB to run. <del> if !op_ty.is_sized(self.tcx, self.param_env) { </del> <ins> if !self .tcx .normalize_erasing_regions(self.param_env, op_ty) .is_sized(self.tcx, self.param_env) { </ins> self.fail( location, format!("Cannot transmute from non-`Sized` type {op_ty:?}"), ); } <del> if !target_type.is_sized(self.tcx, self.param_env) { </del> <ins> if !self .tcx .normalize_erasing_regions(self.param_env, *target_type) .is_sized(self.tcx, self.param_env) { </ins> self.fail( location, format!("Cannot transmute to non-`Sized` type {target_type:?}"),

Discussion:
<!-- 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. --: Should be able to consistently trigger on Windows platform <details<summaryBacktrace</summary</details
I attempted to create a minimial reproduction based on the code I saw and was not able to get an ICE on the latest nightly (2023-04-09). Could you try updating to the latest nightly and see whether that fixed it? There have been a few issues with transmute that got fixed in the last few days.
This is fixed by
Change:
/// assertions disabled. This intrinsic is primarily used by [`assert_unsafe_precondition`]. #[rustc_const_unstable(feature = "delayed_debug_assertions", issue = "none")] #[unstable(feature = "core_intrinsics", issue = "none")] <ins> #[inline(always)] </ins> #[cfg_attr(not(bootstrap), rustc_intrinsic)] pub(crate) const fn debug_assertions() -> bool { cfg!(debug_assertions)

Discussion:
The compiler compiled with debug assertions has gotten really slow recently. For example, compiling the standard library takes way longer than it used to. This is bad, it makes it way harder to work on rustc.
This is probably because of the recent changes to . It contains a cfg(bootstrap) hack for that's not inlined. Additionally, it outlines the predicate, which is super slow as well. Fixing the former is easy, fixing the latter is harder and requires adding .
turns out this was caused by many different factors compounding in an unfortunate way :D oli's intrinsic changes outlining some important functions, and the unsafe preconditions being quite bad for runtime performance
Change:
debuginfo::create_captured_var_metadata( bcx, def_id.node, <del> self_type, </del> env_pointer_alloca, i, captured_by_ref,

Discussion:
So, this code raises an assertion in llvm when compiling with -g. Without -g it works fine. Raised assertion is Edit: reduced code more
Duplicate of ? (there are some comments with unboxed closures and /)
It worked with the rustc versions from around last week. Especially the rustup versions. A friend just tested it with his "old" version from 11/26, and it still works there. So either it's new or it's a regression bug.
cc
I'll look into it.
I suspect the culprit is makereturnslotpointer in librustctrans::trans::builder
Change:
Ok(const_uint((!a).wrapping_add(1))) } <ins> fn const_uint_not(a: u64, opt_ety: Option<UintTy>) -> const_val { let mask = match opt_ety { Some(UintTy::U8) => u8::MAX as u64, Some(UintTy::U16) => u16::MAX as u64, Some(UintTy::U32) => u32::MAX as u64, None | Some(UintTy::U64) => u64::MAX, }; const_uint(!a & mask) } </ins> macro_rules! overflow_checking_body { ($a:ident, $b:ident, $ety:ident, $overflowing_op:ident, lhs: $to_8_lhs:ident $to_16_lhs:ident $to_32_lhs:ident,

Discussion:
This affects the test suites for the and crates.
triage: I-wrong, P-high (1.0)
triage: P-high (1.0)
I ended up adding the 1.0 milestone by hand; isn't the above note with supposed to do it?
cc
the log above says that highfive did add this to the 1.0 milestone - it might just have been that your local view of the webpage needed refreshing?
yeah I guess so, I don't know what happened anymore. Maybe I should have given highfive a little more time to react.
Change:
extern "C" { fn qüx();  //~ ERROR non-ascii idents <ins> //~^ ERROR items in `extern` blocks </ins> } fn main() {}

Discussion:
It was mentioned in that in the original RFC text, there's text that said the non-ASCII identifiers should be disallowed within extern blocks. This is a niche use-case and i believe this doesn't need to block stablization. Creating this issue here to track it.
What will something like actually link against? This seems like it might be a forward-compatiblity hazard when linking to external code, since the precise mangling/encoding isn't clear
I think we should just disallow for now; and later check out what C does and match that.
do you want to implement this? Should be a simple check in the parser.
Sure, let me give it a try.
Implemented in .
On the other hand the use of non-ASCII symbol names is already stable through link_name attribute.
Out of curiosity, I checked how Clang and GCC mangle the symbol: they simply use UTF-8. MSVC doesn't seem to allow non-ascii in identifier. (Notice how the byte-length encoding in C++ is using the UTF-8 byte count, and not the code point count, as I would expect)
Yeah I feel like the functionality can be re- with an FCP without much work, there just needs to be some research on how stable those mangling schemes are around this.
As for , my take on that is that once you're using that you're trying something weird and know what you're doing; there is no point restricting it further since it's very easy to accidently block out legit use cases.
Inversely, I've just noticed that despite usage of a properly-ASCII-ed , if the "Rust name" is non-ASCII then it is still rejected:
Change:
<del> Subproject commit 8d24b02414073bd4dafd3810205265c668dbcae1 </del> <ins> Subproject commit 4cf36f285084f8f841f3cff7b29d44b1d95ee1dd </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Hey don't blame the rollerupperer! Looks like this was :)
Yeah I'm on it.
Change:
--> $DIR/E0604.rs:2:5 | LL |     1u32 as char; <del> |     ^^^^^^^^^^^^ invalid cast | help: try `char::from_u32` instead --> $DIR/E0604.rs:2:5 | LL |     1u32 as char; </del> |     ^^^^^^^^^^^^ <ins> |     | |     invalid cast |     help: try `char::from_u32` instead: `char::from_u32(1u32)` </ins> error: aborting due to previous error

Discussion:
<!-- 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. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Et Voila! ! Here's the final result, pushing a PR soon
Should be fixed by