jiebi/CodeConvo huggingface dataset:
Change:
searchState.mouseMovedAfterSearch = false; document.title = searchState.title; }, <del> hideResults: () => { switchDisplayedElement(null); </del> <ins> removeQueryParameters: () => { // We change the document title. </ins> document.title = searchState.titleBeforeSearch; <del> // We also remove the query parameter from the URL. </del> if (browserSupportsHistoryApi()) { history.replaceState(null, "", getNakedUrl() + window.location.hash); } }, <ins> hideResults: () => { switchDisplayedElement(null); // We also remove the query parameter from the URL. searchState.removeQueryParameters(); }, </ins> getQueryStringParams: () => { const params = {}; window.location.search.substring(1).split("&").

Discussion:
Reproduction: Go to Click the gear next to the search field, enable "Directly go to item in search if there is only one result" Refresh page to ensure it's enabled (was required the first time I tried to reproduce, but seemed to work straight away the second time) Search for You should be taken straight to Press "Back" in your browser I expected this to happen: Go back to Instead, this happened: Goes back to then instantly redirects forward again
Taking a look.
Fixed in
Change:
RegionNameSource::AnonRegionFromYieldTy(span, type_name) => { diag.span_label(*span, format!("yield type is {type_name}")); } <ins> RegionNameSource::AnonRegionFromImplSignature(span, location) => { diag.span_label( *span, format!("lifetime `{self}` appears in the `impl`'s {location}"), ); } </ins> RegionNameSource::Static => {} } }

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details
Changing Self{field} to MyStruct{field} makes it build btw.
I haven't done a search for the exact commit, but on the playground this regressed between beta and nightly. label +regression-from-stable-to-nightly
This is due to the NLL stabilization PR , since it manifests with on 1.61 (with to allow feature flags). I'll be looking at it in a few hours when I get home!
Change:
&format!("`{}`", name), ), ( <ins> Some(ref name), BorrowExplanation::MustBeValidFor { category: category @ ConstraintCategory::OpaqueType, from_closure: false, ref region_name, span, .. }, ) if borrow_spans.for_generator() => self.report_escaping_closure_capture( borrow_spans.args_or_use(), borrow_span, region_name, category, span, &format!("`{}`", name), ), ( </ins> ref name, BorrowExplanation::MustBeValidFor { category: ConstraintCategory::Assignment,

Discussion:
emits the following error The correct code needs the to be part of the block because it is a stack allocation that needs to be in the generator: Ideally, the error message would mention : thanks to for bringing this up! CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We could also consider suggesting an block, similar to the hints we provide for closures.
Marking this as a focus item. assign
Change:
/// Creates a null mutable raw pointer. /// <ins> /// This function is equivalent to zero-initializing the pointer: /// `MaybeUninit::<*mut T>::zeroed().assume_init()`. /// The resulting pointer has the address 0. /// </ins> /// # Examples /// /// ```

Discussion:
This has come up in two places recently: and We should do the following: On , document that is equivalent to Either before or after it lands, update the text in to document that "allocated objects" cannot contain the 0 address (alternatively, if that PR lands with text that says that an allocated object cannot contain the "null" address, update the text to mention that null is equal to 0) Are there other places we should update too? cc
there was some discussion in https://rust-
Int-to-ptr casts are terrible, I'd rather not do that. In fact these two are not equivalent for Miri (but that might be a Miri limitation, int2ptr is just hard or impossible to handle precisely for a tool like Miri). We should say that it returns a pointer whose address is 0, but we shouldn't commit to which provenance it has.
adds the docs for this.
Change:
///   (1) all_constructors will only return constructors that are statically ///       possible. eg. it will only return Ok for Result<T, !> /// <del> /// Whether a vector `v` of patterns is 'useful' in relation to a set of such /// vectors `m` is defined as there being a set of inputs that will match `v` /// but not any of the sets in `m`. </del> <ins> /// This finds whether a (row) vector `v` of patterns is 'useful' in relation /// to a set of such vectors `m` - this is defined as there being a set of /// inputs that will match `v` but not any of the sets in `m`. /// /// All the patterns at each column of the `matrix ++ v` matrix must /// have the same type, except that wildcard (PatternKind::Wild) patterns /// with type TyErr are also allowed, even if the "type of the column" /// is not TyErr. That is used to represent private fields, as using their /// real type would assert that they are inhabited. </ins> /// /// This is used both for reachability checking (if a pattern isn't useful in /// relation to preceding patterns, it is not reachable) and exhaustiveness /// checking (if a wildcard pattern is useful in relation to a matrix, the /// matrix isn't exhaustive). pub fn is_useful<'p, 'a: 'p, 'tcx: 'a>(cx: &mut MatchCheckCtxt<'a, 'tcx>, <del> matrix: &Matrix<'p, 'tcx>, v: &[&'p Pattern<'tcx>], witness: WitnessPreference) -> Usefulness<'tcx> { </del> <ins> matrix: &Matrix<'p, 'tcx>, v: &[&'p Pattern<'tcx>], witness: WitnessPreference) -> Usefulness<'tcx> { </ins> let &Matrix(ref rows) = matrix; debug!("is_useful({:?}, {:?})", matrix, v);

Discussion:
the compiler unexpectedly panicked. this is a bug. I tried this code (hyper = "0.11.9"): I expected to see this happen: code compiles (two top branches are incompatible) Instead, this happened: compiler crashed; re-ordering two top branches fixes the issue : Backtrace:
Slightly simplified version (it's not valid Rust code -- not all patterns are covered -- but it crashes the compiler): Backtrace with debug logging from rustc (RUSTBACKTRACE=full RUSTLOG=rustcconsteval):
Minified:
Change:
found: e_count}), _ => ty::terr_mismatch }; <del> fcx.infcx().report_mismatched_types(pat.span, expected, actual, &type_error); </del> <ins> fcx.infcx().type_error_message_str_with_expected(pat.span, |expected, actual| { expected.map_default(~"", |&e| { fmt!("mismatched types: expected `%s` but found %s", e, actual)})}, Some(expected), ~"tuple", Some(&type_error)); </ins> fcx.write_error(pat.id); } }

Discussion:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in
Change:
ret } <del> pub fn cat_downcast<N:ast_node>(&self, node: &N, base_cmt: cmt<'tcx>, downcast_ty: Ty<'tcx>, variant_did: DefId) -> cmt<'tcx> { let ret = Rc::new(cmt_ { id: node.id(), span: node.span(), mutbl: base_cmt.mutbl.inherit(), cat: Categorization::Downcast(base_cmt, variant_did), ty: downcast_ty, note: NoteNone }); debug!("cat_downcast ret={:?}", ret); ret </del> <ins> pub fn cat_downcast_if_needed<N:ast_node>(&self, node: &N, base_cmt: cmt<'tcx>, variant_did: DefId) -> cmt<'tcx> { // univariant enums do not need downcasts let base_did = self.tcx.parent_def_id(variant_did).unwrap(); if !self.tcx.adt_def(base_did).is_univariant() { let base_ty = base_cmt.ty; let ret = Rc::new(cmt_ { id: node.id(), span: node.span(), mutbl: base_cmt.mutbl.inherit(), cat: Categorization::Downcast(base_cmt, variant_did), ty: base_ty, note: NoteNone }); debug!("cat_downcast ret={:?}", ret); ret } else { debug!("cat_downcast univariant={:?}", base_cmt); base_cmt } </ins> } pub fn cat_pattern<F>(&self, cmt: cmt<'tcx>, pat: &hir::Pat, mut op: F) -> McResult<()>

Discussion:
I got panic with this code (): Backtrace: My rust version:
This code seems to be minimal example type Value = String; fn main() { let f = ""; Some("".into()).map(f); }
Change:
use syntax::visit; use syntax::symbol::keywords; use syntax::symbol::Symbol; <ins> use syntax::parse::token::{self, Token}; </ins> use hir::map::{ITEM_LIKE_SPACE, REGULAR_SPACE};

Discussion:
This issue probably needs a better title, perhaps someone more familiar with the compiler's handling of macros can suggest a better one. Some kind of error message, at least. panic with exit code :
Simplified: Same ICE will happen if is changed to ///. Update: Panic happens at this line: has keys and , but the is .
Change:
use middle::subst::Substs; use middle::traits::{Obligation, SelectionContext}; use metadata::{csearch, cstore, decoder}; <ins> use util::nodemap::{FnvHashSet}; </ins> use syntax::ast; use syntax::codemap::Span;

Discussion:
Updated 10/21: is currently valid Rust. I don't know if it should be, but it causes the compiler to blow its stack when recursively traversing a crate which contains it. To reproduce: Create a lib crate with this body: (compiles fine)Link to this crate, then include code that results in a method missing error, such as: This will cause the stack to overflow in while it looks up traits in linked crates that define a method . There are probably other functions which overflow like this in the case of this text. I would think either should be smart enough to not recursively include the self module or should be an error.
It would be easier to debug this problem if we would have source code that causes it (e.g. for ).
I did some debugging, found the issue, and have updated the title and top comment to explain it clearly, including steps to reproduce. Fortunately, the practical fix is easy (don't use ).
Change:
fn parse_field_ident(&mut self, adt_ty: &str, lo: Span) -> PResult<'a, Ident> { let (ident, is_raw) = self.ident_or_err()?; if !is_raw && ident.is_reserved() { <ins> let snapshot = self.create_snapshot_for_diagnostic(); </ins> let err = if self.check_fn_front_matter(false) { let inherited_vis = Visibility { span: rustc_span::DUMMY_SP,

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 include a note informing the user that the declaration of another struct within a struct is not allowed and they should use separate declarations. (Wording might need a bit of tweaking). <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label D-terse
claim
Change:
} return None; } <del> if let Ok(code) = sm.span_to_snippet(expr.span) { return Some(( sp, "consider removing the borrow", code, Applicability::MachineApplicable, )); </del> <ins> if sp.contains(expr.span) { if let Ok(code) = sm.span_to_snippet(expr.span) { return Some(( sp, "consider removing the borrow", code, Applicability::MachineApplicable, )); } </ins> } } (

Discussion:
The tokens generated by procmacro (e.g. from ) use , which makes some suggestions produce invalid output: It's a bit tricky, because this callsite span does point into the current crate (to ), so this situaiton isn't detected in the same way as external .
Looks like should be used in more places. That one detects this span by checking if is a dummy or imported.
I'm working on a fix specifically for these typeck/borrowing suggestions. Not sure how many other suggestions have the same problem.
this is a prevalent problem. We need to add metadata to spans to distinguish call sites explicitly in an easy way and always ignore suggestions in them.
Change:
<ins> //@ check-pass #![warn(unused_imports)] mod foo { use std::fmt; pub struct String; impl String { pub fn new() -> String { String{} } } impl fmt::Display for String { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!(f, "String") } } } fn main() { { use std::string::String; //~ WARNING the item `String` is imported redundantly // 'String' from 'std::string::String'. let s = String::new(); println!("{}", s); } { // 'String' from 'std::string::String'. let s = String::new(); println!("{}", s); } { use foo::*; // 'String' from 'foo::String'. let s = String::new(); println!("{}", s); } } </ins>

Discussion:
This (very contrived) example emits a warning: Playground: This is a false positive because removing results in a compilation error: Same for and .
It seems this regressed somewhere between 1.34.0 and 1.35.0
More accurately, it looks like the false positive has been present since the introduction of the warning in
I was actually a little surprised that did not cause a compilation error due to two imports of the same name at the same level.
I got something similar while implementing ops::Div when removed, it errors
This issue no longer reproduces and can be closed when a corresponding test is .
Change:
<ins> // unit-test: DataflowConstProp // compile-flags: -Zmir-enable-passes=+ConstProp,+Inline // ignore-debug assertions change the output MIR // EMIT_MIR_FOR_EACH_BIT_WIDTH // EMIT_MIR_FOR_EACH_PANIC_STRATEGY struct A { foo: Box<[bool]>, } // EMIT_MIR default_boxed_slice.main.ConstProp.diff // EMIT_MIR default_boxed_slice.main.DataflowConstProp.diff fn main() { // ConstProp will create a constant of type `Box<[bool]>`. // Verify that `DataflowConstProp` does not ICE trying to dereference it directly. let a: A = A { foo: Box::default() }; } </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
cc
Change:
SrcLayoutUnknown, /// The layout of dst is unknown DstLayoutUnknown, <ins> /// The size of src is overflow SrcSizeOverflow, /// The size of dst is overflow DstSizeOverflow, </ins> } #[cfg(feature = "rustc")]

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
Crashes since 1.65.0.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
// gdb-check:$1 = Vec(size=1000000000) = {[...]...} // gdb-command: print slice <del> // gdb-check:$2 = &[u8] {data_ptr: [...], length: 1000000000} </del> <ins> // gdb-check:$2 = &[u8](size=1000000000) = {[...]...} </ins> #![allow(unused_variables)]

Discussion:
Currently, support for pretty-printing slice types is missing for rust-gdb.
Can you describe in more detail?
provides pretty-printing function for some Rust types, such as , , , etc. This allows gdb to display values of some types in a more readable way. I think it is implemented in the following files: , , Currently, slices can only be displayed as a pointer and a length value in the debugger. I hope rust-gdb can support displaying slices. I also noticed that already supports pretty-printing const slices (), but not mutable slices (). Maybe rust-lldb can also add pretty-printing support fur mutable slices.
label A-slice C-enhancement T-dev-tools
Change:
// Create an infcx, taking the predicates of impl1 as assumptions: tcx.infer_ctxt().enter(|infcx| { <del> // Normalize the trait reference. The WF rules ought to ensure // that this always succeeds. </del> let impl1_trait_ref = match traits::fully_normalize( &infcx, FulfillmentContext::new(),

Discussion:
The following code () produces
Triage: still ICEs
This ICEs since modify labels: +regression-from-stable-to-stable
Change:
<ins> error: this file contains an unclosed delimiter --> $DIR/issue-103451.rs:5:15 | LL | struct S { |          - unclosed delimiter LL |     x: [u8; R |        -      ^ |        | |        unclosed delimiter error: this file contains an unclosed delimiter --> $DIR/issue-103451.rs:5:15 | LL | struct S { |          - unclosed delimiter LL |     x: [u8; R |        -      ^ |        | |        unclosed delimiter error[E0423]: expected value, found struct `R` --> $DIR/issue-103451.rs:5:13 | LL | struct R { } | ------------ `R` defined here LL | struct S { LL |     x: [u8; R |             ^ help: use struct literal syntax instead: `R {}` error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0423`. </ins>

Discussion:
This malformed code () hangs the compiler: Found by fuzzing with a . must be defined as a named-field struct (not a tuple struct or unit struct), although it can have 0 fields. must be the last token to produce the hang: No opening brace (note that braces are required for literals of named-field structs) No closing delimiters Not even a comment If I understand correctly, the hang occurs in LateResolutionVisitor, with never finishing (while calling various functions such as and ) This also hangs. I'm guessing it's the same bug. : with: <details</summary<p</p</detailsregressed nightly: nightly-2022-10-21 regressed commit: (PR ) label +regression-from-stable-to-nightly +I-hang <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
I can not reproduce it with latest code, did I missed anything?
Great cactch Confirmed the error is only triggered by commit: The root cause is I changed the edge corner case in : We think won't return a span which outside of source file, so is a valid one, then will always return a valid span, and we get from when reaching the end of source. So, there is a loop in previous , which will run infinitely loop: Lucky, my another PR merged at last day, this PR refactored this function:
Verif, I no longer get a hang after rollup Do you want to add one or two of these as tests?
Yes, we'd better add a testcase for it. I'm thinking whether we sould in when reaching to the end of source, so that may get an error.
This testcase seems not easy to be : If so, the trigger point will do not exist,
label -I-prioritize
There's an alternative kind of annotation for patterns that should work for this case:
Change:
error[E0618]: expected function, found `(char, char)` --> $DIR/issue-5100.rs:48:14 | <del> LL |       let v = [('a', 'b') |  ______________-^^^^^^^^^ LL | |              ('c', 'd'), | |_______________________- call expression requires function </del> <ins> LL |     let v = [('a', 'b') |              ^^^^^^^^^^- help: consider separating array elements with a comma: `,` </ins> error[E0308]: mismatched types --> $DIR/issue-5100.rs:55:19

Discussion:
Given the following code (): The current output is: <!-- The following is not always necessary. --Ideally the output should look like: and the compiler would preview the fix, by adding the commas in green. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This week I'm busier than I thought ;) release-assignment
label +A-parser
claim
Change:
_ => None } } <ins> /// Returns the sixteen eight-bit integers the IPv6 address consists of. #[unstable(feature = "ipv6_to_octets", reason = "needs some testing", issue = "32313")] pub fn octets(&self) -> [u8; 16] { self.inner.s6_addr } </ins> } #[stable(feature = "rust1", since = "1.0.0")]

Discussion:
Tracking issue for First needs to be implemented, then go through an FCP! Looks like the is being implemented over at
This issue is now entering a cycle-long final comment period for stabilization
Discussed recently, the libs team decided to stabilize.
Change:
pub nocapture: bool, pub color: ColorConfig, pub quiet: bool, <ins> pub test_threads: Option<usize>, </ins> } impl TestOpts {

Discussion:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.
Change:
--> $DIR/numeric-cast.rs:184:16 | LL |     foo::<i16>(x_u8); <del> |                ^^^^ expected `i16`, found `u8` | help: you can convert an `u8` to `i16` and panic if the converted value wouldn't fit | LL |     foo::<i16>(x_u8.try_into().unwrap()); |                ^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> |                ^^^^ |                | |                expected `i16`, found `u8` |                help: you can convert an `u8` to `i16`: `x_u8.into()` </ins> error[E0308]: mismatched types --> $DIR/numeric-cast.rs:186:16

Discussion:
() Errors: I would’ve expected something like: Edit: What actually should happen is the same as currently already with , i.e. it would look like modify labels: A-diagnostics, T-compiler, D-papercut, C-enhancement, E-easy <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Okay, lots of cases that already work got me confused into thinking this was fixed in nightly for a moment. What currently already works is the hint about converting where < where < What currently suggest even though works where < where ≤16 where ≤16
I reported a similar issue not long ago. Maybe it would be more robust and also more general to rewrite this suggestion code to actually look for the impl in question instead of having just a hard-coded list?
claim
I've created a PR augmenting the existing code to change the suggestions for the cases listed. However, I would like to explore the approach suggested(perhaps as part of a separate PR?). Any advice on how I could get the code to look for the impl so it can make the appropriate suggestion? Is the crate the right place to be looking at for this?
Yeah. I believe you'll need to create an and and then call , but there might be other/better ways to do this. You might want to ask for advice on Zulip.