jiebi/CodeConvo huggingface dataset:
Code change:
let fs = fields.move_map(|f| { Spanned { span: folder.new_span(f.span), node: ast::FieldPat { <del> ident: f.node.ident, </del> <ins> ident: folder.fold_ident(f.node.ident), </ins> pat: folder.fold_pat(f.node.pat), is_shorthand: f.node.is_shorthand, }}

Related discussion:
text: stack backtrace: 1: 0x7fc35e73fdf3 - std::sys::imp::backtrace::tracing::imp::write::hdfa3e34b856f69a3 2: 0x7fc35e74e5dd - std::panicking::defaulthook::{{closure}}::h20f8c1082e0ce86e 3: 0x7fc35e74e17b - std::panicking::defaulthook::hd31552ac08c2a241 4: 0x7fc35e74ea68 - std::panicking::rustpanicwithhook::h73969d230a072c1a 5: 0x7fc357eda667 - std::panicking::beginpanic::hb89a2261f4776ce3 6: 0x7fc357eef99f - rustcerrors::Handler::bug::h13b3b29154320abd 7: 0x7fc35bab053a - rustc::session::optspanbugfmt::{{closure}}::hfea18dd68f59976d 8: 0x7fc35baafff7 - rustc::session::optspanbugfmt::h7d370a0810dbdbbd 9: 0x7fc35baafce2 - rustc::session::bugfmt::hcde5f50c54004a4f 10: 0x7fc35b984552 - rustc::hir::def::Def::defid::h728c22aafbe84efc 11: 0x7fc35c6ddb3a - rustcprivacy::ObsoleteVisiblePrivateTypesVisitor::pathisprivatetype::h24756a49a68d1da9 12: 0x7fc35c6d53db - rustc::hir::intravisit::walkty::h64b13c0c45b7a09a 13: 0x7fc35c6d49ba - rustc::hir::intravisit::Visitor::visitfn::ha8ad665c42b1d643 14: 0x7fc35c6de7cf - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a,
Code change:
let fs = fields.move_map(|f| { Spanned { span: folder.new_span(f.span), node: ast::FieldPat { <del> ident: f.node.ident, </del> <ins> ident: folder.fold_ident(f.node.ident), </ins> pat: folder.fold_pat(f.node.pat), is_shorthand: f.node.is_shorthand, }}

Related discussion:
text: 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 15: 0x7fc35c6deab5 - <rustcprivacy::ObsoleteVisiblePrivateTypesVisitor<'a, 'tcxas rustc::hir::intravisit::Visitor<'tcx::visititem::hae9f32c7942ccca1 16: 0x7fc35c6e1b7a - rustcprivacy::checkcrate::h5ba75e3c4ebe0690 17: 0x7fc35eaef747 - rustcdriver::driver::phase3runanalysispasses::{{closure}}::h388b9236cf305089 18: 0x7fc35ead66d6 - rustcdriver::driver::phase3runanalysispasses::h080c1a734c4f2909 19: 0x7fc35eac5425 - rustcdriver::driver::compileinput::hab55539b85c4ceed 20: 0x7fc35eb0ea51 - rustcdriver::runcompiler::h128b89b79f649304 21: 0x7fc35ea236fb - std::panicking::try::docall::h15bca94dda232804 22: 0x7fc35e757b06 - rustmaybecatchpanic 23: 0x7fc35ea44d01 - <F as alloc::boxed::FnBox<A::callbox::h8832766c4bda585b 24: 0x7fc35e74d470 - std::sys::imp::thread::Thread::new::threadstart::h7d03d727f96da002 25: 0x7fc357684453 - startthread 26: 0x7fc35e4147de - GI__clone 27: 0x0 - <unknown
triage: P-high Seems bad. Assigning to based on bisection.
Fixed in .
Code change:
let fs = fields.move_map(|f| { Spanned { span: folder.new_span(f.span), node: ast::FieldPat { <del> ident: f.node.ident, </del> <ins> ident: folder.fold_ident(f.node.ident), </ins> pat: folder.fold_pat(f.node.pat), is_shorthand: f.node.is_shorthand, }}

Related discussion:
text: Servo compiles with rustc 2016-12-18, but not with 2016-12-21. Diff: The crate fails to build with: The method being called here is: Its return type is which is . This call is in another impl of the same method of the same trait: Adding an explicit type annotation works around this error, but only to uncover another very similar one, then another. The third one was in code generated by serde’s , so I gave up that approach. So far I haven’t managed to reduce a test case smaller than "most of Servo", sorry. I’m suspicious of (which is part of ) because it’s commit message mentions inference. I’m not building a compiler to confirm.
CC
Also fails in , so is not to blame. New diff: I don’t have another guess, and doing a full bisect would take a very long time…
I can't find the cause in that range, at least nothing changed in the compiler AFAICT. Can you try (the commit before larger rollup)?
Expanding the macro: (Even simplifying it, this is not using ) gives:
Alright, that matches what I've seen from What about a couple more steps of bisecting? Or maybe compiling this crate with the "servo" feature off (which, AFAICT, turns off all the macros 1.1 - they might be responsible).
Swapping the order of the two arms: Changing the pattern to : Hacking to not use the stable version of the compiler (so effectively disabling the feature and enabling the one) also gives the same error.
New range, based on manual bisect: good, bad. Diff: , which leaves only in-between. CC Also found more clues. More context for the code where the error happens: is a module generated by a macro, that contains re-exports of other modules: If I add a similar not in a macro: or if I change the original code to use the real path without going through a , this seems to work around this issue completely. … only to uncover another one:
Found another ICE, I don’t know if it’s related: .
Code change:
let fs = fields.move_map(|f| { Spanned { span: folder.new_span(f.span), node: ast::FieldPat { <del> ident: f.node.ident, </del> <ins> ident: folder.fold_ident(f.node.ident), </ins> pat: folder.fold_pat(f.node.pat), is_shorthand: f.node.is_shorthand, }}

Related discussion:
text: Found a smaller test case for the inference issue: rust fn main() {} pub mod a { pub struct FontFamily; impl FontFamily { pub fn tocss(&self) -::std::fmt::Result { Ok(()) } } } macrorules! reexport { () ={ mod b { pub use a; } } } reexport!(); pub mod c { use b::a::FontFamily; struct FontFace { family: FontFamily } impl FontFace { pub fn tocss(&self) -::std::fmt::Result { try!(()); Ok(()) } } }
That "other ICE" is actually a direct observation of the bug, whereas this inference issue is some weird side-effect of the way we handle errors that don't stop compilation.
never mind, apparently it fails locally
triage: P-high Seems bad. Assigning to based on bisection.
Does this affect beta ()?
At the moment the latest successful nightly build is 3 days old. I don’t know how often playpen’s nigthly is updated. merged 2 days ago. (This is the rollup PR that merged , which introduced this issue if I did my manual bisecting correctly.) As far as I can tell no, is not reachable from and so beta is not affected.
Fixed in .
Code change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // aux-build:import_crate_var.rs // error-pattern: `$crate` may not be imported // error-pattern: `use $crate;` was erroneously allowed and will become a hard error #![feature(rustc_attrs)] #[macro_use] extern crate import_crate_var; m!(); #[rustc_error] fn main() {} </ins>

Related discussion:
text: When on latest rust nightly , you get an ICE when compiling .
Its a pretty recent regression, it can't be reproduced with .
Okay, managed to minimize it: Looks like a regression of . cc any ideas on this?
Yeah, this was caused by an oversight in -- fixed in .
Code change:
self.points.contains(row, index) } <ins> /// Returns an iterator of all the elements contained by the region `r` crate fn get_elements(&self, row: N) -> impl Iterator<Item = Location> + '_ { self.points .row(row) .into_iter() .flat_map(|set| set.iter()) .take_while(move |&p| self.elements.point_in_range(p)) .map(move |p| self.elements.to_location(p)) } </ins> /// Returns a "pretty" string value of the region. Meant for debugging. crate fn region_value_str(&self, r: N) -> String { <del> region_value_str( self.points .row(r) .into_iter() .flat_map(|set| set.iter()) .take_while(|&p| self.elements.point_in_range(p)) .map(|p| self.elements.to_location(p)) .map(RegionElement::Location), ) </del> <ins> region_value_str(self.get_elements(r).map(RegionElement::Location)) </ins> } }

Related discussion:
text: <!-- 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. --code from glacier <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This one also crashes beta and stable release channel.
Huh, why was this not detected earlier if it was tracked in glacier as fixed?
If you add a annotation to the trait bound on , then it no longer ICEs. Here's the code: Output: And if you add the two feature attributes the above messages ask you to enable, it still does not ICE, but correctly errors with "evaluation of constant value failed." Based on some debugging which I , I think this ICE has to do with the lifetime in the bound , although I'm not exactly sure how. I am new to the Rust compiler, and I just chose this issue because it seemed like a good first issue to work on, so I will read the (thanks to for sharing this) and try to further debug this.
If you plan to work on this issue, I recommend claiming it so other people know that and don't start working on it too. You can claim the issue by commenting with . More details about how to use rustbot are . You may also want to read the of the guide.
claim
Code change:
/// (e.g. `min`, `minimum`, `max`, `maximum`); other aspects of their semantics and which IEEE 754 /// operation they correspond to are documented with the respective functions. /// <del> /// When a floating-point operation is executed in `const` context, the same rules apply: no /// guarantee is made about which of the NaN bit patterns described above will be returned. The /// result does not have to match what happens when executing the same code at runtime, and the /// result can vary depending on factors such as compiler version and flags. </del> <ins> /// When an arithmetic floating-point operation is executed in `const` context, the same rules /// apply: no guarantee is made about which of the NaN bit patterns described above will be /// returned. The result does not have to match what happens when executing the same code at /// runtime, and the result can vary depending on factors such as compiler version and flags. </ins> /// /// ### Target-specific "extra" NaN values // FIXME: Is there a better place to put this?

Related discussion:
text: Pointed out by in the float docs are using the term "arithmetic" operations in a few places, but that term is never defined. Furthermore, the new NaN docs probably should use that term as well when discussing which operations the NaN rules apply to (instead of "non-bitwise floating point operations" which they use currently). By "arithmetic operations", the docs likely mean all operations except for unary , , , , , and .
Code change:
use clean::Variant::*; match variant { CLike(disr) => Variant::Plain(disr.map(|disr| disr.into_tcx(tcx))), <del> Tuple(fields) => Variant::Tuple( fields .into_iter() .filter_map(|f| match *f.kind { clean::StructFieldItem(ty) => Some(ty.into_tcx(tcx)), clean::StrippedItem(_) => None, _ => unreachable!(), }) .collect(), ), Struct(s) => Variant::Struct(ids(s.fields, tcx)), </del> <ins> Tuple(fields) => Variant::Tuple(ids_keeping_stripped(fields, tcx)), Struct(s) => Variant::Struct { fields_stripped: s.has_stripped_entries(), fields: ids(s.fields, tcx), }, </ins> } } }

Related discussion:
text: At some point their should also be a for , and probably a way to tell what position each of the non stripped items are, as currently each of these 3 variants are documented with the same inner. but HTML gets a good representation:  The solution is probably to do what we do for structs, and store the , and a , such that each field of a varient gets an to hold the . We also should have a numfields, as even in that schema, you can't tell the difference between This also effects struct AFAIKT. I don't think this needs to be done now. I'll file an issue for it. Originally posted by in modify labels: +A-rustdoc-json +T-rustdoc
Related:
Code change:
self.check_export_name(hir_id, &attr, span, target) } else if self.tcx.sess.check_name(attr, sym::rustc_args_required_const) { self.check_rustc_args_required_const(&attr, span, target, item) <ins> } else if self.tcx.sess.check_name(attr, sym::rustc_layout_scalar_valid_range_start) { self.check_rustc_layout_scalar_valid_range(&attr, span, target) } else if self.tcx.sess.check_name(attr, sym::rustc_layout_scalar_valid_range_end) { self.check_rustc_layout_scalar_valid_range(&attr, span, target) </ins> } else if self.tcx.sess.check_name(attr, sym::allow_internal_unstable) { self.check_allow_internal_unstable(hir_id, &attr, span, target, &attrs) } else if self.tcx.sess.check_name(attr, sym::rustc_allow_const_fn_unstable) {

Related discussion:
text: <!-- 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
This isn't really a bug, it's just that it has bad diagnostics because it uses , which is a perma-unstable attribute. I would recommend against reporting bugs that need attributes unless they cause unsoundness.
MCVE:
Should I exclude all test programs that have a line starting with ? Thanks.
I don't personally feel comfortable setting a policy that we'll never fix ICEs with attributes, but they are definitely less likely to be bugs than other ICEs. Note that this isn't sufficient to catch programs that have an attribute, you can have arbitrary macros that play with conditional compilation, like . Catching and will probably hit the common cases, though (you may want to also include inner attributes).
Code change:
self.check_export_name(hir_id, &attr, span, target) } else if self.tcx.sess.check_name(attr, sym::rustc_args_required_const) { self.check_rustc_args_required_const(&attr, span, target, item) <ins> } else if self.tcx.sess.check_name(attr, sym::rustc_layout_scalar_valid_range_start) { self.check_rustc_layout_scalar_valid_range(&attr, span, target) } else if self.tcx.sess.check_name(attr, sym::rustc_layout_scalar_valid_range_end) { self.check_rustc_layout_scalar_valid_range(&attr, span, target) </ins> } else if self.tcx.sess.check_name(attr, sym::allow_internal_unstable) { self.check_allow_internal_unstable(hir_id, &attr, span, target, &attrs) } else if self.tcx.sess.check_name(attr, sym::rustc_allow_const_fn_unstable) {

Related discussion:
text: Gives:
cc ICE-ing instead of user error on misuse seems somewhat okay given that it's an internal attribute, IMO.
agreed. We don't protect against mis-use of rustc internal attributes beyond making sure that you can't trivially create buggy code. I don't think we should put any effort into making this nicer to use and instead create the const-generic based replacement.
Code change:
/// Returns a map from a sufficiently visible external item (i.e. an external item that is /// visible from at least one local module) to a sufficiently visible parent (considering /// modules that re-export the external item to be parents). <del> fn visible_parent_map<'a>(&'a self) -> ::std::cell::RefMut<'a, DefIdMap<DefId>> { let mut visible_parent_map = self.visible_parent_map.borrow_mut(); if !visible_parent_map.is_empty() { return visible_parent_map; } </del> <ins> fn visible_parent_map<'a>(&'a self) -> ::std::cell::Ref<'a, DefIdMap<DefId>> { { let visible_parent_map = self.visible_parent_map.borrow(); if !visible_parent_map.is_empty() { return visible_parent_map; } } </ins> use std::collections::vec_deque::VecDeque; use std::collections::hash_map::Entry; <ins> let mut visible_parent_map = self.visible_parent_map.borrow_mut(); </ins> for cnum in (1 .. self.next_crate_num().as_usize()).map(CrateNum::new) { let cdata = self.get_crate_data(cnum);

Related discussion:
text: I was going through some refactoring and the compiler exploded. No unsafe. The last bits of code I was playing with can be found , before I tried to refactor the example, the tests were building and passing. The macro that might be to blame is . I parked a branch with the code that made it blew up, you can find it here works, blows up. a happy compiler, worst case an unhappy one a dead compiler : Backtrace:
Minimal example:
Thanks that was a quick fix. Do you have a workaround until the fix makes it to master?
The ICE occurs when you have an item referenced in an impl signature is imported from an statement occurs within an impl. To work around the ICE, you can move the call to to a different free function.
Got it, it works , thanks!
Code change:
without modifying the original"] #[stable(feature = "unicode_case_mapping", since = "1.2.0")] pub fn to_lowercase(&self) -> String { <del> let out = convert_while_ascii(self.as_bytes(), u8::to_ascii_lowercase); </del> <ins> let (mut s, rest) = convert_while_ascii(self, u8::to_ascii_lowercase); </ins> <del> // Safety: we know this is a valid char boundary since // out.len() is only progressed if ascii bytes are found let rest = unsafe { self.get_unchecked(out.len()..) }; // Safety: We have written only valid ASCII to our vec let mut s = unsafe { String::from_utf8_unchecked(out) }; </del> <ins> let prefix_len = s.len(); </ins> for (i, c) in rest.char_indices() { if c == 'Σ' {

Related discussion:
text: I'm looking into the performance of / on mostly ascii strings, using a small microbenchmark to . Using linux perf tooling I see that the hot part of the code is the following large loop, which despite heavy use of sse2 instructions only seems to process 32 bytes per iteration. I don't see an easy way to improve the autovectorization of this code, but it should be relatively easy to explicitly vectorize it using , and I would like to prepare such a PR if there are no objections. As far as I know, is already in use inside , for example by .
The way the loop ors the bits for the is-ascii check into a single usize doesn't seem ideal for vectorization. keeping the lanes independent should yield better autovectorization results.
Thanks for the suggestion. I already started with a simd implementation, but now checked again if the autovectorization could be improved. With the following main loop The assembly and performance is indeed better, but there is still some weird shuffling and shifting going on: The explicit simd version looks a bit better, mostly because the ascii check directly translates to a : Do you have a preference here between autovectorization and explicit simd?
If the SIMD impl results in reasonable code across architectures, including some without SIMD then that should be fine. I think it would be the first time where we use portable simd unconditionally, so it could use some additional scrutiny. If it's only meant to target x86 with SSE2 then that'd mean having multiple paths and in that case we'd still have to tweak the generic path anyway. At that point we might as well just optimize the latter further. You can probably get rid of those too by keeping multiple bools in a small array. That way the optimizer will more easily see that it can shove them into independent simd lanes. Increasing the unroll count might help too to fit better into simd registers. We do get pretty decent autovectorization in other places in the standard library by massaging things into a state that basically looks like arrays-instead-of-SIMD-types. E.g.
It seems llvm is too "smart" for this trick, on its own that generates the exact same code. The trick does work, although it seems a bit fragile.
Code change:
without modifying the original"] #[stable(feature = "unicode_case_mapping", since = "1.2.0")] pub fn to_lowercase(&self) -> String { <del> let out = convert_while_ascii(self.as_bytes(), u8::to_ascii_lowercase); </del> <ins> let (mut s, rest) = convert_while_ascii(self, u8::to_ascii_lowercase); </ins> <del> // Safety: we know this is a valid char boundary since // out.len() is only progressed if ascii bytes are found let rest = unsafe { self.get_unchecked(out.len()..) }; // Safety: We have written only valid ASCII to our vec let mut s = unsafe { String::from_utf8_unchecked(out) }; </del> <ins> let prefix_len = s.len(); </ins> for (i, c) in rest.char_indices() { if c == 'Σ' {

Related discussion:
text: The following creates a instruction just like the simd version, but a slightly different alternative with a array and comparing against 0 does not. It only needs to be better than the autovectorized version on those platforms ;) My initial idea was to gate the simd code on either SSE2 or Neon (possibly also Altivec and RiscV). I'd also add a scalar loop for the non-multiple-of-N remainder, so all-ascii strings are fully handled by specialized code. Currently this remainder goes through the generic and code path. On other platforms, only the scalar loop would be used, since I assume the autovectorization would also generate suboptimal code. But I agree that if similar code quality can be achieved with autovectorization, that would be preferable. I'll open a PR after a little bit more polishing the code.
Code change:
#[rustc_doc_primitive = "f16"] #[doc(alias = "half")] <del> /// A 16-bit floating point type (specifically, the "binary16" type defined in IEEE 754-2008). </del> <ins> /// A 16-bit floating-point type (specifically, the "binary16" type defined in IEEE 754-2008). </ins> /// /// This type is very similar to [`prim@f32`] but has decreased precision because it uses half as many /// bits. Please see [the documentation for `f32`](prim@f32) or [Wikipedia on half-precision

Related discussion:
text: Pointed out by in the float docs are using the term "arithmetic" operations in a few places, but that term is never defined. Furthermore, the new NaN docs probably should use that term as well when discussing which operations the NaN rules apply to (instead of "non-bitwise floating point operations" which they use currently). By "arithmetic operations", the docs likely mean all operations except for unary , , , , , and .
Code change:
<ins> // Copyright 2017 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 f(x: &mut u32) {} fn main() { let x = Box::new(3); f(&mut *x); } </ins>

Related discussion:
text: This code: produces a helpful error message: But the analogous code using a : gives an error which doesn't point at the binding :
This is fixed today. I'm going to mark as E-needstest since it feels like the kind of thing that's easy to regress on -- a UI test would be best here.