jiebi/CodeConvo huggingface dataset:
Change:
<del> Subproject commit 07ac10277ea5ad42efbb914da5844e0ab08efbf4 </del> <ins> Subproject commit 2adc39f27b7fd2d06b3d1d470827928766731a1d </ins>

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! cc the PR reviewer, and nominating for compiler team prioritization.
Yeah, I will try to figure out how to fix .
Sorry, saw this issue after the fact - If Miri is failing because of the renamed testopt, I have a PR for compiletest-rs open with a potential fix:
Sure, no problem.
We had avoided the "nightly" feature of compiletest-rs in Miri exactly because of this... But recently enabled it again due to other failures. Should we rather try to use the stable variant again?
Both variants are currently not working: should fix the nightly variant fixes the stable variant
Change:
<ins> // check-pass #![allow(unreachable_patterns)] fn main() { const CONST: &[Option<()>; 1] = &[Some(())]; match &[Some(())] { &[None] => {} CONST => {} &[Some(())] => {} } } </ins>

Discussion:
Compiled with: Using: Gives:
The problem is not tied to box:
No longer ICEs after
Ops, sorry, I reopen until a test is present.

: <details<summary<strongBacktrace</strong</summary<p</p</detailssearched nightlies: from nightly-2019-10-03 to nightly-2020-07-05 regressed nightly: nightly-2020-02-16 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
Minified, It seems possible to ICE on stable, though I'm not sure if it counts? <details<summaryStable error</summary</details
The ICE is fixed in the latest nightly, marking as .
Change:
<ins> // check-pass #![allow(unreachable_patterns)] fn main() { const CONST: &[Option<()>; 1] = &[Some(())]; match &[Some(())] { &[None] => {} CONST => {} &[Some(())] => {} } } </ins>

Discussion:
This produces an ICE (): It points to this assert firing: This assert assumes that if we match on a with a const, then must be . I'm not sure where this assumption comes from (I'd guess byte-array patterns), but it's clearly wrong. Note that this also fails with any other non- type here instead of . Note that this does not fail when the arrays are not behind references, or if we use slices instead of arrays. EDIT: removed unnecessary feature gate
The feature gate isn't needed to trigger the ICE
Oh, well spotted. And it appears that fails on stable too then
cc as it's possible this is related to your structural match work I guess?
Funny enough: this doesn't ICE but instead shows the correct "unreachable" warning
Reduced:
What the heck?!?
triage: P-high. Removing nomination. Self-assigning.
That's a leftover from matching on byte strings, which used to be one of the few constants one could actually match on.
I think it's one more of theses cases where we don't know how to handle properly. shouldn't even exist: specialization should be able to specialize consts by unpacking a pattern into its subpatterns, like we specialize everything else.
I've figured out a way to eliminate the ICE, but I do not think my code has the desired semantics. That is, I would imagine we would want this to be accepted: but my current draft code rejects the above as non-exhaustive. On the other hand, that does match the current behavior of the compiler, for better or for worse. Update: Or maybe I've forgotten the desirata for how match usefulness and consts are supposed to interact...?
This was not a stable reduction; on the current nightly, the above length-zero ZST array is accepted with no ICE, while the original length-one ZST array still causes an ICE.
Yet another fun variation on the test: yields:
The reason it exists is that we don't want to unpack a multi megabyte byte string you may have gotten from . That would be super inefficient and likely just cause an out of memory abort. The reason why I believe we should also do this optimization for other types is that you can easily transmute a multi megabyte byte string to another array type in a constant, and then you have the same problem all over again.

(Or you init with a repeat expression). I agree that it would be nicer and less fragilr if we just unpacked everything.
Btw, addresses a few of the ICEs around this
Since the original and reduced versions no longer ICE, but still does
The above no longer ICEs after , could do with a test
Change:
let impl_m_hir_id = tcx.hir().local_def_id_to_hir_id(impl_m.def_id.expect_local()); let return_span = tcx.hir().fn_decl_by_hir_id(impl_m_hir_id).unwrap().output.span(); <del> let cause = ObligationCause::new( </del> <ins> let mut cause = ObligationCause::new( </ins> return_span, impl_m_hir_id, ObligationCauseCode::CompareImplItemObligation {

Discussion:
Essentially, if my trait has and my impl has the compiler panics. Note that the code is invalid and compilation should fail. <!-- 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. --: Note that I'm using which is experimental. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This happens for all type mismatches in the arguments (but not the arity!) A : <details<summaryWith the following backtrace: </summary</details
When not using a normal , the proper error is emitted here inside : But something gets messed up with the return position impl trait in trait desugaring that doesn't make this work (the arity check above does work). claim
Change:
<ins> // This test ensures that the `struct.B.html` only exists in `a`: // since `a::B` is public (and inlined too), `self::a::B` doesn't // need to be inlined as well. #![crate_name = "foo"] pub mod a { // @has 'foo/a/index.html' // Should only contain "Structs". // @count - '//*[@id="main-content"]//*[@class="item-table"]' 1 // @has - '//*[@id="structs"]' 'Structs' // @has - '//*[@id="main-content"]//a[@href="struct.A.html"]' 'A' // @has - '//*[@id="main-content"]//a[@href="struct.B.html"]' 'B' mod b { pub struct B; } pub use self::b::B; pub struct A; } // @has 'foo/index.html' // @!has - '//*[@id="structs"]' 'Structs' // @has - '//*[@id="reexports"]' 'Re-exports' // @has - '//*[@id="modules"]' 'Modules' // @has - '//*[@id="main-content"]//*[@id="reexport.A"]' 'pub use self::a::A;' // @has - '//*[@id="main-content"]//*[@id="reexport.B"]' 'pub use self::a::B;' // Should only contain "Modules" and "Re-exports". // @count - '//*[@id="main-content"]//*[@class="item-table"]' 2 pub use self::a::{A, B}; </ins>

Discussion:
When running with the above code, the docs list the following items: <details<summaryDocs</summary </detailsI would expect to be listed as a reexport, not a struct. The way it is now, it looks like and are different types, which is not the case. If is made , everything looks as it's supposed to. label +T-rustdoc
It's the intended behaviour. Since the module is private, is inlining the item into .
Yes, but is public, so should it really be inlined a second time?
Ok sorry I misunderstood what you meant. No, it shouldn't be inlined a second time.
Change:
<del> // Copyright 2012 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. // error-pattern: /* This is a test to ensure that we do _not_ support nested/balanced comments. I know you might be thinking "but nested comments are cool", and that would be a valid point, but they are also a thing that would make our lexical syntax non-regular, and we do not want that to be true. omitting-things at a higher level (tokens) should be done via token-trees / macros, not comments. /* fail here */ */ fn main() { } </del>

Discussion:
Currently we don't support nested block comments. This allows lexing to be regular, but it widely seen as an inconvenience. Modify the lexer to keep track of comment nesting. Nominating backcompat.
I thought we were going to grow a macro to handle block quotes. Did that ever get implemented?
I don't know what you mean by block quotes.
Accepted for feature-complete
Don't line comments address pretty much all uses of nested block comments?
by block quote, I mean in the style of CPP's to allow for nesting comments. Something like this:
From what I've gathered from the code, there are two implementations of the comment parsing, one of which supports nested comments, so I guess should be fixed before this bug.
That's pretty funny that the pretty printer already supports nested comments. I don't think they necessarily have to be merged to fix this bug, though our lexing is a bit of a mess.
Are you going to tackle this?
If there's no massive refactoring to do, I can try! Expect a PR soon.
The reference manual says "Comments in Rust code follow the general C++ style of line and block-comment forms, with no nesting of block-comment delimiters" ... right after production rules for nested comments.
looks like it was forgotten to be updated, thanks for noticing! (I opened )
Change:
let hir_id = tcx.hir().local_def_id_to_hir_id(def_id); let cause = ObligationCause::misc(span, hir_id); for ty in assumed_wf_types { <del> implied_bounds.insert(ty); </del> <ins> // FIXME(@lcnr): rustc currently does not check wf for types // pre-normalization, meaning that implied bounds are sometimes // incorrect. See #100910 for more details. // // Not adding the unnormalized types here mostly fixes that, except // that there are projections which are still ambiguous in the item definition // but do normalize successfully when using the item, see #98543. // // Anyways, I will hopefully soon change implied bounds to make all of this // sound and then uncomment this line again. // implied_bounds.insert(ty); </ins> let normalized = self.normalize(cause.clone(), param_env, ty); implied_bounds.insert(normalized); }

Discussion:
this compiles with because we now assume unnormalized types in the impl header to be well formed when computing implied bounds. We don't check that when using the impl so we should be able to transmute lifetimes with this, though I haven't tried that yet. Going to fix that myself once I am back home in 2 weeks. cc
assigning after a very long and deep discussion in https://rust-
(FYI I also nominated PR for discussion at T-compiler meeting, essentially because of this associated issue; I hadn't seen that this was tagged as P-critical at that time. I'm leaving it nominated for now, just to ensure doubly that we discuss the matter.)
this is an existing issue on stable if we prevent the projection from normalizing in the impl while normalizing it when using the impl: that's the same issue as , which has been only fixed for function signatures edit: that's
Change:
<del> Subproject commit 2d54c4f559b1acbfe1867950c3a25bfb2f76b693 </del> <ins> Subproject commit 32c27dda3ae2318b6897f00795009cd6f42ac4b3 </ins>

Discussion:
This happens only after the recent LLVM upgrade. The culprit seems to be half of : Changing the call to copy only 8 bytes instead of 16 (to not touch the portion) removes the infinite loop. cc
One workaround would be to replace with but I'm not sure if that will cause a hit on performance.
I haven't fully analyzed this, but that changing the memcpy size helps is coincidental. That just breaks a memcpy optimization that is required for the problem to show up, because the memcpy sizes now differ. AFAICT for now, this is some problem with aliasing.
So looking through the relevant changes in LLVM, I noticed that the docs for have been refined. And now they clarify that using on the return value is only meant for like functions, i.e. functions that return "new" pointers, not previously accessible to the caller at all. We use it for functions returning unique pointers and functions that return through sret pointers. Seems bad. See Testing a patch now.
FWIW, removing from the no-opt IR for the given testcase does indeed fix the problem.
Nice find!
Fun fact, our suspicion that our usage of lifetime intrinsics was at fault for a bunch of failures might have been totally off. Different usage of lifetimes might just have killed different memcpy optimizations, hiding the real culprit lol I still need to fix them to allow for better optimization though :-/
So here's the minimal LLVM IR I have so far: Removing the attribute on on makes the problem go away, but having there doesn't seem wrong to me.
Pretty sure this is a bug in the memcpyopt pass that doesn't update the scoped alias data.
Change:
use parse::token::{InternedString, intern, str_to_ident}; use util::small_vector::SmallVector; use ext::mtwt; <ins> use fold::Folder; </ins> use std::collections::HashMap; use std::gc::{Gc, GC};

Discussion:
I believe this should output the string : But I get this error: Rust version:
Note that standard recursive macros work fine, e.g., And outputs . Maybe the bug here is that expanding macros within other macros is using an older environment that doesn't include the name ?
It's even worse than that. only uses the compiler built-in macros:
I think this might be a dupe of
Does fixing mean that also gets fixed? I wouldn't assume so, but it might be possible depending on the implementation. (Sorry I missed that issue. I searched for 'recursive macro' instead of 'nested macro'!)
both and use , which doesn't work with non-builtin macros.
Right. I'm referring to the recursive aspect. Wasn't sure if that would make a difference. (I just don't know enough about how macros are expanded to know. Pure guesswork on my part.)
Change:
// and to the end of the line. Be careful because the line // numbers in Loc are 1-based, so we subtract 1 to get 0-based // lines. <ins> // // FIXME: now that we handle DUMMY_SP up above, we should consider // asserting that the line numbers here are all indeed 1-based. </ins> let hi_line = hi.line.saturating_sub(1); for line_index in lo.line.saturating_sub(1)..hi_line { let line_len = lo.file.get_line(line_index).map(|s| s.chars().count()).unwrap_or(0);

Discussion:
Problem returns invalid span data, particularly and are set to 0, though . This happens with a completly empty file. Tested on the following cargo version: Whilst on the stable version the returned span array is empty: Steps Now you can see invalid span in file. I've already created and formatted and files with the output of different cargo versions. Here are the crutial differences and Context
Moved to rust-lang/rust, where diagnostics live. Seems to be caused by , cc
additional info: The regression is also present on the older version of nightly rustc: This was the version where I initially spotted the issue, then updated and rechecked, but it was still present in .
Probably caused by
triage: P-high. Assigning to self.
Change:
has_typeck_tables, adt_destructor, used_trait_imports, <ins> check_item_well_formed, check_trait_item_well_formed, check_impl_item_well_formed, </ins> ..*providers }; }

Discussion:
At the moment WF checking is not done via a query. As a consequence, we cannot cache it during incremental compilation. Seems like an easy optimization. cc
I'm working on this.
Change:
<ins> // revisions: nll default // ignore-compare-mode-nll //[nll]compile-flags: -Z borrowck=mir trait TT {} impl dyn TT { fn func(&self) {} } fn main() { let f = |x: &dyn TT| x.func(); //[default]~ ERROR: mismatched types //[nll]~^ ERROR: borrowed data escapes outside of closure } </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. --: This bug also exists at . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Output on 1.46: Changing the closure argument type to compiles successfully on both verions. modify labels: +A-diagnostics +A-lifetimes +regression-from-stable-to-stable
With instead of it compiles successfully too. <details<summaryCode</summary</details
We probably have to check for closures in here.
Assigning as and removing I-prioritize.
Change:
<del> Subproject commit 2b259b3c201f939f2ed8d2fb0a0e9b37dd2d1321 </del> <ins> Subproject commit 4b8d29c585687084bbcf21471e04f279d1eddc0a </ins>

Discussion:
Unfortunately I don't have a minimal reproducible example, just a reproducible example. On MacOS Ventura 13.5 on an Apple M2 processor, the following steps reproduce it: Said steps cause to exit with a SIGTRAP signal, unfortunately all the way at the end of compilation. The above SIGTRAP is a regression, it occurs with in , as well as with , but not with . I have not bisected it further. The error does not occur when using instead of . The difference between these two is the profile selected, uses the debug profile whereas uses the following profile: I've tagged this issue as an 'internal compiler error', even though it does not panic but actually SIGTRAPs. I thus don't have a Rust backtrace, but I did attach to before the sigtrap occurred and got the following backtrace: <details<summary<strongBacktrace</strong</summary<p</p</details
As this is on M2, can you please take a look?
Reduced: If this reduction is too aggressive, I'll try again tomorrow. :)
Upstream issue:
Fixed in LLVM 19 (Probably the next backport). label +llvm-fixed-upstream
Even though this is basically-already-fixed, we need to figure out if this is on the 1.82 beta (it has to be, right?)
Wait, I can just do math. Yes, it is.
I cannot reproduce this because this requires the nightly version, but the regression has included in 1.82 beta. I would expect to integrate the final 19.1.0 version of LLVM to rustc 1.82, although this contains many changes.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Yeah, we'll backport at least the 19.1.0 release to the beta branch, possibly also a later point release if needed.
It's not super important but the regression looks to be from .
then reverting that PR is also an option, but I will of course defer to you on exactly what gets backported, just wanted to make sure this was tagged appropriately so we didn't lose track. :^)
Change:
if let Node::Expr(expr) = tcx.hir_node(arg_hir_id) && let Some(typeck_results) = &self.typeck_results { <ins> if let hir::Expr { kind: hir::ExprKind::MethodCall(_, rcvr, _, _), .. } = expr && let Some(ty) = typeck_results.node_type_opt(rcvr.hir_id) && let Some(failed_pred) = failed_pred.to_opt_poly_trait_pred() && let pred = failed_pred.map_bound(|pred| pred.with_self_ty(tcx, ty)) && self.predicate_must_hold_modulo_regions(&Obligation::misc( tcx, expr.span, body_id, param_env, pred, )) { err.span_suggestion_verbose( expr.span.with_lo(rcvr.span.hi()), format!( "consider removing this method call, as the receiver has type `{ty}` and  `{pred}` trivially holds", ), "", Applicability::MaybeIncorrect, ); } </ins> if let hir::Expr { kind: hir::ExprKind::Block(block, _), .. } = expr { let inner_expr = expr.peel_blocks(); let ty = typeck_results

Discussion:
When calling in a fn that expects we currently emit: We should check whether and suggest the removal of the call. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
feel free to reach out either on this ticket or on a PR, but be warned that this has the potential to be quite involved. It is a great introduction to how some parts of fit together though.
I've been looking into this for a while now, and my idea was to: Check if there a .into() call, check if the type of self was T and finally check if the argument of the function was Into<T. However I cannot figure how to get the type of Self. As far as my understanding goes, rustc hasn't yet inferred the type.
You can query the in-progress type table with the for the expression. You're gonna have an with a . From the first argument in that variant you can take the first element and get the expression for in . Then you can use the for that expression to do I do not know if we will have populated 's type by then, but if we have, then that will give you the type of . Then, if you're in an you can use to see if the inferred type for can be coerced to in the original example. I know this is a bit vague, but for this is inherently exploratory work :)
Hi, are you still working on this issue
No, feel free to claim it if you want
release-assignment
Change:
/// Gets the thread's name. /// <ins> /// For more information about named threads, see /// [this module-level documentation][naming-threads]. /// </ins> /// # Examples /// /// Threads by default have no name specified:

Discussion:
One can specify the stack size of a thread via . It looks like looks at the env var and attempts to parse it into an integer. If it's not specified or can't parse, it falls back to 2MB. Should we update the thread documentation to mention what the default stack size is and mention that environment variable?
Relevant discussion on IRC
Don't forget that the stack size of the main thread is not determined by Rust.
Opened a PR:
Change:
//~^ ERROR mismatched types } <del> fn qux(a: Option<u32>, b: Option<u32>) -> bool { (if let Some(x) = a { true } else { false }) && //~ ERROR expected expression if let Some(y) = a { true } else { false } } </del> fn moo(x: u32) -> bool { (match x { _ => 1,

Discussion:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .
Change:
use rustc_span::{BytePos, InnerSpan, Span}; use rustc_target::abi::{Abi, FIRST_VARIANT}; use rustc_trait_selection::infer::{InferCtxtExt, TyCtxtInferExt}; <ins> use rustc_trait_selection::traits::query::evaluate_obligation::InferCtxtExt as _; </ins> use rustc_trait_selection::traits::{self, misc::type_allowed_to_implement_copy}; use crate::nonstandard_style::{method_context, MethodLateContext};

Discussion:
I would expect the following code to compile successfully since we explicitly opt out of implementing : However, the code fails to compile with the following error message: label C-bug A-lint F-negativeimpls <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The compiler only checks if the type implements already to return early and not emit the lint diagnostic but it doesn't check if the type implements :
I think this makes the trick, you are right! the last think is to explore what is the code of the method The code of the method looks not so trivial :) If you did not find already I can play with your on it by mentoring you, I had some experience in "git archeology" :) label +E-mentor
claim