jiebi/CodeConvo huggingface dataset:
Code change:
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

Related discussion:
text: 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); } }
Code change:
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

Related discussion:
text: for after.each |&elt| { check_pat(pcx, elt, ty::mk_err()); } <del> let resolved_expected = fcx.infcx().ty_to_str(fcx.infcx().resolve_type_vars_if_possible(expected)); fcx.infcx().type_error_message_str(pat.span, |actual| { fmt!("mismatched types: expected `%s` but found %s", resolved_expected, actual)}, ~"a vector pattern", None); </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), ~"a vector pattern", None); </ins> fcx.write_error(pat.id); return; }
Code change:
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

Related discussion:
text: } _ => { check_pat(pcx, inner, ty::mk_err()); <del> let resolved_expected = fcx.infcx().ty_to_str(fcx.infcx().resolve_type_vars_if_possible(expected)); fcx.infcx().type_error_message_str(span, |actual| { fmt!("mismatched types: expected `%s` but found %s", resolved_expected, actual)}, fmt!("%s pattern", match pointer_kind { Managed => "an @-box", Owned => "a ~-box", Borrowed => "an &-pointer" }), None); </del> <ins> fcx.infcx().type_error_message_str_with_expected( span, |expected, actual| { expected.map_default(~"", |&e| { fmt!("mismatched types: expected `%s` but found %s", e, actual)})}, Some(expected), fmt!("%s pattern", match pointer_kind { Managed => "an @-box", Owned => "a ~-box", Borrowed => "an &-pointer" }), None); </ins> fcx.write_error(pat_id); } }
Code change:
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

Related discussion:
text: } } <ins> fn type_error_message_str(@mut self, sp: span, mk_msg: &fn(Option<~str>, ~str) -> ~str, actual_ty: ~str, err: Option<&ty::type_err>) { self.type_error_message_str_with_expected(sp, mk_msg, None, actual_ty, err) } fn type_error_message_str_with_expected(@mut self, sp: span, mk_msg: &fn(Option<~str>, ~str) -> ~str, expected_ty: Option<ty::t>, actual_ty: ~str, err: Option<&ty::type_err>) { debug!("hi! expected_ty = %?, actual_ty = %s", expected_ty, actual_ty); </ins> <del> fn type_error_message_str(@mut self, sp: span, mk_msg: &fn(~str) -> ~str, actual_ty: ~str, err: Option<&ty::type_err>) { </del> let error_str = err.map_default(~"", |t_err| fmt!(" (%s)", ty::type_err_to_str(self.tcx, *t_err))); <del> self.tcx.sess.span_err(sp, fmt!("%s%s", mk_msg(actual_ty), error_str)); for err.each |err| { ty::note_and_explain_type_err(self.tcx, *err) </del> <ins> let resolved_expected = expected_ty.map(|&e_ty| { self.resolve_type_vars_if_possible(e_ty) }); if !resolved_expected.map_default(false, |&e| { ty::type_is_error(e) }) { match resolved_expected { None => self.tcx.sess.span_err(sp, fmt!("%s%s", mk_msg(None, actual_ty), error_str)), Some(e) => { self.tcx.sess.span_err(sp, fmt!("%s%s", mk_msg(Some(self.ty_to_str(e)), actual_ty), error_str)); } } for err.each |err| { ty::note_and_explain_type_err(self.tcx, *err) } </ins> } } <del> fn type_error_message(@mut self, sp: span, mk_msg: &fn(~str) -> ~str, actual_ty: ty::t, err: Option<&ty::type_err>) { </del> <ins> fn type_error_message(@mut self, sp: span, mk_msg: &fn(~str) -> ~str, actual_ty: ty::t, err: Option<&ty::type_err>) { </ins> let actual_ty = self.resolve_type_vars_if_possible(actual_ty); // Don't report an error if actual type is ty_err.
Code change:
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

Related discussion:
text: return; } <del> self.type_error_message_str(sp, mk_msg, self.ty_to_str(actual_ty), err); </del> <ins> self.type_error_message_str(sp, |_e, a| { mk_msg(a) }, self.ty_to_str(actual_ty), err); </ins> } fn report_mismatched_types(@mut self, sp: span, e: ty::t, a: ty::t,
Code change:
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

Related discussion:
text: } match (true, false) { <del> (true, false, false) => () //~ ERROR mismatched types: expected `(bool,bool)` but found `(bool,bool,bool)` (expected a tuple with 2 elements but found one with 3 elements) </del> <ins> (true, false, false) => () //~ ERROR mismatched types: expected `(bool,bool)` but found tuple (expected a tuple with 2 elements but found one with 3 elements) </ins> } match (true, false) {
Code change:
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

Related discussion:
text: <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. fn main() { let (x, y) = (); //~ ERROR expected `()` but found tuple (types differ) return x; } </ins>  No newline at end of file
Code change:
libcore however doesn't use those for the implementations for and for the unit type. This means that the special case in cg_ssa can be removed.
Hi I'd like to work on this. Would be a good initial contribution to Rust :)
I'm really new to the code base, though. Could you clarify what the means above?
That's , a part of the code generation code in rustc. The code in the first snippet is located there.
Thanks for clarifying that! I'll go through the code and post any questions here.
Would love to help but don't know where to start. If mentoring is still possible please ping me or send me in the right direction somehow .
or maybe if your up to the task :)
I think you just need to look at and remove the check for that was mentioned. You can check https://rust- for an overview of the compiler and instruction on how to build it and run tests.
Thanks seems to be a little simpler then I thought once I dug into the docs. Will do hope your having a good one .

Related discussion:
text: ) -> Bx::Value { let is_float = input_ty.is_floating_point(); let is_signed = input_ty.is_signed(); <del> let is_unit = input_ty.is_unit(); </del> match op { mir::BinOp::Add => if is_float { bx.fadd(lhs, rhs)
Code change:
libcore however doesn't use those for the implementations for and for the unit type. This means that the special case in cg_ssa can be removed.
Hi I'd like to work on this. Would be a good initial contribution to Rust :)
I'm really new to the code base, though. Could you clarify what the means above?
That's , a part of the code generation code in rustc. The code in the first snippet is located there.
Thanks for clarifying that! I'll go through the code and post any questions here.
Would love to help but don't know where to start. If mentoring is still possible please ping me or send me in the right direction somehow .
or maybe if your up to the task :)
I think you just need to look at and remove the check for that was mentioned. You can check https://rust- for an overview of the compiler and instruction on how to build it and run tests.
Thanks seems to be a little simpler then I thought once I dug into the docs. Will do hope your having a good one .

Related discussion:
text: mir::BinOp::Shl => common::build_unchecked_lshift(bx, lhs, rhs), mir::BinOp::Shr => common::build_unchecked_rshift(bx, input_ty, lhs, rhs), mir::BinOp::Ne | mir::BinOp::Lt | mir::BinOp::Gt | <del> mir::BinOp::Eq | mir::BinOp::Le | mir::BinOp::Ge => if is_unit { bx.cx().const_bool(match op { mir::BinOp::Ne | mir::BinOp::Lt | mir::BinOp::Gt => false, mir::BinOp::Eq | mir::BinOp::Le | mir::BinOp::Ge => true, _ => unreachable!() }) } else if is_float { </del> <ins> mir::BinOp::Eq | mir::BinOp::Le | mir::BinOp::Ge => if is_float { </ins> bx.fcmp( base::bin_op_to_fcmp_predicate(op.to_hir_binop()), lhs, rhs
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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 prioritization.
Miri fix at

Related discussion:
text: <del> Subproject commit 4f6f264c305ea30f1de90ad0c2f341e84d972b2e </del> <ins> Subproject commit d77fe6c63ca4c50b207a1161def90c9e57368d5b </ins>
Code change:
The keyword doesn't seem to currently work with specialization (namely ). The order of keywords does not matter — I'm not sure which it's supposed to be. Minimal example from in dtolnay/async-trait: which gives the following error
Note that in traits is not yet allowed, so this would be meaningless even if it parsed.
[async_trait] can handle this if rustc will parse it.
Where this came up is when attempting to use the crate, which uses a proc macro to transform async traits to current syntax. I was attempting to use it in Rocket when I ran into this.

Related discussion:
text: self.is_keyword_ahead(1, &[ kw::Impl, kw::Const, <ins> kw::Async, </ins> kw::Fn, kw::Unsafe, kw::Extern,
Code change:
The keyword doesn't seem to currently work with specialization (namely ). The order of keywords does not matter — I'm not sure which it's supposed to be. Minimal example from in dtolnay/async-trait: which gives the following error
Note that in traits is not yet allowed, so this would be meaningless even if it parsed.
[async_trait] can handle this if rustc will parse it.
Where this came up is when attempting to use the crate, which uses a proc macro to transform async traits to current syntax. I was attempting to use it in Rocket when I ran into this.

Related discussion:
text: <ins> // Ensure that `default async fn` will parse. // See issue #63716 for details. // check-pass // edition:2018 #![feature(specialization)] fn main() {} #[cfg(FALSE)] impl Foo for Bar { default async fn baz() {} } </ins>
Code change:
has been renamed to as discussed in , but the old name is still referenced in the docs:

Related discussion:
text: /// [`len`]: #method.len /// /// Note: This example shows the internals of `&str`. `unsafe` should not be <del> /// used to get a string slice under normal circumstances. Use `as_slice` </del> <ins> /// used to get a string slice under normal circumstances. Use `as_str` </ins> /// instead. #[stable(feature = "rust1", since = "1.0.0")] mod prim_str { }
Code change:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.

Related discussion:
text: <ins> use rustc_data_structures::fx::FxHashMap; </ins> use syntax_pos::Span; use crate::print::pprust::token_to_string;
Code change:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.

Related discussion:
text: unmatched_braces: Vec::new(), matching_delim_spans: Vec::new(), last_unclosed_found_span: None, <ins> last_delim_empty_block_spans: FxHashMap::default() </ins> }; let res = tt_reader.parse_all_token_trees(); (res, tt_reader.unmatched_braces)
Code change:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.

Related discussion:
text: /// Used only for error recovery when arriving to EOF with mismatched braces. matching_delim_spans: Vec<(token::DelimToken, Span, Span)>, last_unclosed_found_span: Option<Span>, <ins> last_delim_empty_block_spans: FxHashMap<token::DelimToken, Span> </ins> } impl<'a> TokenTreesReader<'a> {
Code change:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.

Related discussion:
text: // Correct delimiter. token::CloseDelim(d) if d == delim => { let (open_brace, open_brace_span) = self.open_braces.pop().unwrap(); <ins> let close_brace_span = self.token.span; if tts.is_empty() { let empty_block_span = open_brace_span.to(close_brace_span); self.last_delim_empty_block_spans.insert(delim, empty_block_span); } </ins> if self.open_braces.len() == 0 { // Clear up these spans to avoid suggesting them as we've found // properly matched delimiters so far for an entire block. self.matching_delim_spans.clear(); } else { self.matching_delim_spans.push( <del> (open_brace, open_brace_span, self.token.span), </del> <ins> (open_brace, open_brace_span, close_brace_span), </ins> ); } // Parse the close delimiter.
Code change:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.

Related discussion:
text: tts.into() ).into()) }, <del> token::CloseDelim(_) => { </del> <ins> token::CloseDelim(delim) => { </ins> // An unexpected closing delimiter (i.e., there is no // matching opening delimiter). let token_str = token_to_string(&self.token); let msg = format!("unexpected close delimiter: `{}`", token_str); let mut err = self.string_reader.sess.span_diagnostic .struct_span_err(self.token.span, &msg); <ins> if let Some(span) = self.last_delim_empty_block_spans.remove(&delim) { err.span_label( span, "this block is empty, you might have not meant to close it" ); } </ins> err.span_label(self.token.span, "unexpected close delimiter"); Err(err) },
Code change:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.

Related discussion:
text: } /// A delimiter token. <del> #[derive(Clone, PartialEq, RustcEncodable, RustcDecodable, Hash, Debug, Copy)] </del> <ins> #[derive(Clone, PartialEq, Eq, RustcEncodable, RustcDecodable, Hash, Debug, Copy)] </ins> pub enum DelimToken { /// A round parenthesis (i.e., `(` or `)`). Paren,
Code change:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.

Related discussion:
text: <ins> fn main() { } let _ = (); } //~ ERROR unexpected close delimiter </ins>
Code change:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.

Related discussion:
text: <ins> error: unexpected close delimiter: `}` --> $DIR/mismatched-delim-brace-empty-block.rs:5:1 | LL |   fn main() { |  ___________- LL | | LL | | } | |_- this block is empty, you might have not meant to close it LL |       let _ = (); LL |   } |   ^ unexpected close delimiter error: aborting due to previous error </ins>
Code change:
When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per

Related discussion:
text: use crate::hir::def_id::DefId; use crate::hir; use crate::ty::TyCtxt; <del> use syntax_pos::symbol::{sym, Symbol}; </del> <ins> use syntax_pos::symbol::Symbol; </ins> use crate::hir::map::blocks::FnLikeNode; use syntax::attr;