jiebi/CodeConvo huggingface dataset:
Change:
. When calling the function defined like this in C: And like this in Rust: You get a crash with the MSVC version of Rust, but the MinGW version works. This is because apparently the C code expects to actually be a pointer. If you change the Rust declaration to , then it works with the MSVC version and crashes with the MinGW version.
Someone pointed out that this is maybe not a MSVC-related issue. I only tested 32 MinGW vs 64 bits MSVC, so maybe it's an issue of 32bits vs 64bits instead of MinGW vs MSVC.
Possibly related to
should probably be . The equivalent clang code: .

Discussion:
2 => ArgType::direct(t, Some(Type::i16(ccx)), None, None), 4 => ArgType::direct(t, Some(Type::i32(ccx)), None, None), 8 => ArgType::direct(t, Some(Type::i64(ccx)), None, None), <del> _ => ArgType::indirect(t, Some(Attribute::ByVal)) </del> <ins> _ => ArgType::indirect(t, None) </ins> } } _ => {

uint64_t get_z(struct S s) { return s.z; } <ins> uint64_t get_c_many_params(void *a, void *b, void *c, void *d, struct quad f) { return f.c; } </ins>

<ins> // Copyright 2012-2015 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. // #[derive(Copy, Clone)] pub struct Quad { a: u64, b: u64, c: u64, d: u64 } mod rustrt { use super::Quad; #[link(name = "rust_test_helpers")] extern { pub fn get_c_many_params(_: *const (), _: *const (), _: *const (), _: *const (), f: Quad) -> u64; } } fn test() { unsafe { let null = std::ptr::null(); let q = Quad { a: 1, b: 2, c: 3, d: 4 }; assert_eq!(rustrt::get_c_many_params(null, null, null, null, q), q.c); } } pub fn main() { test(); } </ins>
Change:
When you have a match statement against a variable the behaviour is unexpected. Either get an error telling me that placing a variable won't do what I think it will do. Or allow this to happen, and allow for specific cases, as currently adding any extra arms returns a error. This compiles with no errors, or warning, and prints out:
You can match against patterns that are composed of: Literals, ranges, Struct constructors, Enum variant constructors and constants. If you put in an identifier like this it's just a new binding (a catch-all). Rust generally allows variable shadowing without warning ( is ok), so this is consistent with that at least.
Relevant doc section is . I think it could be clarified around this issue.
tagging with docs to see if i can make this somehow more prominent, but I'm not sure.

Discussion:
This prints `one`. <ins> There’s one pitfall with patterns: like anything that introduces a new binding, they introduce shadowing. For example: ```rust let x = 'x'; let c = 'c'; match c { x => println!("x: {} c: {}", x, c), } println!("x: {}", x) ``` This prints: ```text x: c c: c x: x ``` In other words, `x =>` matches the pattern and introduces a new binding named `x` that’s in scope for the match arm. Because we already have a binding named `x`, this new `x` shadows it. </ins> # Multiple patterns You can match multiple patterns with `|`:
Change:
Someone came into the channel today confused at how to index into a vector. Their problem was that the variable that they wanted to use as an index was an . Casting actually crossed their mind, but they gave up after trying and . The page at could stand to have a sentence mentioning how to index with a variable (currently it just indexes with constants, which all properly get inferred to usize without the reader realizing).

Discussion:
The indices count from `0`, so the third element is `v[2]`. <ins> It’s also important to note that you must index with the `usize` type: ```ignore let v = vec![1, 2, 3, 4, 5]; let i: usize = 0; let j: i32 = 0; // works v[i]; // doesn’t v[j]; ``` Indexing with a non-`usize` type gives an error that looks like this: ```text error: the trait `core::ops::Index<i32>` is not implemented for the type `collections::vec::Vec<_>` [E0277] v[j]; ^~~~ note: the type `collections::vec::Vec<_>` cannot be indexed by `i32` error: aborting due to previous error ``` There’s a lot of punctuation in that message, but the core of it makes sense: you cannot index with an `i32`. </ins> ## Iterating Once you have a vector, you can iterate through its elements with `for`. There
Change:
Rust reference says: The problem with this is that ignored` I guess the correct wording would be (keeping in mind that by itself is not a valid identifier):

Discussion:
[^non_ascii_idents]: Non-ASCII characters in identifiers are currently feature gated. This is expected to improve soon. <del> - The first character has property `XID_start` - The remaining characters have property `XID_continue` </del> <ins> Either * The first character has property `XID_start` * The remaining characters have property `XID_continue` Or * The first character is `_` * The identifier is more than one character, `_` alone is not an identifier * The remaining characters have property `XID_continue` </ins> that does _not_ occur in the set of [keywords][keywords].
Change:
Namely: + maybe So, if I want to visit, for example, a and report an error, I can't do it and have to visit all its parents instead.

Discussion:
} fn visit_enum_def(&mut self, enum_definition: &'ast hir::EnumDef, <del> generics: &'ast hir::Generics, item_id: ast::NodeId) { </del> <ins> generics: &'ast hir::Generics, item_id: ast::NodeId, _: Span) { </ins> self.populate_enum_discriminants(enum_definition); visit::walk_enum_def(self, enum_definition, generics, item_id); }

walk_struct_field(self, s) } fn visit_enum_def(&mut self, enum_definition: &'v EnumDef, <del> generics: &'v Generics, item_id: NodeId) { </del> <ins> generics: &'v Generics, item_id: NodeId, _: Span) { </ins> walk_enum_def(self, enum_definition, generics, item_id) } fn visit_variant(&mut self, v: &'v Variant, g: &'v Generics, item_id: NodeId) {

} fn visit_struct_field(&mut self, s: &'v StructField) { walk_struct_field(self, s) } fn visit_enum_def(&mut self, enum_definition: &'v EnumDef, <del> generics: &'v Generics, item_id: NodeId) { </del> <ins> generics: &'v Generics, item_id: NodeId, _: Span) { </ins> walk_enum_def(self, enum_definition, generics, item_id) } fn visit_variant(&mut self, v: &'v Variant, g: &'v Generics, item_id: NodeId) {

for elem in $list { $visitor.$method(elem) } <ins> }; ($visitor: expr, $method: ident, $list: expr, $($extra_args: expr),*) => { for elem in $list { $visitor.$method(elem, $($extra_args,)*) } </ins> } }

} ItemEnum(ref enum_definition, ref type_parameters) => { visitor.visit_generics(type_parameters); <del> visitor.visit_enum_def(enum_definition, type_parameters, item.id) </del> <ins> visitor.visit_enum_def(enum_definition, type_parameters, item.id, item.span) </ins> } ItemDefaultImpl(_, ref trait_ref) => { visitor.visit_trait_ref(trait_ref)

enum_definition: &'v EnumDef, generics: &'v Generics, item_id: NodeId) { <del> for variant in &enum_definition.variants { visitor.visit_variant(variant, generics, item_id); } </del> <ins> walk_list!(visitor, visit_variant, &enum_definition.variants, generics, item_id); </ins> } pub fn walk_variant<'v, V: Visitor<'v>>(visitor: &mut V,
Change:
In the various designators available for macro construction are listed, but they are not explained. The closest I could find was ! I am willing to take a stab at it with some guidance.
I am bad at macros, but yes, this should be explained more.

Discussion:
balanced, but they are otherwise not special. In the matcher, `$` _name_ `:` _designator_ matches the nonterminal in the Rust <del> syntax named by _designator_. Valid designators are `item`, `block`, `stmt`, `pat`, `expr`, `ty` (type), `ident`, `path`, `tt` (either side of the `=>` in macro rules), and `meta` (contents of an attribute). In the transcriber, the </del> <ins> syntax named by _designator_. Valid designators are: * `item`: an [item](#items) * `block`: a [block](#block-expressions) * `stmt`: a [statement](#statements) * `pat`: a [pattern](#match-expressions) * `expr`: an [expression](#expressions) * `ty`: a [type](#types) * `ident`: an [identifier](#identifiers) * `path`: a [path](#paths) * `tt`: either side of the `=>` in macro rules * `meta`: the contents of an [attribute](#attributes) In the transcriber, the </ins> designator is already known, and so only the name of a matched nonterminal comes after the dollar sign.
Change:
Output: Doesn't occur if the comment isn't empty.
Actually, that's being parsed as a doc comment (which you can see if you remove the macro invocation). This looks like a parsing bug of some kind.

Discussion:
} pub fn is_block_doc_comment(s: &str) -> bool { <del> let res = (s.starts_with("/**") && *s.as_bytes().get(3).unwrap_or(&b' ') != b'*') || s.starts_with("/*!"); </del> <ins> let res = ((s.starts_with("/**") && *s.as_bytes().get(3).unwrap_or(&b' ') != b'*') || s.starts_with("/*!")) && s.len() >= 5; // Prevent `/**/` from being parsed as a doc comment </ins> debug!("is {:?} a doc comment? {}", s, res); res }

<ins> // Copyright 2015 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. // `/**/` was previously regarded as a doc comment because it starts with `/**` and ends with `*/`. // This could break some internal logic that assumes the length of a doc comment is at least 5, // leading to an ICE. fn main() { println!(/**/); //~ ERROR unexpected end } </ins>
Change:
Several FIXMEs (formerly TODOs) there that mention using the correct spans for different errors.
Not critical for 0.6; de-milestoning
FIXMEs are still there. I'm not sure if this should be nominated for a maturity milestone, but if it's something that will trip people up, production ready is probably appropriate.
Nominating for Milestone 5: Production Ready.
accepted for production-ready milestone
visiting for triage, email from 2013 sep 16
Accepting for P-low
Triage: no change
Is this still an issue?
yes
Did address this? The description of that PR mentions that it partially addressed this, but I don't know to what extent.
cc but I don't think this issue is entirely fixed, we still use some bad spans, that PR just fixed one case of them.
You've done a lot of work on this file recently, perhaps you could comment if there's still more to be done with the spans? is the file for reference.
I'm not familiar with the details off the top of my head, but IIRC there are comments about spans that could use improvements in the file.
That memory was correct; there are many FIXME comments in the file.
There are now four FIXMEs in that file. No idea if that's few enough for this ticket or not.
If is correct and gets merged, we would be down to just one FIXME and it is about hygiene. Specifically, when transcribing a MBE, when we replace a meta-variable with a matched nonterminal, currently: If the meta-variable was a , we don't do anything to the syntax context of token trees (). If the meta-variable is any other type of nonterminal, we apply the mark of the current expansion to the span of the nonterminal. Why the distinction? cc
Why the distinction? has an answer for this question.

Discussion:
// the meta-var. let ident = MacroRulesNormalizedIdent::new(orignal_ident); if let Some(cur_matched) = lookup_cur_matched(ident, interp, &repeats) { <del> if let MatchedNonterminal(ref nt) = cur_matched { // FIXME #2887: why do we apply a mark when matching a token tree meta-var // (e.g. `$x:tt`), but not when we are matching any other type of token // tree? if let NtTT(ref tt) = **nt { result.push(tt.clone().into()); </del> <ins> if let MatchedNonterminal(nt) = cur_matched { let token = if let NtTT(tt) = &**nt { // `tt`s are emitted into the output stream directly as "raw tokens", // without wrapping them into groups. tt.clone() </ins> } else { <ins> // Other variables are emitted into the output stream as groups with // `Delimiter::None` to maintain parsing priorities. // `Interpolated` is currenty used for such groups in rustc parser. </ins> marker.visit_span(&mut sp); <del> let token = TokenTree::token(token::Interpolated(nt.clone()), sp); result.push(token.into()); } </del> <ins> TokenTree::token(token::Interpolated(nt.clone()), sp) }; result.push(token.into()); </ins> } else { // We were unable to descend far enough. This is an error. return Err(cx.struct_span_err(
Change:
See the case in .
Not critical for 0.6; de-milestoning
-- does it make sense for the AST fold to visit macros? Or is the current code correct?
From my perspective: yes, definitely. In particular, I'm going to want ident-folds to hit the idents inside of macro invocations. Could it break code to add this traversal? Well, the only place you're going to see unexpanded macro invocations is prior to expansion, and the only thing inside of macro invocations is tokens, so it seems very unlikely. To summarize: yes, this fold should visit macro invocations.
In that case, nominating for milestone 5, production-ready
accepted for production-ready milestone
I've implemented this in a local branch, I expect to push it soon (next two days)
done, now. FIXME removed downstream.

Discussion:
id: fld.new_id(a.id), } } //used in noop_fold_expr, and possibly elsewhere in the future fn fold_mac_(m: &mac, fld: @ast_fold) -> mac { spanned { <del> node: match m.node { mac_invoc_tt(*) => copy m.node }, span: fld.new_span(m.span), </del> <ins> node: match m.node { mac_invoc_tt(p,ref tts) => mac_invoc_tt(fld.fold_path(p), fold_tts(*tts,fld)) }, span: fld.new_span(m.span) } } fn fold_tts(tts : &[token_tree], fld: @ast_fold) -> ~[token_tree] { do tts.map |tt| { match *tt { tt_tok(span, ref tok) => tt_tok(span,maybe_fold_ident(tok,fld)), tt_delim(ref tts) => tt_delim(fold_tts(*tts,fld)), tt_seq(span, ref pattern, ref sep, is_optional) => tt_seq(span, fold_tts(*pattern,fld), sep.map(|tok|maybe_fold_ident(tok,fld)), is_optional), tt_nonterminal(sp,ref ident) => tt_nonterminal(sp,fld.fold_ident(*ident)) } } } // apply ident folder if it's an ident, otherwise leave it alone fn maybe_fold_ident(t : &token::Token, fld: @ast_fold) -> token::Token { match *t { token::IDENT(id,followed_by_colons) => token::IDENT(fld.fold_ident(id),followed_by_colons), _ => copy *t </ins> } }

} item_mac(ref m) => { // FIXME #2888: we might actually want to do something here. <del> item_mac(copy *m) </del> <ins> // ... okay, we're doing something. It would probably be nicer // to add something to the ast_fold trait, but I'll defer // that work. item_mac(fold_mac_(m,fld)) </ins> } } }
Change:
The whole example compiles it the implementation is removed.
I'm also running into something that appears to be this issue. I'm indexing a Vec, so the implementation of IndexMut is not under my control. I can try to make a reduced example using Vec if it would be helpful. EDIT: oh, it seems that already contains such an example.
Just wanted to note that I encountered this bug.
This . A simplified example: Workarounds include: extra braces: explicitly: explicitly:
This compiles now. Marking as needs-test (unsure if there is one that covers this already)

Discussion:
<ins> // check-pass use std::cell::RefCell; pub fn f(v: Vec<RefCell<u8>>) { let _t = &mut *v[0].borrow_mut(); } fn main() {} </ins>
Change:
I the augmented_assignments feature to the , but when testing, the compiler complained: I thought I had already done that, but it turns out it isn't enough to be in the source file using the feature. In retrospect (now that I know from help on IRC what the issue is), I'd expect the error to say: or something to that effect.

Discussion:
"overloaded augmented assignments are not stable"); fileline_help!( tcx.sess, e.span, <del> "add #![feature(augmented_assignments)] to the crate features  </del> <ins> "add #![feature(augmented_assignments)] to the crate root  </ins> to enable"); } }

let mut x = Int(0); x += 1; //~^ error: overloaded augmented assignments are not stable <del> // | help: add #![feature(augmented_assignments)] to the crate features to enable </del> <ins> // | help: add #![feature(augmented_assignments)] to the crate root to enable </ins> }
Change:
This can be confusing for people new to rust and perhaps trying to copy some example code from At the moment this produces is OK but may be hard to see how it applies. Perhaps the friendliest thing would be to suggest using rather than , though perhaps that is too specialized. I think there was another bug about returning a Result?
We have decided, generally, to assume that when reading API docs, you already know Rust. If you click the link to show the example in the playpen, it will insert the stuff needed to make it compile. That said, E0308 could use a specific call-out of this situation. And yes, there's an RFC repo issue about main and Result.
Yes, I wasn't suggesting doing this in the documentation, which would be unscalable. E0308 says "This error occurs when the compiler was unable to infer the concrete type of a variable", but there's no variable involved here, at least at the user-visible level. Could we have a more specific error code for 'returning X in a function declared to return Y'? Or, otherwise, mention in the documentation for E0308 that it covers that case too?
/cc
Given exists, I think the real heart remaining part of this is says "wrong type for a variable" but it would be clearer with "wrong return type."
yay, thanks!

Discussion:
//      | //    type `i32` assigned to variable `x` ``` <ins> Another situation in which this occurs is when you attempt to use the `try!` macro inside a function that does not return a `Result<T, E>`: ``` use std::fs::File; fn main() { let mut f = try!(File::create("foo.txt")); } ``` This code gives an error like this: ```text <std macros>:5:8: 6:42 error: mismatched types: expected `()`, found `core::result::Result<_, _>` (expected (), found enum `core::result::Result`) [E0308] ``` `try!` returns a `Result<T, E>`, and so the function must. But `main()` has `()` as its return type, hence the error. </ins> "##, E0309: r##"
Change:
Building nightly yields
A reduction of the code in question is available here: CC
Further reduced:
It looks like the borrow of is not constrained and is therefore inferred to .

Discussion:
NodeTraitItem(ti) => PathName(ti.name), NodeVariant(v) => PathName(v.node.name), NodeLifetime(lt) => PathName(lt.name), <ins> NodeTyParam(tp) => PathName(tp.name), NodeLocal(&Pat { node: PatIdent(_,l,_), .. }) => { PathName(l.node.name) }, </ins> _ => panic!("no path elem for {:?}", node) } }

}; substs_wf_in_scope(rcx, origin, &callee.substs, expr.span, expr_region); <ins> type_must_outlive(rcx, infer::ExprTypeIsNotInScope(callee.ty, expr.span), callee.ty, expr_region); </ins> } // Check any autoderefs or autorefs that appear.

} } <ins> debug!("regionck::visit_expr(e={:?}, repeating_scope={}) - visiting subexprs", expr, rcx.repeating_scope); </ins> match expr.node { hir::ExprPath(..) => { rcx.fcx.opt_node_ty_substs(expr.id, |item_substs| {

<ins> // Copyright 2015 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. pub struct Xyz<'a, V> { pub v: (V, &'a u32), } pub fn eq<'a, 's, 't, V>(this: &'s Xyz<'a, V>, other: &'t Xyz<'a, V>) -> bool where V: PartialEq { this.v == other.v } fn main() {} </ins>
Change:
This is part of , and depends on . We should should replace with and with throughout the compiler, once it is supported. We should also replace all with .

Discussion:
<del> Subproject commit 891e1a859b52486936e021235fdc36fbdd9b4100 </del> <ins> Subproject commit b7c802b5e33f5a402de3780bc5a8b05e7ebad409 </ins>
Change:
I wrote and got this output: The hint in particular was confusing, since it is targeted at developers who created the impl and forgot to provide a argument, rather than consumers of an impl that is specifically designed to be static.
We should probably structure this so that both suggestions are shown. Alternatively, suggest changing the method only when the method is defined in the local crate.
Current compiler message is slightly different: The snippet given for the "candidate " seems wrong, shouldn't it present the definition of (or, if that is not available since it's from , nothing)?
Fixed by .

Discussion:
match *source { CandidateSource::ImplSource(impl_did) => { // Provide the best span we can. Use the item, if local to crate, else <del> // the impl, if local to crate (item may be defaulted), else the call site. </del> <ins> // the impl, if local to crate (item may be defaulted), else nothing. </ins> let item = impl_item(fcx.tcx(), impl_did, item_name) .or_else(|| { trait_item(

item_name ) }).unwrap(); <del> let impl_span = fcx.tcx().map.def_id_span(impl_did, span); let item_span = fcx.tcx().map.def_id_span(item.def_id(), impl_span); </del> <ins> let note_span = fcx.tcx().map.span_if_local(item.def_id()).or_else(|| { fcx.tcx().map.span_if_local(impl_did) }); </ins> let impl_ty = check::impl_self_ty(fcx, span, impl_did).ty;

} }; <del> span_note!(err, item_span, "candidate #{} is defined in an impl{} for the type `{}`", idx + 1, insertion, impl_ty); </del> <ins> let note_str = format!("candidate #{} is defined in an impl{}  for the type `{}`", idx + 1, insertion, impl_ty); if let Some(note_span) = note_span { // We have a span pointing to the method. Show note with snippet. err.span_note(note_span, &note_str); } else { err.note(&note_str); } </ins> } CandidateSource::TraitSource(trait_did) => { let item = trait_item(fcx.tcx(), trait_did, item_name).unwrap();