jiebi/CodeConvo huggingface dataset:
Change:
use cell::RefCell; use intrinsics; use sync::StaticRwLock; <ins> use sync::atomic::{AtomicBool, Ordering}; </ins> use sys::stdio::Stderr; use sys_common::backtrace; use sys_common::thread_info;

Discussion:
Given this code, the failure message looks like this This is problematic as the useful information (the message passed to )is buried inside the sentence. It'd be better if the failure message was on its own line, something akin to: This format also allows for space to mention other useful information (e.g. issue ).
Is this still something we want to do? I have a small patch that implements something like this and would also but I'm not sure how many people really want another format for panic messages. Changing the format might also break existing tools (for example, there are several run-tests in this repo that expect a panic).
I'd be all for it, I still find those messages hard to read even after all these years.
you should submit it
The pull request didn't really fix this bug... should I make another bug like this, or is this a wontfix now?
Oh sorry, that's because I didn't change the original pull request message. Perhaps can comment on this?
This is somewhat of a wontfix for now, the discussion of concluded that we likely don't want to radically change the format for now due to the concurrency/verbosity reasons mentioned. If this becomes extra onerous in the future, however, we can consider reformatting these messages.

Rust developers are developers. Many will be used to using a debugger. Lets tell them straight up from the message how they can hook up their debugger without having to know anything about rust's name mangling algorithm.
Used as workaround in , but still discovered from other people instead of documentation. . Mentioning in the panic message and possibly in the documentation for might be a good idea. If nobody is already doing this, I will :)
Change:
<ins> #![feature(generator_trait)] #![feature(generators)] #![deny(unused_braces, unused_parens)] use std::ops::Generator; use std::pin::Pin; fn main() { let mut x = |_| { while let Some(_) = (yield) {} while let Some(_) = {yield} {} // Only warn these cases while let Some(_) = ({yield}) {} //~ ERROR: unnecessary parentheses while let Some(_) = ((yield)) {} //~ ERROR: unnecessary parentheses {{yield}}; //~ ERROR: unnecessary braces {( yield )}; //~ ERROR: unnecessary parentheses // FIXME: Reduce duplicate warnings. // Perhaps we should tweak checks in `BlockRetValue`? while let Some(_) = {(yield)} {} //~^ ERROR: unnecessary braces //~| ERROR: unnecessary parentheses while let Some(_) = {{yield}} {} //~^ ERROR: unnecessary braces //~| ERROR: unnecessary braces // FIXME: It'd be great if we could also warn them. ((yield)); ({ yield }); }; let _ = Pin::new(&mut x).resume(Some(5)); } </ins>

Discussion:
I tried this code: I expected to see this happen: no warning Instead, this happened: if I follow the suggestion, then compilation fails: ( takes an optional expression, not wrapping it in parentheses means the block becomes that expression, and the is then missing a block). - `rustc 1.47.0-nightly (2020-07-27 )
The lint is a rustc lint, not a Clippy lint. This issue should probably be moved to the rust-lang/rust repo. can you move this issue, please?
Done, thanks
Change:
} } <ins> fn suggest_missing_parentheses(&self, err: &mut DiagnosticBuilder<'_>, expr: &hir::Expr<'_>) { let sp = self.tcx.sess.source_map().start_point(expr.span); if let Some(sp) = self.tcx.sess.parse_sess.ambiguous_block_expr_parse.borrow().get(&sp) { // `{ 42 } &&x` (#61475) or `{ 42 } && if x { 1 } else { 0 }` self.tcx.sess.parse_sess.expr_parentheses_needed(err, *sp, None); } } </ins> fn note_need_for_fn_pointer( &self, err: &mut DiagnosticBuilder<'_>,

Discussion:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .
Change:
// The loop condition must ensure that there's enough headroom to read LANE bytes, // and not only at the current index but also at the index shifted by block_offset const UNROLL: usize = 4; <del> while i + second_probe_offset + UNROLL * Block::LANES < haystack.len() && !result { </del> <ins> while i + last_byte_offset + UNROLL * Block::LANES < haystack.len() && !result { </ins> let mut masks = [0u16; UNROLL]; for j in 0..UNROLL { masks[j] = test_chunk(i + j * Block::LANES);

Discussion:
PR a x8664 SIMD-based implementation of to optimize searching into strings when the needle is at most 32 bytes long. Unfortunately, that implementation doesn't seem to be sound. When compiling the standard library with debug assertions on, running UI tests excluding results in compiletest itself panicking before executing any test due to a in libcore: To reproduce the issue, use the following configuration file: run: cc
Tentatively opened a revert PR in
Ugh. I ran it under miri with quite a combinatorial test that I thought should cover all the edge-cases. It's not immediately obvious what's wrong, so it's fine to land the revert for now.
Last I checked (and a lot has happened since then so I could be working on outdated info -- might be able to confirm), miri can't catch failure in many cases I believe, since it's "just" library UB.
the memory will be accessed after the get_unchecked so it should still be an invalid memory access when it's out of bounds. Unless I'm just doing some shortening slicing and then extending it again so that it's valid within the same allocation but not correct slicing.
What says is correct. The error here is in a situation like Miri (without Stacked Borrows) will not complain about that since the index is in-bounds of the allocation. But the debug assertion will complain since you are causing library UB by going out-of-bounds of the slice. I don't quite understand your last comment,
It seems like the test is just insufficient. Even with debug asserts and overflow checks enabled it doesn't catch it. I'll have to reproduce it first to figure out what's missing.
Ooh, I was getting absolutely unexplainable compiler errors when building stage 1 libstd with a stage 0 rustc which was built with however, could this be the cause for this? :sweat_smile:
Possible, but it would also do incorrect things on x86-64 baseline
has a proper fix
Change:
return Err(ecx.struct_span_err(sp, "requires at least a format string argument")); } <del> let fmtstr = p.parse_expr()?; </del> <ins> let first_token = &p.token; let fmtstr = match first_token.kind { token::TokenKind::Literal(token::Lit { kind: token::LitKind::Str | token::LitKind::StrRaw(_), .. }) => { // If the first token is a string literal, then a format expression // is constructed from it. // // This allows us to properly handle cases when the first comma // after the format string is mistakenly replaced with any operator, // which cause the expression parser to eat too much tokens. p.parse_literal_maybe_minus()? } _ => { // Otherwise, we fall back to the expression parser. p.parse_expr()? } }; </ins> let mut first = true; let mut named = false;

Discussion:
says: ... which isn't exactly where the was expected. () Another variation is this code: which gives this result: ()
Hello, I am a quite new contributor, and I'd like to tackle this issue. Do you think that is possible? I have looked a bit at the code, and I think this mostly comes from the [] function, more precisely, [this condition][cond] can be tweaked. Is that correct? []: [cond]:
Turns out I was terribly wrong. The problem is that the following snippet: Can be rewritten as: And that the [] function looks for an expression as the first argument ([corresponding code][expression], [code example][snippet]). Consequently, is the said expression, which explain why the error is raised on the first . Now that I know where the error comes from. I think the best way to fix this issue is to check if this expression can be a format string, perhaps with the [] function. I am still unsure about the quality of the emitted error, but at least it would have the correct span. []: [expression]: [snippet]: []:
Change:
<del> Subproject commit e979eb4cc55ffd357158c7d30133cbf894e93fe9 </del> <ins> Subproject commit cbedd97b3a58023eff365a2fa74700d06115144a </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. 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! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
) -> usize { let (trait_to_be_found, trait_owning_vtable) = key; <ins> // #90177 let trait_to_be_found_erased = tcx.erase_regions(trait_to_be_found); </ins> let vtable_segment_callback = { let mut vtable_base = 0;

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. --: This is also present in beta and nightly versions, but it is not present on 1.55.0 stable. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
56.0 is released on stable, and it ICEs there as well. label regression-from-stable-to-stable
Bisection led to nightly-2021-07-26. Automatic commit bisection failed. Manual commit bisection: Regression comes from .
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Oops. Sorry for creating this ICE. I haven't really dig into this issue yet, but from the description, it seems this ICE comes from where the equality should be within a certain call, but didn't because of the HRTB region. This inequality is because the two parameters comes from two different routes. The first comes from iterator, which is called from The second comes from generator, which lived in , i think the call is the real difference here. This is my current theory, and i'll try to validate it with debugging rustc this week. I'm not totally sure what's the best way to fix this. I think maybe could give me some advice dealing with HRTBs here?
By the way, i've printed out the contents of the vtable for :
Should it just use ? Or I guess it needs the too... Hmm, probably since this is around codegen, we need to erase regions in both trait refs. But, I'd like to see what the two trait refs are.
is and is So... They're the same with , but inequal? I'm a little confused... So i switched to use , and they're a little different: is and is Complete diagnostics output:
This could "just" be fixed by anonymizing both trait refs.

The here is not the same as here . I have to remember how we deduplicate these predicates elsewhere.
Created for erasing regions before comparison. Let me know if there's a more proper approach, and i'll update the pr accordingly.
Anyone think this needs a backport?
Change:
} else { unsafe { self.len -= 1; <del> Some(ptr::read(self.get_unchecked(self.len()))) </del> <ins> Some(ptr::read(self.as_ptr().add(self.len()))) </ins> } } }

Discussion:
To my knowledge, the following code is intended to be legal: However, Miri currently flags this as UB. I believe this is , but for . Discovered while writing . cc
Yeah this looks pretty similar. uses under the hood though, so I wonder why the issue still exists here. Looks like is implemented via -- and indeed, this errors, too:
The problem is in this line: The here is a slice method, so this creates a slice covering the entire , which overlaps with the mutable reference created before and thus invalidates it.
It shouldn't be too hard to locally fix this, but that duplicates some code and there are some other uses of in . Ideally, this would all use raw slices to avoid making any uniqueness promises. But without , raw slices are not very useful.
Here's a possible fix:
Fix PR is up:
Change:
intravisit::walk_expr(self, ex); self.encode_info_for_expr(ex); } <ins> fn visit_anon_const(&mut self, c: &'tcx AnonConst) { intravisit::walk_anon_const(self, c); let def_id = self.tcx.hir().local_def_id(c.hir_id); self.record(def_id, EncodeContext::encode_info_for_anon_const, def_id); } </ins> fn visit_item(&mut self, item: &'tcx hir::Item) { intravisit::walk_item(self, item); let def_id = self.tcx.hir().local_def_id(item.hir_id);

Discussion:
In a folder , I have a blank library crate with the following : In a folder , I have a blank binary crate with the follow : 's uses crate with the following line: Running or in will produce the following ICE:
triage: P-high. Assigning to self for initial investigation. Removing I-nominated label. assigning as well, as someone who will likely resolve this faster than it will take me to build
Oh, given that this is using const generics (an unstable feature), it probably should be P-medium rather than P-high. I won't change the label yet, but if triage on thursday rolls around and I haven't seen a good reason to keep it P-high, I'll change the label then.
If downstream crates could ICE because they're using a type alias with const generics, even if they don't enable themselves, it seems like slightly more of an issue. (Sorry, I don't have time to look into this issue at the moment.)
It's not just type aliases, but also other constellations of cross-crate usage that are giving this ICE:
I continue to have the impression that if you use stable Rust, it will be used on all of your crates, and therefore you won't hit this bug. (don't get me wrong; I've commented elsewhere, rust-call bug in particular, where I do worry about impact on downstream crates from upstream crates using certain features that have bugs) But I still think this only warrants P-medium. Reclassifying as such.
Encountered this issue and documented it . The associated code is .
I just hit this issue as well in my project. Unfortunately I cannot share the code I'm hitting this with. A repro would look very similar to est31's example , but in my case the affected type isn't even exposed to the bin application. It's only. <details<summaryClick for stack</summary<p</p</details
Also when the type is wrapped privately (i.e., ) and exported like that, it seems to be triggered.
Change:
intravisit::walk_expr(self, ex); self.encode_info_for_expr(ex); } <ins> fn visit_anon_const(&mut self, c: &'tcx AnonConst) { intravisit::walk_anon_const(self, c); let def_id = self.tcx.hir().local_def_id(c.hir_id); self.record(def_id, EncodeContext::encode_info_for_anon_const, def_id); } </ins> fn visit_item(&mut self, item: &'tcx hir::Item) { intravisit::walk_item(self, item); let def_id = self.tcx.hir().local_def_id(item.hir_id);

Discussion:
Hey everybody :) I was trying to test matrix*vector in aljabar crate by running "cargo test" on: and got this: Not sure if it's a known issue or not but if there's anything else you need from me please let me know :)
version:
verbose trace:
It would help if you can reduce the problem to a minimal reproducer without the crate. (Also note that ICEs are common for .)
Not sure if i can manage that. Could be over my head.
there is a minimal example here:
Change:
os: "nuttx".into(), linker_flavor: LinkerFlavor::Gnu(Cc::No, Lld::Yes), linker: Some("rust-lld".into()), <del> llvm_abiname: "lp64d".into(), </del> cpu: "generic-rv64".into(), max_atomic_width: Some(64), features: "+m,+a,+c".into(),

Discussion:
When using I see which seems like an indicator that something is broken. I think LLVM is seeing a mismatch between and the lack of a in But of course I don't know this target, or whether this is somehow a bug in LLVM. cc
Thanks for your report, I'll submit a fix soon, the support (include libstd/libc) for NuttX is in early stage, there are still many issues at present, sorry for that
No need to apologize, just saying something because I saw something :)
Change:
/// N.B., **No cleanup is scheduled for this temporary.** You should /// call `schedule_drop` once the temporary is initialized. crate fn temp(&mut self, ty: Ty<'tcx>, span: Span) -> Place<'tcx> { <del> let temp = self.local_decls.push(LocalDecl::new(ty, span)); </del> <ins> // Mark this local as internal to avoid temporaries with types not present in the // user's code resulting in ICEs from the generator transform. let temp = self.local_decls.push(LocalDecl::new(ty, span).internal()); </ins> let place = Place::from(temp); debug!("temp: created temp {:?} with type {:?}", place, self.local_decls[temp].ty); place

Discussion:
Hey, This code attempts to increment a integer behind a tokio RwLock by 1, This causes a compiler error. Minimized example that reproduces the ICE: But, making this very small modification makes the code not break the compiler my contains as a dependency. This code does not compile, and generates the following error (full backtrace in bottom of the issue) rustc --version --verbose also breaks the same way on (the traces attached are from nightly ^) rustup run stable rustc --version -v
Confirmed this also breaks the same way on
MCVE: Fun fact: changing to doesn't ICE. Also I can't inline an instance into the function. It has to be created outside?!. Weird stuff somtimes. Also it would be nice to get rid of the deref, but I couldn't figure out how. So it's on this currently. Also worth mentioning: this needs . isn't sufficient. modify labels: -E-needs-mcve +E-needs-bisection
The bisection doesn't emit anything useful. This panics like forever. I went back to 2019-01-01 (with the old API and stuff) and it still ICEs there, so I guess it was like this forever. Feel free to add the tag again, but I'll remove it. modify labels: -E-needs-bisection
modify labels: -E-needs-bisection
Change:
LL | fn foo2<I: Foo>(x: I) { |         - similarly named type parameter `I` defined here LL |     let _: A = x.boo(); <del> |            ^ help: a type parameter with a similar name exists: `I` </del> <ins> |            ^ | help: a type parameter with a similar name exists | LL |     let _: I = x.boo(); |            ^ help: you might be missing a type parameter | LL | fn foo2<I: Foo, A>(x: I) { |               ^^^ </ins> error: aborting due to previous error

Discussion:
Rustc should know that is not in the right direction because that still wouldn't make a valid thing to write; type parameters can't have type parameters (yet??). Separately, should also have prevented the suggestion in this case, but is an independent issue. cc who worked on this recently in .
Change:
impl<T> Foo for Fooy<T> { type A<'a> where Self: 'static = (&'a ()); <del> //~^ ERROR the parameter type `T` may not live long enough </del> <ins> //~^ ERROR `impl` associated type </ins> type B<'a, 'b> where 'b: 'a = (&'a(), &'b ()); //~^ ERROR `impl` associated type //~| ERROR lifetime bound not satisfied

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 expected to see this happen: A slightly better error message Instead, this happened: A slightly confusing error message <!-- 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<summaryBacktrace</summary<p</p</details
Change:
extern crate test; #[cfg(test)] #[rustc_test_marker = "a_test"] <ins> #[doc(hidden)] </ins> pub const a_test: test::TestDescAndFn = test::TestDescAndFn { desc: test::TestDesc {

Discussion:
I tried this code: I expected to see this happen: no errors Instead, this happened: : Very likely to be related
Looks like allowed missing docs on the generated function, but didn't test having any actual s. cc
Attempt fix in
Change:
<ins> error[E0223]: ambiguous associated type --> $DIR/issue-109195.rs:2:5 | LL |     String::from::utf8; |     ^^^^^^^^^^^^ | help: there is an associated function with a similar name: `from_utf8` | LL |     String::from_utf8; |             ~~~~~~~~~ error[E0223]: ambiguous associated type --> $DIR/issue-109195.rs:5:5 | LL |     String::from::utf8(); |     ^^^^^^^^^^^^ | help: there is an associated function with a similar name: `from_utf8` | LL |     String::from_utf8(); |             ~~~~~~~~~ error[E0223]: ambiguous associated type --> $DIR/issue-109195.rs:8:5 | LL |     String::from::utf16(); |     ^^^^^^^^^^^^ | help: there is an associated function with a similar name: `from_utf16` | LL |     String::from_utf16(); |             ~~~~~~~~~~ error[E0223]: ambiguous associated type --> $DIR/issue-109195.rs:11:5 | LL |     String::from::method_that_doesnt_exist(); |     ^^^^^^^^^^^^ | help: if there were a trait named `Example` with associated type `from` implemented for `String`, you could use the fully-qualified path | LL |     <String as Example>::from::method_that_doesnt_exist(); |     ~~~~~~~~~~~~~~~~~~~~~~~~~ error[E0223]: ambiguous associated type --> $DIR/issue-109195.rs:14:5 | LL |     str::from::utf8(); |     ^^^^^^^^^ | help: if there were a trait named `Example` with associated type `from` implemented for `str`, you could use the fully-qualified path | LL |     <str as Example>::from::utf8(); |     ~~~~~~~~~~~~~~~~~~~~~~ error[E0223]: ambiguous associated type --> $DIR/issue-109195.rs:17:5 | LL |     str::from::utf8_mut(); |     ^^^^^^^^^ | help: if there were a trait named `Example` with associated type `from` implemented for `str`, you could use the fully-qualified path | LL |     <str as Example>::from::utf8_mut(); |     ~~~~~~~~~~~~~~~~~~~~~~ error: aborting due to 6 previous errors For more information about this error, try `rustc --explain E0223`. </ins>

Discussion:
` " ); } This had me VERY confused as I was certain I would try to get a String here, where does Example come from?? And associated types wut?? The problem is I used which should have been :D Maybe rustc could improve its suggestion somehow in that case? No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
For reference, here is a MRE:
claim
Change:
F64Value, StringValue, NullValue, SyntaxError, Key, Index, Stack, InvalidSyntax, InvalidNumber, EOFWhileParsingObject, EOFWhileParsingList, EOFWhileParsingValue, EOFWhileParsingString, KeyMustBeAString, ExpectedColon, <del> TrailingCharacters}; </del> <ins> TrailingCharacters, TrailingComma}; </ins> use std::{i64, u64, f32, f64, io}; use std::collections::TreeMap;

Discussion:
Gives me:
That's because JSON doesn't allow for a trailing comma, I'd imagine.
The specification is clearly wrong here and the decoder should accept trailing commas.
Well, that's not how standards work.
Not sure what you mean by that. I'm not saying that the encoder should produce trailing commas.
There is some precedence for not allowing trailing commas: Go, Chromium, and Firefox reject such json. The specification is still wrong for not allowing them and I see no reason not to parse them.
sad but true. Please feel free to close the issue then.
We could, however, have a better error message.
It shouldn't fail, since it returns a containing possible parse errors.