jiebi/CodeConvo huggingface dataset:
Change:
pub crate_name: String, pub deriving_hash_type_parameter: bool, pub enable_quotes: bool, <ins> pub recursion_limit: uint, </ins> } impl ExpansionConfig {

Discussion:
Defining macros recursively like so will lead rustc to cause a stack overflow. It would be useful to improve the error message for that problem. There is currently no error message specified for that issue.
We already have a field in . We can copy it to libsyntax's and then track the recursion depth in .
I am looking into this issue. Howerver it seems like the same and are used for macro expansion, so it seems like recursion depth cannot be tracked naively.
The methods and already maintain a sort of stack of macro invocations. They can also maintain a counter so that we don't have to walk that stack on every check (it's a kind of indirect linked list).
Now that recursion depth is limited, is there anyway to configure it from the command line? The current depth setting (64?) is too aggressive for some macro magic I am working on, that recurses heavily.
I could at least increase it to 256 if that would help. Other than that someone else ( maybe) should look into it.
My patch did not include any method to customize the depth limit. I just used 64 because defaults to that as well. I am not aware of a command line interface to change session attributes, but I am not very familiar with rustc`s command line interface. Another way to customize the recursion depth for macro expansions could be using something like for macros which result in deeper recursions, but no in an infinite recursion. Anyhow, if there is a decision to do it one way or another, I'd be happy to work on a patch.
Could we at least for now bump the limit up to something much larger? The current setting of 64 is probably too low for macros that rely on reduction rules. (ie that match a portion of a statement and pass the remainder to another macro (often itself) for further expansion). I don't have a good handle on the expense of each macro expansion in terms of compiler memory/time ... but is there any reason for it not to be a number on a much larger scale, such as 1024?
I like the idea of a file/crate attribute to govern the recursion depth of macros expanded within that crate.
I will try to increase it to 2048. Someone else should maybe look into the attribute or command line argument thing.
Seems that 2048 is way to high and already causes stack overflows.

If just the compiler wouldn't compile forever...
Seems surprising ... are you changing the to be 2048, or changing it at the level as well?
Just the ExpansionConfig limit, since the session limit won't go crazy way too far. I guess 1024 is still ok for macros. It is compiling and testing right now, so I can tell you more later.
Ah, I misunderstood you, I thought you meant the overflows were happening when compiling the compiler! You mean rather that an infinite recursion test will overflow before it hits the 2048 limit I think.
Yes
I got a workaround, but I guess it is not the best way. Sadly I got ill, so I won't be able to work on it further. Maybe someone else could go on? /cc ()
Change:
return body; } <ins> // If `mir_drops_elaborated_and_const_checked` found that the current body has unsatisfiable // predicates, it will shrink the MIR to a single `unreachable` terminator. // More generally, if MIR is a lone `unreachable`, there is nothing to optimize. if let TerminatorKind::Unreachable = body.basic_blocks[START_BLOCK].terminator().kind && body.basic_blocks[START_BLOCK].statements.is_empty() { return body; } </ins> run_optimization_passes(tcx, &mut body); body

Discussion:
File: mvce: original: Version information Command: Program output:
cc
I spent some time digging this, but I have no clue how is this happening yet.
Uh... isn't this regression from one of the dataflow const prop PRs? I don't think the is_global change caused
cc
When I reverted changes to problem disappeared. Edit: My hunch is this problem existed before but somehow covered it.
Change:
let impl_m = &cm.mty; <del> if impl_m.fty.meta.purity != trait_m.fty.meta.purity { tcx.sess.span_err( cm.span, fmt!("method `%s`'s purity does  not match the trait method's  purity", tcx.sess.str_of(impl_m.ident))); } // is this check right? </del> <ins> // FIXME(#2687)---this check is too strict.  For example, a trait // method with self type `&self` or `&mut self` should be // implementable by an `&const self` method (the impl assumes less // than the trait provides). </ins> if impl_m.self_ty != trait_m.self_ty { tcx.sess.span_err( cm.span,

Discussion:
Right now, a fn implementing an iface method must match the purity of the iface method exactly. This is too strict. We should allow a pure fn to implement an impure fn, and both pure/impure to implement an unsafe fn. UPDATE: Updated title to reflect the real problem here. There is a FIXME in the code in the relevant area. If one declares a trait like: then in the impl, the method should take one type parameter with an bound. We don't really check this correctly though. As far as I can tell, we just check that has one type parameter with one bound, but not precisely what kind of bound it is.
Similarly, in , we require that the bounds on the method parameters be precisely equivalent, which is stronger than necessary. It is sufficient (I believe) that the bounds on the trait be stronger than the bounds on the implementation.
Is this still an issue? It seems to be fixed now.
Still an issue with respect to type parameter bounds.
I don't believe this is backwards incompatible, renominating.
accepted for feature-complete milestone
The following appears to work, but I assume that this is what was talking about:
triage bump. nothing to add.
Accepted for P-backcompat-lang
Added UPDATE to main bug description above.
I had a look at this issue and tried to create a test case. does test case covers the issue you mentioned? This test case fails because it seems like the parameter types are checked in
what error does it fail with? In the you need to use a different type bound for in order to test this issue. To be more precise, the bounds of the implementation should be implied by the bounds of the trait. For example, this should fail:
thanks for the hint, I guess your updated example should indeed test this issue. I'll start working on a patch.
Change:
.label = value moved from here .note = The current maximum size is {$limit}, but it can be customized with the move_size_limit attribute: `#![move_size_limit = "..."]` <ins> monomorphize_no_optimized_mir = missing optimized MIR for an item in the crate `{$crate_name}` .note = missing optimized MIR for this item (was the crate `{$crate_name}` compiled with `--emit=metadata`?) </ins> monomorphize_recursion_limit = reached the recursion limit while instantiating `{$shrunk}` .note = `{$def_path_str}` defined here

Discussion:
The following scenario used to work fine 1.25.0: This would create two .bc files that could be linked together into a program, but when I try this on 1.26.{0,1,2} the compiler crashes like so:
Possibly dupe/related to ?
Yea I think this is a dupe, handling over there
The issue you mention seems to have something to do with impl trait (and looks like it goes away when the use is removed?) , whereas the issue I posted here crashes with even the simplest rust code. Are they really the same?
Hmm... you're right. I mean impl Trait in the other issue is just the trigger, the cause is in a normal function calling another one, but here you have another crate
I've discovered that if I tell the compiler to emit another type along with like this issue goes away. It makes me suspect this piece of code in : I'm wondering if by not running the code-gen or linking when outputting the metadata is causing this.
Triage: still repros:
Since , doesn't include optimized MIR, so produced rlib cannot be used to perform codegen. It would be nice to detect that particular situtation and produce more meaningful error describing that this is unsupported.
PR with fix:
Change:
LL |     fn foo(&self) {} |     ------------- not an `unsafe` function <del> error: aborting due to previous error </del> <ins> error: aborting due to 2 previous errors </ins>

Discussion:
The compiler currently allows safe default method implementations to be marked with : which I don't think is allowed in . For reference, is not allowed on trait implementations: From my limited testing, this doesn't seem to be unsound however, as the compiler seems to consider all implementations of as having . cc label T-lang T-compiler C-bug F-targetfeature11 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A good resolution to this would be to move it into a separate feature gate I guess?
claim
Change:
Applicability::MaybeIncorrect, ); } else { <ins> // Issue #104961, we need to add parentheses properly for compond expressions // for example, `x.starts_with("hi".to_string() + "you")` // should be `x.starts_with(&("hi".to_string() + "you"))` let Some(body_id) = self.tcx.hir().maybe_body_owned_by(obligation.cause.body_id) else { return false; }; let body = self.tcx.hir().body(body_id); let mut expr_finder = FindExprBySpan::new(span); expr_finder.visit_expr(body.value); let Some(expr) = expr_finder.result else { return false; }; let needs_parens = match expr.kind { // parenthesize if needed (Issue #46756) hir::ExprKind::Cast(_, _) | hir::ExprKind::Binary(_, _, _) => true, // parenthesize borrows of range literals (Issue #54505) _ if is_range_literal(expr) => true, _ => false, }; </ins> let is_mut = mut_ref_self_ty_satisfies_pred || ref_inner_ty_mut; <del> err.span_suggestion_verbose( span.shrink_to_lo(), &format!( "consider{} borrowing here", if is_mut { " mutably" } else { "" } ), format!("&{}", if is_mut { "mut " } else { "" }), </del> <ins> let span = if needs_parens { span } else { span.shrink_to_lo() }; let sugg_prefix = format!("&{}", if is_mut { "mut " } else { "" }); let sugg_msg = &format!( "consider{} borrowing here", if is_mut { " mutably" } else { "" } ); let suggestions = if !needs_parens { vec![(span.shrink_to_lo(), format!("{}", sugg_prefix))] } else { vec![ (span.shrink_to_lo(), format!("{}(", sugg_prefix)), (span.shrink_to_hi(), ")".to_string()), ] }; err.multipart_suggestion_verbose( sugg_msg, suggestions, </ins> Applicability::MaybeIncorrect, ); }

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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 output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The code here: Seems we can only get more context from , with only we can not know whether the current code snippet is an ident or a more complicated expression. The current is . An completed solution should make sure we get something like in ? A hack I'm thinking is checking whether contains spaces, if so we suggest it like:
I guess we have more similar issues for other suggestions come from .
This is an similar case, but we handle it well: Output is: The codepath is different, we take care parenthesis here, with :
Change:
// INVALID_HANDLE_VALUE. Stdio::Inherit => { match stdio::get(stdio_id) { <del> Ok(io) => io.handle().duplicate(0, true, c::DUPLICATE_SAME_ACCESS), </del> <ins> Ok(io) => { let io = Handle::new(io.handle()); let ret = io.duplicate(0, true, c::DUPLICATE_SAME_ACCESS); io.into_raw(); return ret } </ins> Err(..) => Ok(Handle::new(c::INVALID_HANDLE_VALUE)), } }

Discussion:
Over time the value of may change (e.g. see ) and we should likely reload the value over time instead of caching the return value to catch cases like this.
There's very little value in caching the result. takes 3 nanoseconds for me according to a quick bench.
Change:
is_method: bool, ) -> Option<Vec<(Option<&hir::GenericParam<'_>>, &hir::Param<'_>)>> { let fn_node = self.tcx.hir().get_if_local(def_id)?; <ins> let fn_decl = fn_node.fn_decl()?; </ins> <del> let generic_params: Vec<Option<&hir::GenericParam<'_>>> = fn_node .fn_decl()? </del> <ins> let generic_params: Vec<Option<&hir::GenericParam<'_>>> = fn_decl </ins> .inputs .into_iter() .skip(if is_method { 1 } else { 0 })

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at /rust/deps/itertools- 'itertools: .zipeq() reached end of one iterator before the other'', 'thread 'rustc' panicked at /rust/deps/itertools- 'itertools: .zipeq() reached end of one iterator before the other'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate -- label +F-cvariadic +F-fndelegation <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
lol
Thanks! I will take a look. (I'm glad we the check!)
another one that does not need delegation I think
claim
Change:
let var_ty = self.monomorphized_place_ty(place.as_ref()); let var_kind = if self.mir.local_kind(place.local) == mir::LocalKind::Arg && place.projection.is_empty() <ins> && var.source_info.scope == mir::OUTERMOST_SOURCE_SCOPE </ins> { <del> // FIXME(eddyb, #67586) take `var.source_info.scope` into // account to avoid using `ArgumentVariable` more than once // per argument local. </del> let arg_index = place.local.index() - 1; // FIXME(eddyb) shouldn't `ArgumentVariable` indices be

Discussion:
modify labels: +A-mir +C-bug +requires-nightly
cc
I wonder if this is caused by MIR inlining or by other passes like copy propagation. The conflict with would seem to suggest inlining (of a method call). Anyway, we can improve this for now by treating anything not in the outermost as not an argument user variable (even when backed by an argument MIR local).
Minimal repro, with ():
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. // Check that we check fns appearing in constant declarations. // Issue #22382. // Returning local references? struct DropString { inner: String } impl Drop for DropString { fn drop(&mut self) { self.inner.clear(); self.inner.push_str("dropped"); } } const LOCAL_REF: fn() -> &'static str = { fn broken() -> &'static str { let local = DropString { inner: format!("Some local string") }; return &local.inner; //~ ERROR does not live long enough } broken }; fn main() { } </ins>

Discussion:
Functions defined inside of declarations seem to ignore all lifetimes and mutability. This allows for massively violating the safety guarantees of Rust:
Nominating, this seems incredibly serious.
According to it seems that the borrowck isn't bothering to walk statics/consts (see ). Presumably this code was never updated when it became possible to use blocks as the initializer expression.
Um, yeah, not good. I'll investigate soonish, presuming doesn't get there first.
P-back-compatlang, 1.0 beta
Change:
// trait impls where we should have warned for the trait definition already. ast::ItemKind::Impl(box ast::Impl { of_trait: None, items, .. }) => { for it in items { <ins> // FIXME: this doesn't respect `#[allow(..)]` on the item itself. </ins> if let ast::AssocItemKind::Type(..) = it.kind { self.check_case(cx, "associated type", &it.ident); }

Discussion:
I believe the old behavior from nightly-2023-04-19 is correct. The repro has nothing to do with trait impls so I believe was not supposed to have affected it.
Bisects to .
How on earth did that happen? It was like a five-line change. :laughing: EDIT: got a fix, will post soon.
Probably something to do with the hygeine of the span on the versus the . if you can't fix this then ping me and I'll look at it, but we probably should fix it sooner than later.
Actually, you're probably right.
Oh, no, that's not it. You're missing a call to in the visitor.
Change:
<ins> #![feature(type_alias_impl_trait)] trait Callable { type Output; fn call(x: Self) -> Self::Output; } trait PlusOne { fn plus_one(&mut self); } impl<'a> PlusOne for &'a mut i32 { fn plus_one(&mut self) { **self += 1; } } impl<T: PlusOne> Callable for T { type Output = impl PlusOne; fn call(t: T) -> Self::Output { t } } fn test<'a>(y: &'a mut i32) -> impl PlusOne { <&'a mut i32 as Callable>::call(y) //~^ ERROR hidden type for `impl PlusOne` captures lifetime that does not appear in bounds } fn main() { let mut z = 42; let mut thing = test(&mut z); let mut thing2 = test(&mut z); thing.plus_one(); assert_eq!(z, 43); thing2.plus_one(); assert_eq!(z, 44); thing.plus_one(); assert_eq!(z, 45); } </ins>

Discussion:
This code should pass but it doesn't: This is resurrected. Cc label F-typealiasimpl_trait C-bug T-compiler T-types
Oh heh, I fixed the situation for registering the hidden type but didn't allow implying anything from that.
Change:
present_first @ Some(_) => present_first, // Uninhabited because it has no variants, or only absent ones. None if def.is_enum() => return tcx.layout_raw(param_env.and(tcx.types.never)), <del> // if it's a struct, still compute a layout so that we can still compute the // field offsets </del> <ins> // If it's a struct, still compute a layout so that we can still compute the // field offsets. </ins> None => Some(VariantIdx::new(0)), };

Discussion:
cc I suspect (but have not verified) that this would be fixed by a backport of
was merged in October, I don't think it's related
Does this need an mcve?
Yeah, but I think at this point a bisection might be more helpful since we're not yet sure what caused this.
Here's a somewhat small-ish MCVE: Haven't managed to remove mio yet, but that's just a matter of time ;) Note, that this doesn't depend on the feature. You can use as well.
Here's a "M"CVE without any dependencies: regression in nightly-2020-01-11 <details<summaryBacktrace</summary</details modify labels: -E-needs-bisection -E-needs-mcve
searched nightlies: from nightly-2019-11-01 to nightly-2020-02-16 regressed nightly: nightly-2020-01-11 searched commits: from to regressed commit: source code: Reproduce bisection with: <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details<details<summaryERROR BEFORE ICE REGRESSION</summary<p</p</details
It would be good to continue the bisection into the rollup PR, among the following PRs: (Point at opaque and closure type definitions in type errors) (Reduce special treatment for zsts) (Parse the syntax described in RFC 2632) (rustcastlowering: misc cleanup & rustc dep reductions) (Extend support of in type parameters) (expect after / )
triage: P-high, removing nomination, assigning to self.
Given the backtrace, I think it's probably (Reduce special treatment for zsts)
I can indeed reproduce the ICE at , seems to be the culprit. cc <details<summaryBacktrace</summary</details
Here is a more minimal MCVE: /me needs to invest some time in tools like rust-reduce or creduce...
Okay so now we have two different PR's to fix this. PR is almost certainly the right call for nightly itself. My only Question is whether we should also land PR and also then backport that to beta. My argument for why is that it is "obviously" less risky, which is important because the beta is going to be imminently promoted to stable.
Change:
.get(&self.item_id) .map_or(&[][..], |v| v.as_slice()) .iter() <del> .filter_map(|ItemLink { link: s, link_text, did, ref fragment }| { </del> <ins> .filter_map(|ItemLink { link: s, link_text, page_id: did, ref fragment }| { </ins> debug!(?did); if let Ok((mut href, ..)) = href(*did, cx) { debug!(?href);

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. --field contains wrong IDs for some kind of items. Items for which no independent HTML is generated (link target URL is ) appear to have incorrect IDs. I tried this code: I expected to see this happen: contains the IDs of link targets Instead, this happened: contains the ID of the items containing the link targets <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: +A-rustdoc-json +T-rustdoc +A-intra-doc-links
claim
Change:
<del> Subproject commit a8d90f6a57925d204efb21b3f6d9726d6674f9bd </del> <ins> Subproject commit fd0428f622feee209e6014b802f5717d48d9e978 </ins>

Discussion:
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.
Change:
* @param {Array<FunctionType>} list * @param {QueryElement} elem          - The element from the parsed query. * @param {[FunctionType]} whereClause - Trait bounds for generic items. <ins> * @param {Map<number,number>|null} mgens - Map functions generics to query generics. </ins> * * @return {boolean} - Returns true if found, false otherwise. */ <del> function checkIfInList(list, elem, whereClause) { </del> <ins> function checkIfInList(list, elem, whereClause, mgens) { </ins> for (const entry of list) { <del> if (checkType(entry, elem, whereClause)) { </del> <ins> if (checkType(entry, elem, whereClause, mgens)) { </ins> return true; } }

Discussion:
sqlx was updated yesterday. and its search is now broken. compare: with:
Firefox prints those errors: with label -needs-triage +T-rustdoc +A-rustdoc-search +regression-untriaged cc
Change:
<del> // Issue #118164: recovery path leaving unemitted error behind fn bar() -> String { #[cfg(feature = )] [1, 2, 3].iter().map().collect::<String>() //~ ERROR expected `;`, found `#` #[attr] //~ ERROR expected statement after outer attribute } fn main() { let _ = bar(); } </del>

Discussion:
<!-- [31mICE[0m: Rustc '--crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: not a tail expression', 'error: internal compiler error: not a tail expression' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It seems the pops up since cc The code starts ICEing in general since cc
claim