jiebi/CodeConvo huggingface dataset:
Change:
Uncommenting the features and running in Nightly makes the complaints about unstable features go away while the panick stays. ~I’m not sure yet how to make a smaller example out of this.~ smaller examples in comments below This code was a step of me trying out if I could turn into a trait to get method syntax. () Errors:
Minimized:
Ah, neat, so it has nothing to do with closures or Fn traits.
T-compiler triage: I'm going to assume from 's self-assignment that this does not require discussion at T-compiler meeting. Removing I-nominated label.
Are nested type-alias-impl-traits even allowed by the RFC? If not, we should check and emit an error we we construct the type.
They are
any ideas how I can get my original example running though? I was starting with this function (which does compile) and wanted to give a name to its return type. The straightforward approach seems to be But the compiler is still unhappy with lifetimes currently, after your fix. I'm getting the following. At least it works without the lifetimes (i.e. after removing parametrization over 'a and replacing all occurrences of 'a with 'static).
Also I'm now (self-compiled master with the fix) getting a panic on this (admittedly incorrect) program: which didn't panic on the latest nightly (2020-02-13). Edit: I double checked: the behavior changes precisely over your 2 commits. Message is:
Can you open separate issues for each of those problems?
Okay, done ^^ (, )

Discussion:
Some(tcx.closure_base_def_id(def_id)) } Node::Item(item) => match item.kind { <del> ItemKind::OpaqueTy(hir::OpaqueTy { impl_trait_fn, .. }) => impl_trait_fn, </del> <ins> ItemKind::OpaqueTy(hir::OpaqueTy { impl_trait_fn, .. }) => { impl_trait_fn.or_else(|| { let parent_id = tcx.hir().get_parent_item(hir_id); if parent_id != hir_id && parent_id != CRATE_HIR_ID { debug!("generics_of: parent of opaque ty {:?} is {:?}", def_id, parent_id); // If this 'impl Trait' is nested inside another 'impl Trait' // (e.g. `impl Foo<MyType = impl Bar<A>>`), we need to use the 'parent' // 'impl Trait' for its generic parameters, since we can reference them // from the 'child' 'impl Trait' if let Node::Item(hir::Item { kind: ItemKind::OpaqueTy(..), .. }) = tcx.hir().get(parent_id) { Some(tcx.hir().local_def_id(parent_id)) } else { None } } else { None } }) } </ins> _ => None, }, _ => None,

<ins> // check-pass // Regression test for issue #67844 // Ensures that we properly handle nested TAIT occurences // with generic parameters #![feature(type_alias_impl_trait)] trait WithAssoc { type AssocType; } trait WithParam<A> {} type Return<A> = impl WithAssoc<AssocType = impl WithParam<A>>; struct MyParam; impl<A> WithParam<A> for MyParam {} struct MyStruct; impl WithAssoc for MyStruct { type AssocType = MyParam; } fn my_fun<A>() -> Return<A> { MyStruct } fn my_other_fn<A>() -> impl WithAssoc<AssocType = impl WithParam<A>> { MyStruct } fn main() {} </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. 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! cc the PR reviewer, and nominating for compiler team prioritization.

Discussion:
<del> Subproject commit d9e38f57c125c5ac50397ec8a006fe49f17cd96c </del> <ins> Subproject commit 732825dcff6d1f115225305ce5e0c9c9d876a0ff </ins>
Change:
Associated types are types and thus should be capitalized. I think most code also does this. Recently I accidentally didn't capitalize it and was surprised that it doesn't lint for it: I'd expect it to say something. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
checking happens inside , add for , then inspect the kind of inside this checking.
I'd like to put my hand up for this if that's alright? It looks like a good one to get started on. claim

Discussion:
} } <ins> fn check_trait_item(&mut self, cx: &EarlyContext<'_>, it: &ast::AssocItem) { if let ast::AssocItemKind::TyAlias(..) = it.kind { self.check_case(cx, "associated type", &it.ident); } } </ins> fn check_variant(&mut self, cx: &EarlyContext<'_>, v: &ast::Variant) { self.check_case(cx, "variant", &v.ident); }

// check-pass #![allow(dead_code)] <ins> #![allow(non_camel_case_types)] </ins> // pretty-expanded FIXME #23616 trait Person {

// run-pass <ins> #![allow(non_camel_case_types)] </ins> #![allow(unused_variables)] trait Foo { type bar; fn bar();

} trait foo6 { //~ ERROR trait `foo6` should have an upper camel case name <ins> type foo7; //~ ERROR associated type `foo7` should have an upper camel case name </ins> fn dummy(&self) { } }

LL | trait foo6 { |       ^^^^ help: convert the identifier to upper camel case (notice the capitalization): `Foo6` <ins> error: associated type `foo7` should have an upper camel case name --> $DIR/lint-non-camel-case-types.rs:26:10 | LL |     type foo7; |          ^^^^ help: convert the identifier to upper camel case (notice the capitalization): `Foo7` </ins> error: type parameter `ty` should have an upper camel case name <del> --> $DIR/lint-non-camel-case-types.rs:29:6 </del> <ins> --> $DIR/lint-non-camel-case-types.rs:30:6 </ins> | LL | fn f<ty>(_: ty) {} |      ^^ help: convert the identifier to upper camel case: `Ty` <del> error: aborting due to 8 previous errors </del> <ins> error: aborting due to 9 previous errors </ins>
Change:
The following ICE's on stable, beta and nightly: <details<summaryBacktrace:</summary</detailsPossibly related to , except with a different ICE message.
The bug here should be delayed:
triage: P-medium, removing I-nominated label.

Discussion:
let param_env = tcx.param_env(src.def_id()).with_reveal_all(); let move_data = match MoveData::gather_moves(body, tcx, param_env) { Ok(move_data) => move_data, <del> Err(_) => bug!("No `move_errors` should be allowed in MIR borrowck"), </del> <ins> Err((move_data, _)) => { tcx.sess.delay_span_bug( body.span, "No `move_errors` should be allowed in MIR borrowck", ); move_data } </ins> }; let elaborate_patch = { let body = &*body;

<ins> struct Bug { A: [(); { *"" }.len()], //~^ ERROR: cannot move a value of type str //~| ERROR: cannot move out of a shared reference } fn main() {} </ins>

<ins> error[E0161]: cannot move a value of type str: the size of str cannot be statically determined --> $DIR/issue-67947.rs:2:13 | LL |     A: [(); { *"" }.len()], |             ^^^^^^^ error[E0507]: cannot move out of a shared reference --> $DIR/issue-67947.rs:2:15 | LL |     A: [(); { *"" }.len()], |               ^^^ move occurs because value has type `str`, which does not implement the `Copy` trait error: aborting due to 2 previous errors Some errors have detailed explanations: E0161, E0507. For more information about an error, try `rustc --explain E0161`. </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. 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! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium, removing I-nominated label.

Discussion:
<del> Subproject commit e8642c7a2900bed28003a98d4db8b62290ac802f </del> <ins> Subproject commit 43ac9416d935942d6c7d2b2e0c876c551652c4ec </ins>
Change:
Test case: I left it compiling for just over half an hour, and it sat at constant memory usage and 100% of a CPU core for the entire time. Originally tested on . Checking through some different versions, these all take over a minute (I didn't bother sitting around for the full 30 minutes): Going back a little further it works and compiles in about a second on: Going back even further it ICEs with on: (this may be a duplicate of one of the existing large array compile time issues, but I didn't find one it fit exactly with, especially given it worked on at least two stable releases).
I've tried to compile this with , but it's been running for two hours and it didn't complete, so I had to cut it off. Maybe someone else can try? I think my computer is getting old :D So I tried compiling using the compiler for the last commit (installed with ): Here's what I got: <details<summary<strongStandard output</strong(if that even matters)</summary<p</p</details<details<summary<strongStandard error</strong</summary<p</p</detailsThis last line: Is emitted in here: So I believe this is a const eval bug? cc do you have any idea what may be happening?
Hm, not off the top of my head. Cc I take it it keeps going after that last line without outputting anything any more? Then that's just the last thing it completed, which might or might not have anything to do with the next thing it is doing. Could you use to capture a backtrace of what code it is running then? (Let me know if you need help with that.)
is the LLDB output for the command with latest nightly ().
Okay so this is interning walking every single field of that array... and taking forever to do that, obviously.
Letting it run a bit longer gave me an additional frame:
How did you originally find this? Did it impact a real code you had?
Assigning .
the context was , I was just trying to find out whether you could have a ZST array with length , so no, not real code.
Alright, it is fine being then
For arrays and slices we could make interning check the relocation map for relocations within the array, compute the indices which have relocations and only look at those indices. This way we don't have to walk all elements, but only those that interning cares about. Not sure what validation will do after interning is finished, maybe that'll also run forever? I thought we had some optimizations in there. Oh yea, and interning can skip any zst type in general.

Discussion:
return walked; } } <ins> // ZSTs do not need validation unless they're uninhabited if mplace.layout.is_zst() && !mplace.layout.abi.is_uninhabited() { return Ok(()); } </ins> self.walk_aggregate(mplace, fields) }

<ins> // build-pass fn main() { println!("{}", [(); std::usize::MAX].len()); } </ins>
Change:
Problematic code: Minimal reproduction: This ICE happens on both nightly and stable. rustc 1.42.0-nightly ( 2020-01-06) binary: rustc commit-hash: commit-date: 2020-01-06 host: x86_64-unknown-linux-gnu release: 1.42.0-nightly LLVM version: 9.0 Backtrace:
I'm not sure how to reproduce the ICE given the two snippets at the top. Can you clarify the minimal reproduction: how do I reproduce it in the playground?
Simplified:
The failure occurs here: I guess we can add to first arm (), is it safe?
triage: P-high. Removing I-nominated label.

Discussion:
//! `ExprUseVisitor` determines how expressions are being used. pub use self::ConsumeMode::*; <del> use self::OverloadedCallType::*; </del> // Export these here so that Clippy can use them. pub use mc::{Place, PlaceBase, Projection};

WriteAndRead, // x += y } <del> #[derive(Copy, Clone)] enum OverloadedCallType { FnOverloadedCall, FnMutOverloadedCall, FnOnceOverloadedCall, } impl OverloadedCallType { fn from_trait_id(tcx: TyCtxt<'_>, trait_id: DefId) -> OverloadedCallType { for &(maybe_function_trait, overloaded_call_type) in &[ (tcx.lang_items().fn_once_trait(), FnOnceOverloadedCall), (tcx.lang_items().fn_mut_trait(), FnMutOverloadedCall), (tcx.lang_items().fn_trait(), FnOverloadedCall), ] { match maybe_function_trait { Some(function_trait) if function_trait == trait_id => return overloaded_call_type, _ => continue, } } bug!("overloaded call didn't map to known function trait") } fn from_method_id(tcx: TyCtxt<'_>, method_id: DefId) -> OverloadedCallType { let method = tcx.associated_item(method_id); OverloadedCallType::from_trait_id(tcx, method.container.id()) } } </del> /////////////////////////////////////////////////////////////////////////// // The ExprUseVisitor type //

hir::ExprKind::Call(ref callee, ref args) => { // callee(args) <del> self.walk_callee(expr, callee); </del> <ins> self.consume_expr(callee); </ins> self.consume_exprs(args); }

} } <del> fn walk_callee(&mut self, call: &hir::Expr<'_>, callee: &hir::Expr<'_>) { let callee_ty = return_if_err!(self.mc.expr_ty_adjusted(callee)); debug!("walk_callee: callee={:?} callee_ty={:?}", callee, callee_ty); match callee_ty.kind { ty::FnDef(..) | ty::FnPtr(_) => { self.consume_expr(callee); } ty::Error => {} _ => { if let Some(def_id) = self.mc.tables.type_dependent_def_id(call.hir_id) { match OverloadedCallType::from_method_id(self.tcx(), def_id) { FnMutOverloadedCall => { self.borrow_expr(callee, ty::MutBorrow); } FnOverloadedCall => { self.borrow_expr(callee, ty::ImmBorrow); } FnOnceOverloadedCall => self.consume_expr(callee), } } else { self.tcx() .sess .delay_span_bug(call.span, "no type-dependent def for overloaded call"); } } } } </del> fn walk_stmt(&mut self, stmt: &hir::Stmt<'_>) { match stmt.kind { hir::StmtKind::Local(ref local) => {

<ins> // check-pass fn foo<F, G>(_: G, _: Box<F>) where F: Fn(), G: Fn(Box<F>), { } fn main() { foo(|f| (*f)(), Box::new(|| {})); } </ins>
Change:
This code () Produces ICE on any channel
This is the same issue as , attributes on expressions are not converted into HIR properly.
I checked on latest nightly - isn't produced anymore while this one still throws ICE.
could you reopen this issue?
triage: P-high. Removing nomination.
Reduced somewhat:

Discussion:
} else if attr.check_name(sym::thread_local) { codegen_fn_attrs.flags |= CodegenFnAttrFlags::THREAD_LOCAL; } else if attr.check_name(sym::track_caller) { <del> if tcx.fn_sig(id).abi() != abi::Abi::Rust { </del> <ins> if tcx.is_closure(id) || tcx.fn_sig(id).abi() != abi::Abi::Rust { </ins> struct_span_err!(tcx.sess, attr.span, E0737, "`#[track_caller]` requires Rust ABI") .emit(); }

codegen_fn_attrs.export_name = Some(s); } } else if attr.check_name(sym::target_feature) { <del> if tcx.fn_sig(id).unsafety() == Unsafety::Normal { </del> <ins> if tcx.is_closure(id) || tcx.fn_sig(id).unsafety() == Unsafety::Normal { </ins> let msg = "`#[target_feature(..)]` can only be applied to `unsafe` functions"; tcx.sess .struct_span_err(attr.span, msg)

<ins> // build-fail #![feature(track_caller)] fn main() { (0..) .map( #[target_feature(enable = "")] //~^ ERROR: the feature named `` is not valid for this target //~| ERROR: `#[target_feature(..)]` can only be applied to `unsafe` functions #[track_caller] //~^ ERROR: `#[track_caller]` requires Rust ABI |_| (), ) .next(); } </ins>

<ins> error: `#[target_feature(..)]` can only be applied to `unsafe` functions --> $DIR/issue-68060.rs:8:13 | LL |             #[target_feature(enable = "")] |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can only be applied to `unsafe` functions ... LL |             |_| (), |             ------ not an `unsafe` function error: the feature named `` is not valid for this target --> $DIR/issue-68060.rs:8:30 | LL |             #[target_feature(enable = "")] |                              ^^^^^^^^^^^ `` is not valid for this target error[E0737]: `#[track_caller]` requires Rust ABI --> $DIR/issue-68060.rs:11:13 | LL |             #[track_caller] |             ^^^^^^^^^^^^^^^ error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0737`. </ins>
Change:
The following takes approximately one year to compile: (This estimate was derived from observing that compile time scales seemingly exponentially in the depth of the instantiated closure. At level 23 it took about 25 seconds, and at 22 only 13. Extrapolating this doubling-per-depth leads us to about a year at level 43 which is depicted above).
Flamegraph:
Yields: cc

Discussion:
where T: Relate<'tcx>, { <del> self.fields.higher_ranked_sub(a, b, self.a_is_expected)?; self.fields.higher_ranked_sub(b, a, self.a_is_expected) </del> <ins> if a.skip_binder().has_escaping_bound_vars() || b.skip_binder().has_escaping_bound_vars() { self.fields.higher_ranked_sub(a, b, self.a_is_expected)?; self.fields.higher_ranked_sub(b, a, self.a_is_expected) } else { // Fast path for the common case. self.relate(a.skip_binder(), b.skip_binder())?; return Ok(a.clone()); } </ins> } }

b = self.infcx.shallow_resolve(b); } <ins> if a == b { return Ok(a); } </ins> match (&a.kind, &b.kind) { (_, &ty::Infer(ty::TyVar(vid))) => { if D::forbid_inference_vars() {

debug!("binders({:?}: {:?}, ambient_variance={:?})", a, b, self.ambient_variance); <ins> if !a.skip_binder().has_escaping_bound_vars() && !b.skip_binder().has_escaping_bound_vars() { // Fast path for the common case. self.relate(a.skip_binder(), b.skip_binder())?; return Ok(a.clone()); } </ins> if self.ambient_covariance() { // Covariance, so we want `for<..> A <: for<..> B` -- // therefore we compare any instantiation of A (i.e., A

<ins> // Check that this can be compiled in a reasonable time. // build-pass fn main() { // 96 nested closures let x = (); || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || || [&(), &x]; } </ins>
Change:
Currently with const generics you can create a "specialized" implementation, such as: Which has the following output: (playground link: ) However, when using such a type in another crate this causes a stack overflow in the compiler. For example, with the following code (full example: ): I would expect it to produce the same output as the playground link above, however it produces the following:
A bisect shows this stopped crashing after , marked as needing a test
I was still encountering this in my code with and after trying to minimize it seems that the original example is fixed but the stack overflow still occurs when the const expression in the has braces around it. After experimenting I found some more examples of what works and what doesn't: (see to try it) compiles and runs successfully while and (or ) crash the compiler with the same error as the original: :

Discussion:
impl EntryKind { fn def_kind(&self) -> DefKind { match *self { <ins> EntryKind::AnonConst(..) => DefKind::AnonConst, </ins> EntryKind::Const(..) => DefKind::Const, EntryKind::AssocConst(..) => DefKind::AssocConst, EntryKind::ImmStatic

fn mir_const_qualif(&self, id: DefIndex) -> mir::ConstQualifs { match self.kind(id) { <del> EntryKind::Const(qualif, _) </del> <ins> EntryKind::AnonConst(qualif, _) | EntryKind::Const(qualif, _) </ins> | EntryKind::AssocConst( AssocContainer::ImplDefault | AssocContainer::ImplFinal

fn get_rendered_const(&self, id: DefIndex) -> String { match self.kind(id) { <del> EntryKind::Const(_, data) | EntryKind::AssocConst(_, _, data) => data.decode(self).0, </del> <ins> EntryKind::AnonConst(_, data) | EntryKind::Const(_, data) | EntryKind::AssocConst(_, _, data) => data.decode(self).0, </ins> _ => bug!(), } }

let const_data = self.encode_rendered_const_for_body(body_id); let qualifs = self.tcx.mir_const_qualif(def_id); <del> record!(self.tables.kind[def_id.to_def_id()] <- EntryKind::Const(qualifs, const_data)); </del> <ins> record!(self.tables.kind[def_id.to_def_id()] <- EntryKind::AnonConst(qualifs, const_data)); </ins> record!(self.tables.visibility[def_id.to_def_id()] <- ty::Visibility::Public); record!(self.tables.span[def_id.to_def_id()] <- self.tcx.def_span(def_id)); self.encode_item_type(def_id.to_def_id());

#[derive(Copy, Clone, RustcEncodable, RustcDecodable)] enum EntryKind { <ins> AnonConst(mir::ConstQualifs, Lazy<RenderedConst>), </ins> Const(mir::ConstQualifs, Lazy<RenderedConst>), ImmStatic, MutStatic,

<ins> #![feature(const_generics)] pub struct Num<const N: usize>; // Braces around const expression causes crash impl Num<{5}> { pub fn five(&self) { } } </ins>

<ins> // aux-build:impl-const.rs // run-pass #![feature(const_generics)] #![allow(incomplete_features)] extern crate impl_const; use impl_const::*; pub fn main() { let n = Num::<5>; n.five(); } </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. 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! cc the PR reviewer, and nominating for compiler team prioritization.

Discussion:
<del> Subproject commit 43ac9416d935942d6c7d2b2e0c876c551652c4ec </del> <ins> Subproject commit 920cdb59e1edf2c4cb2f266fa521f12c1b97a499 </ins>
Change:
currently calls on the inner iterator but that can overflow even if the itself doesn't return more that items. For example: This should return but currently triggers an (or returns if overflow checks are disabled). This is caused by which was in which was merged between versions 1.0 and 1.1.
This could probably be fixed by calling and then relying on .
I think it doesn't fix because is very slow, right?
Should be overridden for ranges though.

Discussion:
} #[inline] <del> fn count(self) -> usize { self.iter.count().saturating_sub(self.n) </del> <ins> fn count(mut self) -> usize { if self.n > 0 { // nth(n) skips n+1 if self.iter.nth(self.n - 1).is_none() { return 0; } } self.iter.count() </ins> } #[inline]

<ins> // run-pass // only-32bit too impatient for 2⁶⁴ items // compile-flags: -C overflow-checks -C opt-level=3 fn main() { let i = (0..usize::max_value()).chain(0..10).skip(usize::max_value()); assert_eq!(i.count(), 10); } </ins>
Change:
<!-- Thanks for filing a bug report ! --Problem <!-- A clear and concise description of what the bug is. --<!-- including what currently happens and what you expected to happen. --It is possible to run tests for various targets using . When given an invalid triple, cargo indicates the user should run for help. However, this is not valid advice. Steps <!-- The steps to reproduce the bug. --the suggested Possible Solution(s) <!-- Not obligatory, but suggest a fix/reason for the bug, --<!-- or ideas how to implement the addition or change --cargo should implement , or the advice should be removed. Notes Output of : cargo 1.40.0 ( 2019-11-22) <!-- Also, any additional context or information you feel may be relevant to the issue. --<!-- (e.g rust version, OS platform/distribution/version, target toolchain(s), release channel.. --$ cargo test --target invalid-target error: failed to run to learn about target-specific information Caused by: process didn't exit successfully: (exit code: 1) --- stderr error: Error loading target specification: Could not find specification for target "invalid-target" | = help: Use for a list of built-in targets $ cargo test --print target-list error: Found argument '--print' which wasn't expected, or isn't valid in this context USAGE: test [OPTIONS] [TESTNAME] [-- <args...] For more information try --help $ ...
This can be confusing but cctually just prints what is saying via :
Yea, this message is printed by , so I have moved this to the rust issue tracker. It seems reasonable to me that it should include before the flag, though maybe the diagnostic people have further thoughts.

Discussion:
opts.error_format, &format!( "Error loading target specification: {}.  <del> Use `--print target-list` for a list of built-in targets", </del> <ins> Run `rustc --print target-list` for a list of built-in targets", </ins> e ), )