jiebi/CodeConvo huggingface dataset:
Change:
ordered_params += &pprust::bounds_to_string(&bounds); } } <ins> match kind { GenericParamKind::Type { default: Some(default) } => { ordered_params += " = "; ordered_params += &pprust::ty_to_string(default); } GenericParamKind::Type { default: None } => (), GenericParamKind::Lifetime => (), // FIXME(const_generics:defaults) GenericParamKind::Const { ty: _, kw_span: _ } => (), } </ins> first = false; } }

Discussion:
results in: when it should be: This should be easy to fix: just replace in the following line with an appropriate format string. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
For the record, it's not quite this simple, as doing so results in incorrect output when the parameter also has bounds. For example, it would render as because bounds are printed after the
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // xfail-test #6122 </del> <ins> #[feature(managed_boxes)]; </ins> extern mod extra;

Discussion:
The bots are currently failing like so I bisected to , which changes how works.
Closing since I'm almost certain that test is either gone, or passes.
This continues to be a source of breakage on incoming. Right now the failure is in rpass/auto-encode
run-pass/auto-encode is xfailed now
my branch contains a reduced test case under run-pass/issue-6122
incoming has been poofed, so I'm not sure what the status of this is. Bors has been churning away and the tree is green, so does the problem still arise?
The test passes locally for me with some updating. Pushed it to try, will see how it falls.
Change:
impl<'tcx> ProjectionTy<'tcx> { pub fn trait_def_id(&self, tcx: TyCtxt<'tcx>) -> DefId { <del> let parent = tcx.parent(self.item_def_id); assert_eq!(tcx.def_kind(parent), DefKind::Trait); parent </del> <ins> match tcx.def_kind(self.item_def_id) { DefKind::AssocTy | DefKind::AssocConst => tcx.parent(self.item_def_id), DefKind::ImplTraitPlaceholder => { tcx.parent(tcx.impl_trait_in_trait_parent(self.item_def_id)) } kind => bug!("unexpected DefKind in ProjectionTy: {kind:?}"), } </ins> } /// Extracts the underlying trait reference and own substs from this projection.

Discussion:
Based on 's blog posts, I was playing around with RPITIT and dyn Trait. I fully understand that it shouldn't compile :sweat_smile:. It should probably give the same error as you get when is replaced with . Which would be: . Playground: <strongDetails:</strongI started with this code ("shadowing foo" and dot-notation): Which errors with , but recommends the ICE-ing code: . ICE's both on nightly and beta. <details<summary<strongBacktrace 1</strong</summary<p</p</details<details<summary<strongBacktrace 2</strong</summary<p</p</details
the that triggers. Maybe including is enough to fix it?
No, that will just mask the underlying issue.
label +F-returnpositionimpltraitin_trait
Change:
= note: see issue #37854 <https://github.com/rust-lang/rust/issues/37854> for more information = help: add `#![feature(exclusive_range_pattern)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date <ins> = help: use an inclusive range pattern, like N..=M </ins> error: aborting due to 3 previous errors

Discussion:
Came across this when a beginner was very confused about what was wrong with their ; the words "is experimental" and the link to the issue was not sufficient for their discovering what the problem/solution was. The suggested inclusive range pattern doesn't need to contain the actual matching value if producing it is hard or impossible, printing something like is still better than nothing. This issue may of course be ignored/closed if this nightly feature is just about ready to be stabilized or something. No response label +D-terse +C-enhancement +F-exclusiverangepattern <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
/// map.insert(3, "c"); /// map.insert(2, "b"); /// <del> /// // Not possible with .iter() </del> /// let vec: Vec<(uint, &str)> = map.into_iter().collect(); /// /// assert_eq!(vec, vec![(1, "a"), (2, "b"), (3, "c")]); /// ``` #[stable] <del> pub fn into_iter(&mut self) -> IntoIter<V> { </del> <ins> pub fn into_iter(self) -> IntoIter<V> { fn filter<A>((i, v): (uint, Option<A>)) -> Option<(uint, A)> { v.map(|v| (i, v)) } let filter: fn((uint, Option<V>)) -> Option<(uint, V)> = filter; // coerce to fn ptr IntoIter { iter: self.v.into_iter().enumerate().filter_map(filter) } } /// Returns an iterator visiting all key-value pairs in ascending order of /// the keys, emptying (but not consuming) the original `VecMap`. /// The iterator's element type is `(uint, &'r V)`. Keeps the allocated memory for reuse. /// /// # Examples /// /// ``` /// use std::collections::VecMap; /// /// let mut map = VecMap::new(); /// map.insert(1, "a"); /// map.insert(3, "c"); /// map.insert(2, "b"); /// /// let vec: Vec<(uint, &str)> = map.drain().collect(); /// /// assert_eq!(vec, vec![(1, "a"), (2, "b"), (3, "c")]); /// ``` #[unstable = "matches collection reform specification, waiting for dust to settle"] pub fn drain<'a>(&'a mut self) -> Drain<'a, V> { </ins> fn filter<A>((i, v): (uint, Option<A>)) -> Option<(uint, A)> { v.map(|v| (i, v)) } let filter: fn((uint, Option<V>)) -> Option<(uint, V)> = filter; // coerce to fn ptr <del> let values = replace(&mut self.v, vec!()); IntoIter { iter: values.into_iter().enumerate().filter_map(filter) } </del> <ins> Drain { iter: self.v.drain().enumerate().filter_map(filter) } </ins> } /// Return the number of elements in the map.

Discussion:
cc I'm in the process of -ifying the collections, and I've discovered that the takes a instead of the convention of consuming the value. It's also marked stable, even though the type itself is marked unstable. Should this instead be a candidate for the method discussed in the collection reform trait?
Yeah this is just a mistake. Feel free to fix it to match conventions.
Just to be clear, the solution to this is to make consume the value and introduce a function (and iterator). Is this right or am I missing something?
Yep!
Change:
println!("avx512bw: {:?}", is_x86_feature_detected!("avx512bw")); println!("avx512cd: {:?}", is_x86_feature_detected!("avx512cd")); println!("avx512dq: {:?}", is_x86_feature_detected!("avx512dq")); <del> println!("avx512er: {:?}", is_x86_feature_detected!("avx512er")); </del> println!("avx512f: {:?}", is_x86_feature_detected!("avx512f")); println!("avx512ifma: {:?}", is_x86_feature_detected!("avx512ifma")); <del> println!("avx512pf: {:?}", is_x86_feature_detected!("avx512pf")); </del> println!("avx512vbmi2: {:?}", is_x86_feature_detected!("avx512vbmi2")); println!("avx512vbmi: {:?}", is_x86_feature_detected!("avx512vbmi")); println!("avx512vl: {:?}", is_x86_feature_detected!("avx512vl"));

Discussion:
For example, from (And many more.) I think this is due to Should we just drop these from ?
cc
Change:
match binder.no_late_bound_regions() { // If so, this obligation is an error (for now). Eventually we should be // able to support additional cases here, like `for<'a> &'a str: 'a`. <ins> // NOTE: this is duplicate-implemented between here and fulfillment. </ins> None => { ProcessResult::Error(CodeSelectionError(Unimplemented)) }

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:
"lazy_static", "libc", "log", <del> "measureme 9.1.2", </del> <ins> "measureme", </ins> "rand 0.8.5", "regex", "rustc-workspace-hack",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Probably a missing join (these tests are a bit random, now that we have preemption).
Change:
use syntax::ext::base::Determinacy::Undetermined; use syntax::ext::hygiene::Mark; use syntax::ext::tt::macro_rules; <del> use syntax::parse::token; </del> <ins> use syntax::parse::token::{self, Token}; </ins> use syntax::symbol::keywords; use syntax::symbol::Symbol; use syntax::visit::{self, Visitor};

Discussion:
This issue probably needs a better title, perhaps someone more familiar with the compiler's handling of macros can suggest a better one. Some kind of error message, at least. panic with exit code :
Simplified: Same ICE will happen if is changed to ///. Update: Panic happens at this line: has keys and , but the is .
Change:
OutputFilenames { out_directory: out_file.parent().unwrap_or(cur_dir).to_path_buf(), <del> out_filestem: out_file.file_stem().unwrap() </del> <ins> out_filestem: out_file.file_stem().unwrap_or(OsStr::new("")) </ins> .to_str().unwrap().to_string(), single_output_file: ofile, extra: sess.opts.cg.extra_filename.clone(),

Discussion:
I don't think this has been reported yet. I think better error handling in would make this go away.
Change:
<ins> // Copyright 2014 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. // Test structs with always-unsized fields. use std::mem; use std::raw; struct Foo<T> { f: [T], } struct Bar { f1: uint, f2: [uint], } struct Baz { f1: uint, f2: str, } trait Tr { fn foo(&self) -> uint; } struct St { f: uint } impl Tr for St { fn foo(&self) -> uint { self.f } } struct Qux<'a> { f: Tr+'a } pub fn main() { let _: &Foo<f64>; let _: &Bar; let _: &Baz; let _: Box<Foo<i32>>; let _: Box<Bar>; let _: Box<Baz>; let _ = mem::size_of::<Box<Foo<u8>>>(); let _ = mem::size_of::<Box<Bar>>(); let _ = mem::size_of::<Box<Baz>>(); unsafe { struct Foo_<T> { f: [T, ..3] } let data = box Foo_{f: [1i32, 2, 3] }; let x: &Foo<i32> = mem::transmute(raw::Slice { len: 3, data: &*data }); assert!(x.f.len() == 3); assert!(x.f[0] == 1); assert!(x.f[1] == 2); assert!(x.f[2] == 3); struct Baz_ { f1: uint, f2: [u8, ..5], } let data = box Baz_{ f1: 42, f2: ['a' as u8, 'b' as u8, 'c' as u8, 'd' as u8, 'e' as u8] }; let x: &Baz = mem::transmute( raw::Slice { len: 5, data: &*data } ); assert!(x.f1 == 42); let chs: Vec<char> = x.f2.chars().collect(); assert!(chs.len() == 5); assert!(chs[0] == 'a'); assert!(chs[1] == 'b'); assert!(chs[2] == 'c'); assert!(chs[3] == 'd'); assert!(chs[4] == 'e'); struct Qux_ { f: St } let obj: Box<St> = box St { f: 42 }; let obj: &Tr = &*obj; let obj: raw::TraitObject = mem::transmute(&*obj); let data = box Qux_{ f: St { f: 234 } }; let x: &Qux = mem::transmute(raw::TraitObject { vtable: obj.vtable, data: mem::transmute(&*data) }); assert!(x.f.foo() == 234); } } </ins>

Discussion:
cc
This should be a compiler error, not an ICE. The error is (or should be) that is unsized, but is not a bare .
Why would this be an error? Isn't enabling this kind of code part of the goal of DST?
Not quite. We want to allow struct's last field to be potentially unsized, but it must be possible to have a sized version too. This is because only sized types can be instantiated. Since there is no possible sized version of , it cannot be instantiated and should be an error.
Hm, I see. This is kinda unfortunate though, because you can't hide away the actual slice type from your wrapper. Eg, you could do But that widens your wrapper to possibly be instantiated with more than and . Maybe allow a struct definition like but to use it you need to transmute something like ? As an aside, the example in this issue would probably not work anyway, as the stride should presumably be stored per pointer, and not once in the target matrices backing memory. But this is till relevant for newtype wrappers around , eg a hypothetical
Change:
<ins> // check-pass trait Bar<'a> { type Assoc: 'static; } impl<'a> Bar<'a> for () { type Assoc = (); } struct ImplsStatic<CG: Bar<'static>> { d: &'static <CG as Bar<'static>>::Assoc, } fn caller(b: ImplsStatic<()>) where for<'a> (): Bar<'a> { let _: &<() as Bar<'static>>::Assoc = b.d; } 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. --<!-- 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 one works okay:
This one also (Just proxying a type, that means that something strange with struct's generics):
Bisected to but it probably just bubbles up a pre-existing issue that the OP could be massaged to emit without this PR, cc author just in case.
This worked fine before 1.70.0 so it's a regression.
minimized
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Once this will be fixed.
Change:
ext::log_syntax::expand_syntax_ext)); syntax_expanders.insert(intern("derive"), Decorator(box ext::deriving::expand_meta_derive)); <ins> syntax_expanders.insert(intern("deriving"), Decorator(box ext::deriving::expand_deprecated_deriving)); </ins> if ecfg.enable_quotes { // Quasi-quoting expanders

Discussion:
I've got bitten by: The compiler silently accepts this code, no warning at all, but nothing is derived. (rustc 1.0.0-nightly ( 2015-01-08 17:03:40 -0800))
I get two warnings with a more recent nightly ():
I tried playpen just now: And the output gives: I think it is a clear warning which is good enough.
If one uses the type in a place that needs the derived trait, one will get type errors before any of those warnings appear. E.g.
I've updated to rustc 1.0.0-nightly ( 2015-01-14 00:41:55 +0000). I'm getting same error as Even though it shows an error, I think this is a problem, because it shows a wrong, misleading error — the problem isn't in the line where value is copied. It's in the line which has been ignored. Because of that I've been pulling my hair out and tripple-checking all borrows in my program, documentation etc. and wondering why correctly-looking code does't work.
Change:
) -> hir::ExprKind<'hir> { let outer_decl = FnDecl { inputs: decl.inputs.clone(), output: FnRetTy::Default(fn_decl_span) }; <del> // We need to lower the declaration outside the new scope, because we // have to conserve the state of being inside a loop condition for the // closure argument types. let fn_decl = self.lower_fn_decl(&outer_decl, None, false, None); self.with_new_scopes(move |this| { </del> <ins> let body_id = self.with_new_scopes(|this| { </ins> // FIXME(cramertj): allow `async` non-`move` closures with arguments. if capture_clause == CaptureBy::Ref && !decl.inputs.is_empty() { struct_span_err!(

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. --<!-- 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
Doesn't ICE on stable or beta label: regression-from-stable-to-nightly
searched nightlies: from nightly-2020-11-25 to nightly-2020-11-29 regressed nightly: nightly-2020-11-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsMaybe ?
Assigning and removing as in the prioritization working group.
- would you be up for fixing this bug or temporarily reverting PR presuming it is the cause?
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-69310-array-size-lit-wrong-ty.rs:10:15 | LL | const A: [(); 0.1] = [()]; |               ^^^ expected `usize`, found floating-point number error[E0308]: mismatched types --> $DIR/issue-69310-array-size-lit-wrong-ty.rs:11:15 | LL | const B: [(); b"a"] = [()]; |               ^^^^ expected `usize`, found `&[u8; 1]` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on and , but not on . <details<summaryNightly backtrace</summary</details
triage: P-high, assigning to self.
(This ended up being a great motivation for me to tie off some work I've been doing...)
ICE was introduced between nightly 2020-01-15 and 2010-01-16. Here are the merges from that time period: ( is independently working to identify which one is the culprit.)
Okay finished: searched nightlies: from nightly-2020-01-15 to nightly-2020-01-22 regressed nightly: nightly-2020-01-16 searched commits: from to regressed commit:
Looks like the problem was injected by PR
reassigning to
The following also causes an ICE: (Same reason, but different message.)
Fixed by
Change:
<ins> fn main() { let x = 8u8; let z: *const u8 = &x; println!("{}", z.to_string());  //~ ERROR E0599 } </ins>

Discussion:
When trying to call a method on a raw pointer Rust compiler says there's no such method. It would be better to say that there is such method, but the pointer has to be explicitly dereferenced first. This is technically correct, but unexpected and help hint for this error suggests wrong solution. I've read this message as "yada yada no such method", so I went to check whether I've spelled the method correctly, whether I've put the method in the appropriate block, etc. — all completely irrelevant to this error. I'd find something like that more helpful:
, though. The best we could do here is to add some logic in trait suggestion mechanism to check whether traits for dereferenced values exist. Something along the lines of Too many help messages will overwhelm messages that actually matter, though.
Triage: no change
Triage: the error message has improved /
To suggest it would have to suggest , which is taking the suggestions a bit far. We could add a note though.
Change:
mut ty: Ty<'tcx>, normalize: impl Fn(Ty<'tcx>) -> Ty<'tcx>, ) -> Ty<'tcx> { <del> loop { </del> <ins> for iteration in 0.. { if !self.sess.recursion_limit().value_within_limit(iteration) { return self.ty_error_with_message( DUMMY_SP, &format!("reached the recursion limit finding the struct tail for {}", ty), ); } </ins> match *ty.kind() { ty::Adt(def, substs) => { if !def.is_struct() {

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: Running does not terminate after a long time. After running for 4 minutes, the process is using 99.2% CPU and about 80 MB memory. <!-- 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.

--:
The following also hangs, though a diagnostic is first emitted:
The hang seems to happen in
I have modified to detect simple cycles like these to obtain a backtrace: <details</details
More minimal example: This one demonstrates that it's a regression, it errors out immediately on 1.35 but hangs on 1.36.
searched toolchains nightly-2019-04-09 through nightly-2019-05-22 Regression in nightly-2019-04-24 found 9 bors merge commits in the specified range commit[0] 2019-04-22UTC: Auto merge of - varkor:tidy-leading-newline, r=alexcrichton commit[1] 2019-04-22UTC: Auto merge of - estebank:continue-eval, r=oli-obk commit[2] 2019-04-23UTC: Auto merge of - euclio:pulldown-cmark, r=GuillaumeGomez commit[3] 2019-04-23UTC: Auto merge of - davazp:fix-sync-all-macos, r=KodrAus commit[4] 2019-04-23UTC: Auto merge of - varkor:tidy-double-trailing-newline, r=kennytm commit[5] 2019-04-23UTC: Auto merge of - estebank:continue-evaluating, r=oli-obk commit[6] 2019-04-23UTC: Auto merge of - stepnivlk:visit_subpats-removal, r=varkor commit[7] 2019-04-23UTC: Auto merge of - davidtwco:issue-, r=oli-obk commit[8] 2019-04-23UTC: Auto merge of - Centril:rollup-akw4r85, r=Centril Probably ? I guess the compiler used to abort early after the recursive type error but now doesn't and hangs because later code assumes structs aren't recursive. label regression-from-stable-to-stable
cc - maybe something similar is necessary here?
What did was stop doing that (aborting early if there's an error) for .

Seems a bit drastic to revert that (making the compiler unable to report other, later errors until the recursive type is fixed) for this - I think we can do something more targeted.
Perhaps the recursive field could be replaced by a ?
Assigning and removing as .20leads.20to.20infinite.20loop) in the prioritization working group.
This issue have been also reported in .
Change:
let prefix = default_path(&builder.config.prefix, "/usr/local"); let sysconfdir = prefix.join(default_path(&builder.config.sysconfdir, "/etc")); let datadir = prefix.join(default_path(&builder.config.datadir, "share")); <del> let docdir = prefix.join(default_path(&builder.config.docdir, "share/doc")); </del> <ins> let docdir = prefix.join(default_path(&builder.config.docdir, "share/doc/rust")); </ins> let mandir = prefix.join(default_path(&builder.config.mandir, "share/man")); let libdir = prefix.join(default_path(&builder.config.libdir, "lib")); let bindir = prefix.join(&builder.config.bindir); // Default in config.rs

Discussion:
I tried this command: I expected to see files installed to Instead, I see files installed to This worked on Rust 1.49, and I noticed the change in testing the Rust 1.50 pre-release. I'm going ahead to call this stable-to-stable since 1.50 is imminent. modify labels: +regression-from-stable-to-stable -regression-untriaged The specific change appears to be commit from , a backport of from , where the default install changed from "share/doc/rust" to just "share/doc". cc Also note that still documents that the default is "share/doc/rust".
labeling to as per sibling PR