jiebi/CodeConvo huggingface dataset:
Change:
ast::ExprForLoop(ref pat, ref head, ref blk, _) => { // The pattern lives as long as the block. debug!("walk_expr for loop case: blk id={}", blk.id); <del> self.walk_expr(&**head); </del> <ins> self.consume_expr(&**head); </ins> <del> let head_cmt = return_if_err!(self.mc.cat_expr(&**head)); self.walk_pat(head_cmt, pat.clone()); </del> <ins> // Fetch the type of the value that the iteration yields to // produce the pattern's categorized mutable type. let pattern_type = ty::node_id_to_type(self.tcx(), pat.id); let pat_cmt = self.mc.cat_rvalue(pat.id, pat.span, ty::ReScope(blk.id), pattern_type); self.walk_pat(pat_cmt, pat.clone()); </ins> self.walk_block(&**blk); }

Discussion:
loops allow moving out of fixed size arrays. This code compiles and should not compile. segfault with channels I don't know how to make this test case smaller, but... This commit introduces a segfault. Seems bad.
From what I'm seeing here(debugger wise) the problem looks to stem from the call to in the function. Inside we enter the loop, make it through the first unsafe match and then the problem appears to occur in the branch when we try to match again.
Can you describe the system that you're running on as well as the cargo/rustc versions you're using? I've been unable to reproduce the segfault on the most recent nightly on both linux and osx.
Oh sorry, I'm running Windows here. Latest installer version. After restarting into Xubuntu and updating I recompiled there and got a segfault. I get rust from the hansjorg/rust PPA. I'm running off of a Toshiba Satellite L875D-S7210 with an AMD A6-4400M APU. Windows is 64bit and Xubuntu is 32bit.
Ah, found it. Nominating and cc this seems bad and related to the recent removal of for-loop desugaring.
Assigning P-backcompat-lang, 1.0 milestone.
Simpler reproduction (it's not related to fixed sized arrays, updating title):
If you want to see a segfault you have to do something in the loop and iterate twice: This prints 1 and 2, then stalls a bit, then segfaults.
Change:
format!("not allowed after `{}` fragments", frag_spec), ); let msg = "allowed there are: "; <del> match &possible[..] { </del> <ins> match possible { </ins> &[] => {} &[t] => { err.note(&format!(

Discussion:
E.g. in a vec is created, only to be thrown away if the macro actually works out. I think we can just turn most places into an early return in the happy path and then only allocate in the error path. Do not work on this issue before is merged. Also, hasn't had its docs updated to reflect the source changes.
Are there any reasons to not use constant/static slices and convert them to vecs on demand? Or maybe even convert to something like so there's no need to allocate vecs (In all cases) anymore?
That's a great idea! I haven't checked whether it'll work everywhere, but I think it should.
Change:
None => std::env::current_dir().unwrap_or_default(), }; let now: OffsetDateTime = SystemTime::now().into(); <del> let file_now = now.format(&Rfc3339).unwrap_or_default(); </del> <ins> let file_now = now .format( // Don't use a standard datetime format because Windows doesn't support `:` in paths &time::format_description::parse("[year]-[month]-[day]T[hour]_[minute]_[second]") .unwrap(), ) .unwrap_or_default(); </ins> let pid = std::process::id(); path.push(format!("rustc-ice-{file_now}-{pid}.txt")); Some(path)

Discussion:
While investigating the ICE in , I saw that every attempt at writing the ICE details to a file (first implemented in ) would fail on my Windows machine with error messages of this kind: The timestamp format used for the file name separates time components with colons, and Windows is generally finicky about having colons in file names since it is already employed as the drive unit delimiter. Could there be a change in the file name format for better compatibility, at least when running rustc on a Windows host? : </p</details
cc
Yes, we can change the format.
Change:
- name: x86_64-gnu-distcheck os: ubuntu-latest-xl env: {} <del> - name: x86_64-gnu-full-bootstrap os: ubuntu-latest-xl env: {} </del> - name: x86_64-gnu-llvm-8 env: RUST_BACKTRACE: 1

Discussion:
It's clocking in at 20 minutes and seems to be doing nothing -- I suspect that this might be a result of changes to x.py defaults but have not confirmed. We should fix this.
(link to the PR: )
We discussed this during the and agreed to remove the builder. The builder doesn't provide much value for the stability of the project, as it rarely fails and we'd catch any failure it would prevent as soon as we promote nightly to beta.
To fix this issue, the builders needs to be removed from and .
Change:
needs_to_be_read = true; } } <del> PatKind::TupleStruct(..) | PatKind::Path(..) | PatKind::Struct(..) | PatKind::Tuple(..) => { // If the PatKind is a TupleStruct, Path, Struct or Tuple then we want to check // whether the Variant is a MultiVariant or a SingleVariant. We only want // to borrow discr if it is a MultiVariant. // If it is a SingleVariant and creates a binding we will handle that when // this callback gets called again. // Get the type of the Place after all projections have been applied let place_ty = place.place.ty(); if let ty::Adt(def, _) = place_ty.kind() { if def.variants.len() > 1 { </del> <ins> PatKind::Path(qpath) => { // A `Path` pattern is just a name like `Foo`. This is either a // named constant or else it refers to an ADT variant let res = self.mc.typeck_results.qpath_res(qpath, pat.hir_id); match res { Res::Def(DefKind::Const, _) | Res::Def(DefKind::AssocConst, _) => { // Named constants have to be equated with the value // being matched, so that's a read of the value being matched. // // FIXME: We don't actually  reads for ZSTs. </ins> needs_to_be_read = true; } <del> } else { // If it is not ty::Adt, then it should be read needs_to_be_read = true; </del> <ins> _ => { // Otherwise, this is a struct/enum variant, and so it's // only a read if we need to read the discriminant. needs_to_be_read |= is_multivariant_adt(place.place.ty()); } </ins> } } <ins> PatKind::TupleStruct(..) | PatKind::Struct(..) | PatKind::Tuple(..) => { // For `Foo(..)`, `Foo { ... }` and `(...)` patterns, check if we are matching // against a multivariant enum or struct. In that case, we have to read // the discriminant. Otherwise this kind of pattern doesn't actually // read anything (we'll get invoked for the `...`, which may indeed // perform some reads). let place_ty = place.place.ty(); needs_to_be_read |= is_multivariant_adt(place_ty); } </ins> PatKind::Lit(_) | PatKind::Range(..) => { // If the PatKind is a Lit or a Range then we want // to borrow discr.

Discussion:
The following ICE was found migrating . cc which was very similar, but has been fixed. Also found in: - https://crater- <!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Change:
/// the trait `Copy` may not be implemented for this type; field `points` does not implement `Copy` /// ``` /// <ins> /// ## When can my type _not_ be `Copy`? /// /// Some types can't be copied safely. For example, copying `&mut T` would create an aliased /// mutable reference, and copying `String` would result in two attempts to free the same buffer. /// /// Generalizing the latter case, any type implementing `Drop` can't be `Copy`, because it's /// managing some resource besides its own `size_of::<T>()` bytes. /// /// ## When should my type be `Copy`? /// /// Generally speaking, if your type _can_ implement `Copy`, it should. There's one important thing /// to consider though: if you think your type may _not_ be able to implement `Copy` in the future, /// then it might be prudent to not implement `Copy`. This is because removing `Copy` is a breaking /// change: that second example would fail to compile if we made `Foo` non-`Copy`. /// /// ## Derivable /// /// This trait can be used with `#[derive]` if all of its components implement `Copy` and the type /// implements `Clone`. The implementation will copy the bytes of each field using `memcpy`. /// </ins> /// ## How can I implement `Copy`? /// /// There are two ways to implement `Copy` on your type:

Discussion:
I'm using s as keys in a BtreeMap. I have to look up the map ~15 million times per second (10G ethernet line rate). Ipv4Addr cmp() compiles to this on my system (linux x86-64, rustc 1.10.0-nightly ( 2016-05-21)) Which seems kinda inefficient for a thing which is basically u32. I guess part of the reason is the which converts it to an array(!) first. I copied the definition and implemented Ord like this: It's about 10 times faster on my .
Nice find! Want to send a PR for this? Looks like something that'd be more than welcome :)
Change:
<ins> // Copyright 2018 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. trait Deserialize<'de> {} trait DeserializeOwned: for<'de> Deserialize<'de> {} impl<T> DeserializeOwned for T where T: for<'de> Deserialize<'de> {} // Based on this impl, `&'static str` only implements Deserialize<'static>. // It does not implement for<'de> Deserialize<'de>. impl<'de: 'a, 'a> Deserialize<'de> for &'a str {} fn main() { // Then why does it implement DeserializeOwned? This compiles. fn assert_deserialize_owned<T: DeserializeOwned>() {} assert_deserialize_owned::<&'static str>(); //~^ ERROR the requirement `for<'de> 'de : ` is not satisfied // It correctly does not implement for<'de> Deserialize<'de>. //fn assert_hrtb<T: for<'de> Deserialize<'de>>() {} //assert_hrtb::<&'static str>(); } </ins>

Discussion:
This is a regression between rustc 1.20.0 and 1.21.0. 20 correctly rejects this code with the following error.
Tagging P-high because this very much affects Serde.
Same issue using Serde traits: (One possible) output:
Even better, :
Perhaps we can bisect this regression? (e.g., with )
Bisected to correct behavior in nightly-2017-07-07 -- rustc 1.20.0-nightly ( 2017-07-06), incorrect behavior in nightly-2017-07-08 -- rustc 1.20.0-nightly ( 2017-07-07). That range is Looks like
visited for triage. Assigning to
thanks, very helpful!
I think the bug is here: In particular, I think the condition is not strong enough. doesn't consider region annotations, so we probably need to not use this logic if there are any regions. But I'm wondering if the whole concept is flawed. I'm a bit fearful of regions being introduced through associated type normalization.
I have a fix.
Of course, any approach that relies on any lifetimes in the affected trait-ref is fatally flawed - here's an example where the trait ref is the region-free .
I'm not really sure what your example is meant to illustrate. That said, running that on my branch gives an error: This seems like the error I would expect, more or less. We try to use the impl to prove that but we fail to do so (because of the side condition that it adds).
BTW, the check looks like it happened because I used there, and an explicit check when he changed in to note be made true by late-bound regions.
visited for triage. bug seems to be being dealt with, assuming that PR is eventually deemed as passing muster...
Yes, I think that the "no late-bound regions" check was basically a workaround for this same problem; I removed it in the PR since I think it has a "more correct" fix.
Change:
}; if ends_with_stmt { let last_stmt = body.stmts.last().unwrap(); <ins> let original_span = original_sp(last_stmt.span, sp); </ins> let span_semicolon = Span { <del> lo: last_stmt.span.hi, hi: last_stmt.span.hi, expn_info: last_stmt.span.expn_info </del> <ins> lo: original_span.hi - BytePos(1), hi: original_span.hi, expn_info: original_span.expn_info </ins> }; self.ir.tcx.sess.span_note( span_semicolon, "consider removing this semicolon:");

Discussion:
Code: Compilation attempt: It should be pointing at the semi-colon on the next line, not the comma on this line.
The note message was introduced in . It doesn't seem to handle this situation properly.
Change:
} t("`Struct<'a, T>`", "<p><code>Struct&lt;'a, T&gt;</code></p>n"); <del> t("Struct<'a, T>", "<p>Struct&lt;'a, T&gt;</p>n"); </del> <ins> t("Struct<'a, T>", "<p>Struct&lt;’a, T&gt;</p>n"); </ins> t("Struct<br>", "<p>Struct&lt;br&gt;</p>n"); }

Discussion:
Split off from . modify labels: T-rustdoc C-enhancement <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Uh, it looks like rustbot is editing my message and adding weird comments:
Cc
It looks like smart punctuation doesn't work in headers: ! wasn't able to reproduce this in pulldown itself; I'm guessing rustdoc is doing something special with headers. Cc
Triagebot does that as a way of easily storing data per-issue (we could do it in the database now, we didn't have one back then). But it's expected and shouldn't really be a problem.
Is this a good thing? Wouldn't keeping things as it is is better?
I think if you want to argue against doing this, giving reasons would be helpful. I personally think given that we already use emoji and otherwise non-ASCII characters readily, it should be reasonable for us to generate smart quotes as well.
I do think emoji and other non-ASCII characters if specified would be good except for smart quote. It's like saying to use greek question mark which is the same as semi-colon when a semi-colon was seen in documentation to make it look a bit cooler. One thing is copying, when others are copying the text, it will copy the utf-8 version of smart quotes which when displayed in terminals which in turn will make it look ugly and hard for text processing. Auto changing text to emoji I am okay with that. But not automatically changing single quotes, double quotes and semi-colons. Personally I don't see much benefit to that, usually if users want it they would specifically type it out but otherwise it would be similar. In my humble opinion, looks wise the smart quotes are more ugly, but easier to distinguish opening and closing quotes, but still when copied and pasted it may not look so good.
Change:
<ins> // check-pass trait Data { type Elem; } impl<F, S: Data<Elem = F>> Data for ArrayBase<S> { type Elem = F; } struct DatasetIter<'a, R: Data> { data: &'a R::Elem, } pub struct ArrayBase<S> { data: S, } trait Trait { type Item; fn next() -> Option<Self::Item>; } impl<'a, D: Data> Trait for DatasetIter<'a, ArrayBase<D>> { type Item = (); fn next() -> Option<Self::Item> { None } } fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --can't compile linfa, please show me how to fix <!-- 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 is due to . It turns out that skipping over projection goals that we get back from leads to unconstrained infer vars. It's pretty difficult to create a minimal repro of this, though. This isn't fixed by because the infer var is coming from within 's own normalization.
I'll take a look.
Pretty rough, but here's an MCVE. Still can probably minimize a bit more: (edit: updating as I minimize a bit more)
Okay, here's the simplest MCVE I can make:
WG-prioritization assigning priority (). label -I-prioritize +P-high -needs-triage
Change:
base_did: DefId, ) { let struct_path = self.tcx().def_path_str(base_did); <ins> let kind_name = match self.tcx().def_kind(base_did) { Some(def_kind) => def_kind.descr(base_did), _ => " ", }; </ins> let mut err = struct_span_err!( self.tcx().sess, expr.span, E0616, <del> "field `{}` of struct `{}` is private", </del> <ins> "field `{}` of {} `{}` is private", </ins> field, <ins> kind_name, </ins> struct_path ); // Also check if an accessible method exists, which is often what is meant.

Discussion:
() Errors: Notice how it says "struct" when it should say "union". cc this looks like low-hanging fruit
Can I pick this up if no-one is working on this?
go ahead! You need to use here to get whether it is a struct or union using .
Thanks . Newbie question, but how do I test this while development? Do I build the stage1 compiler and then write a sample test?
is the way to get the fastest iteration time. is theoretically suspect but should affect you on what you're working on and is marginally slower on first compile but much faster on subsequent compiles. You rarely (if ever) need .
Change:
/// ``` #[inline] #[stable(feature = "unreachable", since = "1.27.0")] <del> pub unsafe fn unreachable_unchecked() -> ! { </del> <ins> #[rustc_const_unstable(feature = "const_unreachable_unchecked", issue = "53188")] pub const unsafe fn unreachable_unchecked() -> ! { </ins> // SAFETY: the safety contract for `intrinsics::unreachable` must // be upheld by the caller. unsafe { intrinsics::unreachable() }

Discussion:
Currently one cannot call in constant functions, so one cannot add hints of the form: These types of hints can heavily influence code generation, which can substantially change the performance of when they are invoked at run-time. It would be a shame to have to write and call and because the code generated for is sub-par. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
One cannot do any sort of conditional control flow, so would currently be less than useless. Any test you can write would be undefined behaviour
the RFC for / in const was merged and is pending an implementation right? When that's implemented, will still be useless?
No it makes sense after we have conditional control flow.
As I understand / in const functions is now implemented. Can be made into a now?
yes. Basically you just need to add the attribute to the intrinsic and wrapper function. This is documented at https://rustc-dev- Let me know if anything is unclear (in which case we should update the guide)
Hi, It looks like previous PR is not being worked on currently. I'm working on this and will create a PR soon. claim
As mentioned in , this issue should be reopened (to track stablization)
cc ^
After a short discussion on Zulip, it was decided that it's best to wait for to stabilize to avoid a potential footgun wherein users use this instead of , leading to UB at runtime. I'm subscribed to the issue and intend to file a PR to stabilize this once the aforementioned happens.
Change:
<ins> // Copyright 2018 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 gratitude() { let for_you = false; if not for_you { //~^ ERROR unexpected `for_you` after identifier println!("I couldn't"); } } fn qualification() { let the_worst = true; while not the_worst { //~^ ERROR unexpected `the_worst` after identifier println!("still pretty bad"); } } fn should_we() { let not = true; if not  // lack of braces is [sic] println!("Then when?"); //~^ ERROR expected `{`, found `; //~| ERROR unexpected `println` after identifier } fn sleepy() { let resource = not 2; //~^ ERROR unexpected `2` after identifier } fn main() { let be_smothered_out_before = true; let young_souls = not be_smothered_out_before; //~^ ERROR unexpected `be_smothered_out_before` after identifier } </ins>

Discussion:
this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `
Change:
ecx .layout_of(body.return_ty().subst(tcx, substs)) .ok() <del> // Don't bother allocating memory for ZST types which have no values. .filter(|ret_layout| !ret_layout.is_zst()) </del> <ins> // Don't bother allocating memory for ZST types which have no values // or for large values. .filter(|ret_layout| !ret_layout.is_zst() && ret_layout.size < Size::from_bytes(MAX_ALLOC_LIMIT)) </ins> .map(|ret_layout| ecx.allocate(ret_layout, MemoryKind::Stack)); ecx.push_stack_frame(

Discussion:
The following ICEs on beta and nightly: () <details<summarygdb backtrace </summary</details
triage: P-high.

A MSVC x8664 bors job has failed on two unrelated PRs (, ) with the : In both cases, attempted to allocate several GB of memory while compiling the crate. One of these failures was in the job, and the other was in . This failure appears to be spurious: a previous version of passed the same job.
I wonder if we could get a backtrace or something from this allocation -- it seems... suspicious that we're only sometimes OOMing. It's also interesting to note that this is almost exactly 4 GB in a single allocation, which is surprising generally ( is not a big crate -- 300 lines or so, with comments etc).
On my PR it was a different (almost) power of two: edit In both cases, the size of the allocation is 8 bytes less than a power of two.
So I minimized this to: on a recent nightly gives: It looks like the compiler is trying to allocate enough space to store a value of the return type. As long as I use a large enough value it reproduces reliably and it isn't specific to Windows: . I bisected this to and I'm guessing (cc is the root cause.
Yes, that seems likely. I will take a look at this tonight.
should we put on hold while this is sorted out?
Yeah, let's do that just to be safe.
triage: P-high. Removing nomination label.
Change:
<ins> #![feature(doc_cfg)] // @has 'issue_79201/trait.Foo.html' // @count   - '//*[@class="stab portability"]' 6 // @matches - '//*[@class="stab portability"]' 'crate feature foo-root' // @matches - '//*[@class="stab portability"]' 'crate feature foo-public-mod' // @matches - '//*[@class="stab portability"]' 'crate feature foo-private-mod' // @matches - '//*[@class="stab portability"]' 'crate feature foo-fn' // @matches - '//*[@class="stab portability"]' 'crate feature foo-method' pub trait Foo {} #[doc(cfg(feature = "foo-root"))] impl crate::Foo for usize {} #[doc(cfg(feature = "foo-public-mod"))] pub mod public { impl crate::Foo for u8 {} } #[doc(cfg(feature = "foo-private-mod"))] mod private { impl crate::Foo for u16 {} } #[doc(cfg(feature = "foo-const"))] const _: () = { impl crate::Foo for u32 {} }; #[doc(cfg(feature = "foo-fn"))] fn __() { impl crate::Foo for u64 {} } #[doc(cfg(feature = "foo-method"))] impl dyn Foo { fn __() { impl crate::Foo for u128 {} } } </ins>

Discussion:
I tried this code: I expected to see this happen: both impls being highlighted as needing the feature. Instead, this happened: only the impl got the message: ! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: +T-rustdoc
claim