jiebi/CodeConvo huggingface dataset:
Code change:
The support for ARMv6 architecture was broken somewhere between ...: compiles file while produces binary that crashes with . More specifically, this is a binary cross-compiled from for arch, linked with a . The hardware is part of Raspberry Pi Zero rev. 1.1, the processor information is as follows:
Presumably due to LLVM update. Can you determine what the illegal instruction is? (E.g. via gdb and .)
did you try compiling code on your raspberry pi 0 ? this might be issue with gcc cross compiler (code generator part)l/linker rather than Rust
Looks like even compilation directly on RPi0 is broken as the compiler/cargo crashes: Running under gdb: I'm not sure if this helpful at all, I can send (e-mail) you the coredump or do anything else you need, unfortunately I have basically no experience debugging low-level ASM issues.
The problematic instruction is , which vfp2 and dpvfp. The target builds with . There were some in LLVM 9 around the sp/dp handling on ARM ( became ), possibly we flipped a default there...
According to the ARM1176JZF-S Technical Reference Manual (which is the CPU used in Raspberry Pi Zero) it contains a VFP11 coprocessor (VFP2 implementation with full support for single-precision and double-precision math operations). Maybe VFP11 is somehow slightly different from what LLVM assumes? ARM refs: VFP11 VectorFloating-point Coprocessor Technical Reference Manual for ARM1136JF-S
Thanks for the references. So both vfp2 and fp64 should be supported. Something I missed before is that the instruction uses the register, while the VFP11 coprocessor only has 16 double-precision registers. To target this CPU needs to be to the target features. It looks like the corresponding does disable . Possibly the default flipped here, in which case we should just add to all the older ARM targets.
This issue might be related to this one - libc's CI is broken since the LLVM upgrade.
This is probably caused by EDIT: Ah nevermind, someone found this already
Reopening until there is confirmation that this is fixed...
Hi with the recent 1.38.0-nightly ( 2019-07-26) both local toolchain / cargo and the cross-compiled binary seem to work. Thanks.
Great, closing as fixed

Related discussion:
text: linker_flavor: LinkerFlavor::Gcc, options: TargetOptions { <del> features: "+v6,+vfp2".to_string(), </del> <ins> features: "+v6,+vfp2,-d32".to_string(), </ins> max_atomic_width: Some(64), abi_blacklist: super::arm_base::abi_blacklist(), target_mcount: "u{1}__gnu_mcount_nc".to_string(),
Code change:
The support for ARMv6 architecture was broken somewhere between ...: compiles file while produces binary that crashes with . More specifically, this is a binary cross-compiled from for arch, linked with a . The hardware is part of Raspberry Pi Zero rev. 1.1, the processor information is as follows:
Presumably due to LLVM update. Can you determine what the illegal instruction is? (E.g. via gdb and .)
did you try compiling code on your raspberry pi 0 ? this might be issue with gcc cross compiler (code generator part)l/linker rather than Rust
Looks like even compilation directly on RPi0 is broken as the compiler/cargo crashes: Running under gdb: I'm not sure if this helpful at all, I can send (e-mail) you the coredump or do anything else you need, unfortunately I have basically no experience debugging low-level ASM issues.
The problematic instruction is , which vfp2 and dpvfp. The target builds with . There were some in LLVM 9 around the sp/dp handling on ARM ( became ), possibly we flipped a default there...
According to the ARM1176JZF-S Technical Reference Manual (which is the CPU used in Raspberry Pi Zero) it contains a VFP11 coprocessor (VFP2 implementation with full support for single-precision and double-precision math operations). Maybe VFP11 is somehow slightly different from what LLVM assumes? ARM refs: VFP11 VectorFloating-point Coprocessor Technical Reference Manual for ARM1136JF-S
Thanks for the references. So both vfp2 and fp64 should be supported. Something I missed before is that the instruction uses the register, while the VFP11 coprocessor only has 16 double-precision registers. To target this CPU needs to be to the target features. It looks like the corresponding does disable . Possibly the default flipped here, in which case we should just add to all the older ARM targets.
This issue might be related to this one - libc's CI is broken since the LLVM upgrade.
This is probably caused by EDIT: Ah nevermind, someone found this already
Reopening until there is confirmation that this is fixed...
Hi with the recent 1.38.0-nightly ( 2019-07-26) both local toolchain / cargo and the cross-compiled binary seem to work. Thanks.
Great, closing as fixed

Related discussion:
text: linker_flavor: LinkerFlavor::Gcc, options: TargetOptions { <del> features: "+v6,+vfp2".to_string(), </del> <ins> features: "+v6,+vfp2,-d32".to_string(), </ins> abi_blacklist: super::arm_base::abi_blacklist(), target_mcount: "__mcount".to_string(), .. base
Code change:
As per : Add the following link () next to the existing ones: See all std's items Re-exports Primitive Types Modules Macros <-- this one. cc
Thanks for opening the issue! I'll send the PR tomorrow (but if you want to do it, please go ahead ).

Related discussion:
text: ItemType::Enum, ItemType::Constant, ItemType::Static, ItemType::Trait, ItemType::Function, ItemType::Typedef, ItemType::Union, ItemType::Impl, ItemType::TyMethod, ItemType::Method, ItemType::StructField, ItemType::Variant, <del> ItemType::AssocType, ItemType::AssocConst, ItemType::ForeignType] { </del> <ins> ItemType::AssocType, ItemType::AssocConst, ItemType::ForeignType, ItemType::Keyword] { </ins> if items.iter().any(|it| !it.is_stripped() && it.type_() == myty) { let (short, name) = item_ty_to_strs(&myty); sidebar.push_str(&format!("<li><a href="#{id}">{name}</a></li>",
Code change:
As per : Add the following link () next to the existing ones: See all std's items Re-exports Primitive Types Modules Macros <-- this one. cc
Thanks for opening the issue! I'll send the PR tomorrow (but if you want to do it, please go ahead ).

Related discussion:
text: // @has foo/index.html '//h2[@id="keywords"]' 'Keywords' // @has foo/index.html '//a[@href="keyword.match.html"]' 'match' <ins> // @has foo/index.html '//div[@class="block items"]//a/@href' '#keywords' </ins> // @has foo/keyword.match.html '//a[@class="keyword"]' 'match' // @has foo/keyword.match.html '//span[@class="in-band"]' 'Keyword match' // @has foo/keyword.match.html '//section[@id="main"]//div[@class="docblock"]//p' 'this is a test!'
Code change:
When run on an with elided lifetimes, generates documentation containing the anonymous elided lifetimes in the function's signature. Running on the blocking variant of the same function produces a correct signature. You can reproduce this issue by generating docs for the following code: The asynchronous function's docs show the elided lifetimes, the blocking function's docs don't: :
I agree that this makes some function signatures unnecessarily verbose. For example: ... becomes ... However, given the nuances of async functions (specifically: the referenced values must survive every state of the FSM), one could argue that showing these lifetimes in the docs might be useful(?). It's obviously not the worst problem on earth, but could someone at least shed some light on whether this behaviour is intended or not? Is this a feature or a bug? Maybe
I think it's the expected behaviour. However we can discuss about removing the elided lifetimes. In this case it's not really useful...
It's especially visually disruptive with a parameter, making simple methods look significantly more complex than they actually are. It also feels surprising to special-case async functions like this, if it makes sense to show these lifetimes symmetry with traditional functions would be nice.
We have several instances of in the Tokio codebase because the version with explicit lifetimes is simpler than the one with all the elided ones displayed. There are many cases where it would be more useful to just not show lifetimes on the method.
So I don't forget, I got halfway through debugging this and it has something to do with 'in band lifetimes': Naively changing this to use the same mechanism as .
Funnily enough, this does work with 1.34 if you add enough s: ! So in some sense this is a regression, although you needed nightly to use at the time.

Related discussion:
text: _ => false, } } <ins> /// This can happen for `async fn`, e.g. `async fn f<'_>(&'_ self)`. /// /// See [`lifetime_to_generic_param`] in [`rustc_ast_lowering`] for more information. /// /// [`lifetime_to_generic_param`]: rustc_ast_lowering::LoweringContext::lifetime_to_generic_param fn is_elided_lifetime(param: &hir::GenericParam<'_>) -> bool { match param.kind { hir::GenericParamKind::Lifetime { kind: hir::LifetimeParamKind::Elided } => true, _ => false, } } </ins> let impl_trait_params = self .params .iter()
Code change:
When run on an with elided lifetimes, generates documentation containing the anonymous elided lifetimes in the function's signature. Running on the blocking variant of the same function produces a correct signature. You can reproduce this issue by generating docs for the following code: The asynchronous function's docs show the elided lifetimes, the blocking function's docs don't: :
I agree that this makes some function signatures unnecessarily verbose. For example: ... becomes ... However, given the nuances of async functions (specifically: the referenced values must survive every state of the FSM), one could argue that showing these lifetimes in the docs might be useful(?). It's obviously not the worst problem on earth, but could someone at least shed some light on whether this behaviour is intended or not? Is this a feature or a bug? Maybe
I think it's the expected behaviour. However we can discuss about removing the elided lifetimes. In this case it's not really useful...
It's especially visually disruptive with a parameter, making simple methods look significantly more complex than they actually are. It also feels surprising to special-case async functions like this, if it makes sense to show these lifetimes symmetry with traditional functions would be nice.
We have several instances of in the Tokio codebase because the version with explicit lifetimes is simpler than the one with all the elided ones displayed. There are many cases where it would be more useful to just not show lifetimes on the method.
So I don't forget, I got halfway through debugging this and it has something to do with 'in band lifetimes': Naively changing this to use the same mechanism as .
Funnily enough, this does work with 1.34 if you add enough s: ! So in some sense this is a regression, although you needed nightly to use at the time.

Related discussion:
text: .collect::<Vec<_>>(); let mut params = Vec::with_capacity(self.params.len()); <del> for p in self.params.iter().filter(|p| !is_impl_trait(p)) { </del> <ins> for p in self.params.iter().filter(|p| !is_impl_trait(p) && !is_elided_lifetime(p)) { </ins> let p = p.clean(cx); params.push(p); }
Code change:
When run on an with elided lifetimes, generates documentation containing the anonymous elided lifetimes in the function's signature. Running on the blocking variant of the same function produces a correct signature. You can reproduce this issue by generating docs for the following code: The asynchronous function's docs show the elided lifetimes, the blocking function's docs don't: :
I agree that this makes some function signatures unnecessarily verbose. For example: ... becomes ... However, given the nuances of async functions (specifically: the referenced values must survive every state of the FSM), one could argue that showing these lifetimes in the docs might be useful(?). It's obviously not the worst problem on earth, but could someone at least shed some light on whether this behaviour is intended or not? Is this a feature or a bug? Maybe
I think it's the expected behaviour. However we can discuss about removing the elided lifetimes. In this case it's not really useful...
It's especially visually disruptive with a parameter, making simple methods look significantly more complex than they actually are. It also feels surprising to special-case async functions like this, if it makes sense to show these lifetimes symmetry with traditional functions would be nice.
We have several instances of in the Tokio codebase because the version with explicit lifetimes is simpler than the one with all the elided ones displayed. There are many cases where it would be more useful to just not show lifetimes on the method.
So I don't forget, I got halfway through debugging this and it has something to do with 'in band lifetimes': Naively changing this to use the same mechanism as .
Funnily enough, this does work with 1.34 if you add enough s: ! So in some sense this is a regression, although you needed nightly to use at the time.

Related discussion:
text: TyKind::Never => Never, TyKind::Ptr(ref m) => RawPointer(m.mutbl, box m.ty.clean(cx)), TyKind::Rptr(ref l, ref m) => { <del> let lifetime = if l.is_elided() { None } else { Some(l.clean(cx)) }; </del> <ins> // There are two times a `Fresh` lifetime can be created: // 1. For `&'_ x`, written by the user. This corresponds to `lower_lifetime` in `rustc_ast_lowering`. // 2. For `&x` as a parameter to an `async fn`. This corresponds to `elided_ref_lifetime in `rustc_ast_lowering`. //    See #59286 for more information. // Ideally we would only hide the `'_` for case 2., but I don't know a way to distinguish it. // Turning `fn f(&'_ self)` into `fn f(&self)` isn't the worst thing in the world, though; // there's no case where it could cause the function to fail to compile. let elided = l.is_elided() || matches!(l.name, LifetimeName::Param(ParamName::Fresh(_))); let lifetime = if elided { None } else { Some(l.clean(cx)) }; </ins> BorrowedRef { lifetime, mutability: m.mutbl, type_: box m.ty.clean(cx) } } TyKind::Slice(ref ty) => Slice(box ty.clean(cx)),
Code change:
When run on an with elided lifetimes, generates documentation containing the anonymous elided lifetimes in the function's signature. Running on the blocking variant of the same function produces a correct signature. You can reproduce this issue by generating docs for the following code: The asynchronous function's docs show the elided lifetimes, the blocking function's docs don't: :
I agree that this makes some function signatures unnecessarily verbose. For example: ... becomes ... However, given the nuances of async functions (specifically: the referenced values must survive every state of the FSM), one could argue that showing these lifetimes in the docs might be useful(?). It's obviously not the worst problem on earth, but could someone at least shed some light on whether this behaviour is intended or not? Is this a feature or a bug? Maybe
I think it's the expected behaviour. However we can discuss about removing the elided lifetimes. In this case it's not really useful...
It's especially visually disruptive with a parameter, making simple methods look significantly more complex than they actually are. It also feels surprising to special-case async functions like this, if it makes sense to show these lifetimes symmetry with traditional functions would be nice.
We have several instances of in the Tokio codebase because the version with explicit lifetimes is simpler than the one with all the elided ones displayed. There are many cases where it would be more useful to just not show lifetimes on the method.
So I don't forget, I got halfway through debugging this and it has something to do with 'in band lifetimes': Naively changing this to use the same mechanism as .
Funnily enough, this does work with 1.34 if you add enough s: ! So in some sense this is a regression, although you needed nightly to use at the time.

Related discussion:
text: <ins> // ignore-tidy-linelength </ins> // edition:2018 #![feature(min_const_generics)]
Code change:
Roughly according to cc
Some notes: I think this is not worth fixing as it would require hacks deep in the general sequence parser. We should try to still have suggestions; notes that there are special purpose methods for doing that. "Unnecessary" is semantically misleading here as this is a hard error, not a lint.

Related discussion:
text: pub(super) fn recover_parens_around_for_head( &mut self, pat: P<Pat>, <del> expr: &Expr, </del> begin_paren: Option<Span>, ) -> P<Pat> { match (&self.token.kind, begin_paren) { (token::CloseDelim(token::Paren), Some(begin_par_sp)) => { self.bump(); <del> let pat_str = self // Remove the `(` from the span of the pattern: .span_to_snippet(pat.span.trim_start(begin_par_sp).unwrap()) .unwrap_or_else(|_| pprust::pat_to_string(&pat)); self.struct_span_err(self.prev_token.span, "unexpected closing `)`") .span_label(begin_par_sp, "opening `(`") .span_suggestion( begin_par_sp.to(self.prev_token.span), "remove parenthesis in `for` loop", format!("{} in {}", pat_str, pprust::expr_to_string(&expr)), // With e.g. `for (x) in y)` this would replace `(x) in y)` // with `x) in y)` which is syntactically invalid. // However, this is prevented before we get here. Applicability::MachineApplicable, ) .emit(); </del> <ins> self.struct_span_err( MultiSpan::from_spans(vec![begin_par_sp, self.prev_token.span]), "unexpected parenthesis surrounding `for` loop head", ) .multipart_suggestion( "remove parenthesis in `for` loop", vec![(begin_par_sp, String::new()), (self.prev_token.span, String::new())], // With e.g. `for (x) in y)` this would replace `(x) in y)` // with `x) in y)` which is syntactically invalid. // However, this is prevented before we get here. Applicability::MachineApplicable, ) .emit(); </ins> // Unwrap `(pat)` into `pat` to avoid the `unused_parens` lint. pat.and_then(|pat| match pat.kind {
Code change:
Roughly according to cc
Some notes: I think this is not worth fixing as it would require hacks deep in the general sequence parser. We should try to still have suggestions; notes that there are special purpose methods for doing that. "Unnecessary" is semantically misleading here as this is a hard error, not a lint.

Related discussion:
text: self.check_for_for_in_in_typo(self.prev_token.span); let expr = self.parse_expr_res(Restrictions::NO_STRUCT_LITERAL, None)?; <del> let pat = self.recover_parens_around_for_head(pat, &expr, begin_paren); </del> <ins> let pat = self.recover_parens_around_for_head(pat, begin_paren); </ins> let (iattrs, loop_block) = self.parse_inner_attrs_and_block()?; attrs.extend(iattrs);
Code change:
Roughly according to cc
Some notes: I think this is not worth fixing as it would require hacks deep in the general sequence parser. We should try to still have suggestions; notes that there are special purpose methods for doing that. "Unnecessary" is semantically misleading here as this is a hard error, not a lint.

Related discussion:
text: for ( elem in vec ) { //~^ ERROR expected one of `)`, `,`, `@`, or `|`, found keyword `in` <del> //~| ERROR unexpected closing `)` </del> <ins> //~| ERROR unexpected parenthesis surrounding `for` loop head </ins> const RECOVERY_WITNESS: () = 0; //~ ERROR mismatched types } }
Code change:
Roughly according to cc
Some notes: I think this is not worth fixing as it would require hacks deep in the general sequence parser. We should try to still have suggestions; notes that there are special purpose methods for doing that. "Unnecessary" is semantically misleading here as this is a hard error, not a lint.

Related discussion:
text: LL |     for ( elem in vec ) { |                ^^ expected one of `)`, `,`, `@`, or `|` <del> error: unexpected closing `)` --> $DIR/recover-for-loop-parens-around-head.rs:10:23 </del> <ins> error: unexpected parenthesis surrounding `for` loop head --> $DIR/recover-for-loop-parens-around-head.rs:10:9 </ins> | LL |     for ( elem in vec ) { <del> |         --------------^ |         | |         opening `(` |         help: remove parenthesis in `for` loop: `elem in vec` </del> <ins> |         ^             ^ | help: remove parenthesis in `for` loop | LL -     for ( elem in vec ) { LL +     for  elem in vec  { | </ins> error[E0308]: mismatched types --> $DIR/recover-for-loop-parens-around-head.rs:13:38
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: kind_name = "variant"; } None => { <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| { </del> <ins> fcx.infcx().type_error_message_str_with_expected(pat.span, |expected, actual| { expected.map_default(~"", |&e| { </ins> fmt!("mismatched types: expected `%s` but found %s", <del> resolved_expected, actual)}, ~"a structure pattern", </del> <ins> e, actual)})}, Some(expected), ~"a structure pattern", </ins> None); fcx.write_error(pat.id); kind_name = "[error]";
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: kind_name = "structure"; } _ => { <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| { </del> <ins> fcx.infcx().type_error_message_str_with_expected(pat.span, |expected, actual| { expected.map_default(~"", |&e| { </ins> fmt!("mismatched types: expected `%s` but found %s", <del> resolved_expected, actual)}, ~"an enum or structure pattern", </del> <ins> e, actual)})}, Some(expected), ~"an enum or structure pattern", </ins> None); fcx.write_error(pat.id); kind_name = "[error]";
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 elts.each |elt| { check_pat(pcx, *elt, ty::mk_err()); } <del> let actual = ty::mk_tup(tcx, elts.map(|pat_var| { fcx.node_ty(pat_var.id) })); </del> // use terr_tuple_size if both types are tuples let type_error = match s { ty::ty_tup(ref ex_elts) =>