jiebi/CodeConvo huggingface dataset:
Change:
// want to keep their span info to improve diagnostics in these cases in a later stage. (true, Some(AssocOp::Multiply)) | // `{ 42 } *foo = bar;` or `{ 42 } * 3` (true, Some(AssocOp::Subtract)) | // `{ 42 } -5` <del> (true, Some(AssocOp::LAnd)) | // `{ 42 } &&x` (#61475) </del> (true, Some(AssocOp::Add)) // `{ 42 } + 42 // If the next token is a keyword, then the tokens above *are* unambiguously incorrect: // `if x { a } else { b } && if y { c } else { d }` <del> if !self.look_ahead(1, |t| t.is_reserved_ident()) => { </del> <ins> if !self.look_ahead(1, |t| t.is_used_keyword()) => { // These cases are ambiguous and can't be identified in the parser alone. let sp = self.sess.source_map().start_point(self.token.span); self.sess.ambiguous_block_expr_parse.borrow_mut().insert(sp, lhs.span); false } (true, Some(AssocOp::LAnd)) => { // `{ 42 } &&x` (#61475) or `{ 42 } && if x { 1 } else { 0 }`. Separated from the // above due to #74233. </ins> // These cases are ambiguous and can't be identified in the parser alone. let sp = self.sess.source_map().start_point(self.token.span); self.sess.ambiguous_block_expr_parse.borrow_mut().insert(sp, lhs.span);

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:
error: aborting due to 3 previous errors <del> For more information about this error, try `rustc --explain E0577`. </del> <ins> For more information about this error, try `rustc --explain E0433`. </ins>

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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
glacier ""
searched nightlies: from nightly-2022-10-05 to nightly-2023-03-16 regressed nightly: nightly-2022-10-12 searched commit range: regressed commit:
Newer version of cargo-bisect-rustc can bisect through rollups
The one that is not released yet? :smile: Thx, will install git then.. :)
label +S-bug-has-mcve
Change:
Erroneous code example: ```compile_fail,E0577,edition2018 <del> pub struct Sea; </del> <ins> pub enum Sea {} </ins> pub (in crate::Sea) struct Shark; // error!

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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
glacier ""
searched nightlies: from nightly-2022-10-05 to nightly-2023-03-16 regressed nightly: nightly-2022-10-12 searched commit range: regressed commit:
Newer version of cargo-bisect-rustc can bisect through rollups
The one that is not released yet? :smile: Thx, will install git then.. :)
label +S-bug-has-mcve
Change:
LL |         assert_eq!(0, 0); |         ^^^^^^^^^^^^^^^^^ | <ins> = note: consider importing one of these items: core::panic std::panic </ins> = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error[E0433]: failed to resolve: use of undeclared type `Vec`

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: compiler should suggest importing from (it is in ). Instead, this happened: compiler say cannot find macro 'Component' but did not suggest importing it like other functions <!-- 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. --: Also not available in stable.
Change:
} #[test] <ins> fn test_from_str() { assert_eq!(char::from_str("a").unwrap(), 'a'); assert_eq!(char::try_from("a").unwrap(), 'a'); assert_eq!(char::from_str("0").unwrap(), '0'); assert_eq!(char::from_str("u{D7FF}").unwrap(), 'u{d7FF}'); assert!(char::from_str("").is_err()); assert!(char::from_str("abc").is_err()); } #[test] </ins> fn test_is_lowercase() { assert!('a'.is_lowercase()); assert!('ö'.is_lowercase());

Discussion:
I'm not sure if this is an oversight. But the implementation should be trivial. I'll add tests and implement it, if it is fine.
Strings aren't indexable and .len() doesn't count the number of chars. :smile: What comes to mind first is an iterator inspecting the two first chars:
xD I didn't test my code, but you get the gist. I had a impl at first, but then edited it
cc
Triage: this has not been .
PRs welcome!
I can take this. I was also thinking of adding a impl for , but unsure if it would be better to wait for to get closer to stabilization and use that instead of adding another empty enum to std
wait, that wouldn't work bc of lifetime issues regardless, right? :(
Change:
return; } <ins> // If the method is an impl for an item with docs_hidden, don't doc. if method_context(cx, impl_item.hir_id()) == MethodLateContext::PlainImpl { let parent = cx.tcx.hir().get_parent_did(impl_item.hir_id()); let impl_ty = cx.tcx.type_of(parent); let outerdef = match impl_ty.kind() { ty::Adt(def, _) => Some(def.did), ty::Foreign(def_id) => Some(*def_id), _ => None, }; let is_hidden = match outerdef { Some(id) => cx.tcx.is_doc_hidden(id), None => false, }; if is_hidden { return; } } </ins> let (article, desc) = cx.tcx.article_and_description(impl_item.def_id.to_def_id()); self.check_missing_docs_attrs(cx, impl_item.def_id, impl_item.span, article, desc); }

Discussion:
I tried : I expected to see this happen: no warnings, and its method are not publicly documented. Instead, this happened: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Looks like the context here could give us the information needed to determine 1) if the item is an associated function definition, and 2) if the type on which it is implemented itself has the attribute.
Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. enum Enum { Var1, Var2, } fn main() { use Enum::*; let s = Var1; match s { Var1 => (), Var3 => (), //~^ NOTE this pattern matches any value Var2 => (), //~^ ERROR unreachable pattern }; match &s { &Var1 => (), &Var3 => (), //~^ NOTE this pattern matches any value &Var2 => (), //~^ ERROR unreachable pattern }; let t = (Var1, Var1); match t { (Var1, b) => (), (c, d) => (), //~^ NOTE this pattern matches any value anything => () //~^ ERROR unreachable pattern }; // `_` need not emit a note, it is pretty obvious already. let t = (Var1, Var1); match t { (Var1, b) => (), _ => (), anything => () //~^ ERROR unreachable pattern }; } </ins>

Discussion:
This simple code fails to compile because is not defined. But the error message is . But is not the cause it just happens to occur after .
I agree that this is confusing, though from the compiler's perspective, the error message makes sense. Since isn't a variant of , becomes the name of a binding that matches all possible values of other than . (See ) Once that happens, the case is indeed unreachable.
Perhaps the error message could point to the match arm that the unreachable arm overlaps with.
Also if you comment out the Bar arm, you get a snake-case warning on Other, but unfortunately the error happens first.
Thanks for your coments. Now at least I understand why the compiler printed this error message.
Related:
Change:
#[stable(feature = "rust1", since = "1.0.0")] #[allow(deprecated)] <del> impl<A: Step + One> Iterator for ops::RangeFrom<A> { </del> <ins> impl<A: Step + One> Iterator for ops::RangeFrom<A> where for<'a> &'a A: Add<&'a A, Output = A> { </ins> type Item = A; #[inline] fn next(&mut self) -> Option<A> { <del> self.start.step(&A::one()).map(|mut n| { mem::swap(&mut n, &mut self.start); n }) </del> <ins> let mut n = &self.start + &A::one(); mem::swap(&mut n, &mut self.start); Some(n) </ins> } }

Discussion:
I tried printing all valid s by doing and was surprised to find it only printed up to 254. I'm unsure if this is supposed to be this way ( can be used). If so, I'd propose adding this to the Iterators/Ranges section of the book.
The problem is the next method of RangeFrom: It returns the previous value, then updates itself to store the next one. The value 255 ends up being the value that represents a "done" state, so it can't return it. I can't think of any solution that doesn't involve adding a flag to RangeFrom.
Or impl IntoIter instead of Iterator (and use a helper struct to keep track of the range).
Seems similar to .
Question: What is the origin of this Rust behavior, or what is its justification? e.g.: Why an exclusive upper bound on ranges? This caught me by total surprise, coming from Haskell, and I don't know if any Rust I've written for my own cases is wrong now. It behaves differently from similar syntax in Haskell, Swift, and Go, so I'm wondering if it's fruitful to have behavior different from peer languages (in trying to attract people away from languages where syntax like this does not exist.)
Ruby has both exclusive and inclusive ranges
The origin is related to the for-loop idiom in C. corresponds to the range. It has some nice properties such as how it iterates over exactly elements, whereas an inclusive range does and would require you to say, for example, for the indices of a vector if were inclusive. Essentially, it seems like the exclusive behaviour is useful more often than inclusive in a systems language.
Exclusive behaviour is also a leaner implementation. For inclusive behaviour you need some kind of flag for "now yield the inclusive element". This issue is an exact example of why: How do you statefully write an iterator from to , inclusive?
cc , which adjusts this behavior by triggering an overflow on non-wrapped-arithmetic types; it makes the semantics equivalent to repeatedly updating .
so just to be clear, with the above PR merged, now panics. Is this the intended behavior?
Change:
break; } <del> match serde_json::from_str(&line) { </del> <ins> match serde_json::from_slice(&line) { </ins> Ok(parsed) => self.render_message(parsed), Err(_err) => { // Handle non-JSON output, for example when --nocapture is passed. <del> print!("{line}"); let _ = std::io::stdout().flush(); </del> <ins> let mut stdout = std::io::stdout(); stdout.write_all(&line).unwrap(); let _ = stdout.flush(); </ins> } } }

Discussion:
(Sorry if this isn't the right template, I wasn't sure what to choose) Hi, when I run tests with x.py from the command I get this error .
can you add some more context? there should be output printed before this panic, what does it say? what commit are you testing?
I'd like to contribute to Rust so I'm first trying to understand and try the tests from x.py, I haven't made any changes, I just cloned the repo then did an x.py setup then this command . Here is what I get from this command:
ok, great! now we need to find which of the tests are causing the "Microsoft Windows [version 10.0..1778]" output - can you run and print the ~20 or so lines before the panic?
hmm, that doesn't show the test that panicked. try adding ?
still the same thing, earlier today I had a theory, I thought it had nothing to do with tests but more a story of utf-8 and console
right, I understand it's still panicking, but I'm trying to find what's causing it to panic. alternatively, you could try making this change to bootstrap to have it print the thing it couldn't parse: you can paste that into and it should make the change for you.
I'm not sure what to copy, is that enough?
is that with ? I'm trying to find which of the tests are emitting this output, not just the output itself. If you could paste the 20 or so lines before in addition to this version output it would be very helpful.
It's with this line, but I don't know where to start copying the 20 lines, I don't have any more crashes?
I started from the last line where I was
hmm, this runs on windows, maybe that's printing the version notice?
can you post the output of ?
hmm ok, but you don't see the "Microsoft Windows [version 10.0..1778]" from ? it might be a different test that's making bootstrap panic then. cc do you have ideas what could be going wrong here? is using a french locale and that's making one of the tests emit non-utf8 on Windows for some reason.

When I launch a terminal, I get "Microsoft Windows...", but with the command I don't get "Microsoft Windows..."
I set my computer to English, I deleted the changes from earlier and I no longer have the problem.
Setting the environment variable to should work if the Visual Studio English language pack is installed. I believe rustc itself sets this. I did recently add some code to rustc to attempt to re-encode as UTF-8 if the output is not UTF-8 but this only triggers for linker output. Perhaps other tools may also want the same treatment but I've not investigated.
Oh sorry, just read that again. This is caused by cmd when used with ? Hm, strange. I'm not sure off-hand. Using should switch to the UTF-8 code page. But I'm unsure of the cause so I don't know if that would help in this case.
Change:
self.bump(); // `(` let path = self.parse_path(PathStyle::Mod)?; // `crate`/`super`/`self` self.expect(&token::CloseDelim(Delimiter::Parenthesis))?; // `)` <del> let vis = VisibilityKind::Restricted { path: P(path), id: ast::DUMMY_NODE_ID }; </del> <ins> let vis = VisibilityKind::Restricted { path: P(path), id: ast::DUMMY_NODE_ID, shorthand: true, }; </ins> return Ok(Visibility { span: lo.to(self.prev_token.span), kind: vis,

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: it to print . Instead, this happened: it prints . <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.62.1 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-beta -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Similar effect can already be observed on stable too prints already. But it is indeed a (small?) behavior change in this beta for the case.
I would expect to see this issue in 2020, but not now when we are collecting tokens in (almost) all cases instead of converting them from AST. Apparently for visibilities they are collected incorrectly for some reason. cc (in case you have time for this)
bisection points to searched nightlies: from nightly-2022-01-01 to nightly-2022-08-03 regressed nightly: nightly-2022-05-24 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsThe commit is a rollup so I think_ it's in cc ?
Without even looking at the rest of the rollup, it's definitely my PR. Short of storing whether was used, I'm not sure what could be done.
This will slip into 1.63.

I'll work on this this evening to get it resolved quickly, even if it is too late to patch the beta. I don't think it'll be too difficult.
PR is up: . This also fixes to be , which is certainly better than the status quo of .
Change:
<ins> // Copyright 2013 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // xfail-test use std::hashmap::HashMap; trait Graph<Node, Edge> { fn f(&self, Edge); } impl<E> Graph<int, E> for HashMap<int, int> { fn f(&self, _e: E) { fail!(); } } fn main() { let g : ~HashMap<int, int> = ~HashMap::new(); let _g2 : ~Graph<int,int> = g as ~Graph<int,int>; } </ins>

Discussion:
I got this stacktrace while running "rust test" on a file. The end of the trace contains a failure message. I have an archlinux 64bits, with rust-0.6-3 (compiled on april 6th, 2013). The code is at the bottom of the page. code:
It seems you are using an old version of rust (based on your use of LinearMap, which has since been renamed to HashMap). Does this crash also happen on incoming?
Looks like my computer is not powerful enough to build rust from ...
I tested with master () And I get the same problem
Simpler test case: Reproduced with . Nominating for milestone 5, production-ready.
accepted for production-ready milestone
I don't get ICE anymore.
Hurrah! flagging as needstest, but this probably just needs the test case un-xfail'd
The test was actually already checked in and was un-xfail'd in
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let x = ~1; let f: proc() = proc() { let _a = x; drop(x); //~^ ERROR: use of moved value: `x` }; f(); } </ins>

Discussion:
compiles . Runs . Connection refused and segfault.
This is a bug in the treatment of captured variables. The line in question is: This is moving into the loop repeatedly when you should only be allowed to do it once. I think I've seen this bug before, but just in case, cc
thanks I've seen some reports of bugs like this before -- it's clear that we need to revisit the code used to check "once fns" -- it was as a temporary start towards support (under a -Z flag) and then pressed into full service, clearly not quite ready for prime time.
Nominating.
updated title to reflect the real issue at hand.
cc
Assigning 1.0, max(P-backcompat-lang, P-high). Gotta fix. edit: The use of above is sort of a joke: take the max of the two P-tag inputs. (Also, I originally wrote P-backcompat-libs, but I'm pretty sure that was a typo.)
Change:
let x = "x"; //~ ERROR cannot find value `x` in this scope println!("x: {}", x); //~ ERROR cannot find value `x` in this scope <ins> let some_variable = 6; //~ cannot find value `let_some_variable` in this scope println!("some_variable: {}", some_variable); //~ ERROR cannot find value `some_variable` in this scope let other_variable = 6; //~ cannot find value `letother_variable` in this scope println!("other_variable: {}", other_variable); //~ ERROR cannot find value `other_variable` in this scope </ins> if x == "x" { //~^ ERROR cannot find value `x` in this scope println!("x is 1");

Discussion:
I accidentally typoed an underscore instead of a space between and the name of the new variable I was trying to declare. If a binding isn't found, and it starts with (or frankly , if you forget/miss the space completely), it seems like it would be more likely to suggest ( plus a space) rather than the current suggestion of an additional . No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
interesting, I'd like to have a try. but might not solve it quicklly casuze I am new to rustc
sounds good! feel free to ask for help if you need it, but the implementation should be fairly simple. assign
Change:
if !features.is_empty() { cargo.arg("--features").arg(&features.join(", ")); } <ins> // Enable internal lints for clippy and rustdoc // NOTE: this doesn't enable lints for any other tools unless they explicitly add `#![warn(rustc::internal)]` // See https://github.com/rust-lang/rust/pull/80573#issuecomment-754010776 // // NOTE: We unconditionally set this here to avoid recompiling tools between `x check $tool` // and `x test $tool` executions. // See https://github.com/rust-lang/rust/issues/116538 cargo.rustflag("-Zunstable-options"); </ins> cargo }

Discussion:
When working on Miri I noticed "portable-atomics" gets rebuilt every time I switch between a check-build and actutally running tests. This boils down to being different between the two invocations: in check builds it contains but in test builds it does not. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Cc
HEAD: ! Seems working fine here.
I'll have to try if I can till reproduce. But note that I mentioned "test build" above, so this would be vs .
Yeah I can still reproduce the problems with those invocations. (It's not the latest master but recent enough: .) Sorry for not giving the exact commands in the issue description.
I missed the tests part, sorry. I just reproduce it too. I will be working on it by the coming week. claim
Change:
// have to support that case (mostly by skipping all caching). match frame.locals.get(local).and_then(|state| state.layout.get()) { None => { <del> let layout = from_known_layout(layout, || { </del> <ins> let layout = from_known_layout(self.tcx.tcx, layout, || { </ins> let local_ty = frame.body.local_decls[local].ty; let local_ty = self.subst_from_frame_and_normalize_erasing_regions(frame, local_ty);

Discussion:
The following ICEs (example by shows This means that is wrong. It might be possible to also trigger this without nightly features through const_prop.
Baring a way to do the proper structural subtyping check, the only solution I see is to go back to comparing layouts in all cases (as a fallback after types mismatch) -- but does not like this, as far as I recall. Any other proposals?