jiebi/CodeConvo huggingface dataset:
Change:
#![feature(intrinsics)] #![feature(try_find)] #![feature(is_sorted)] <del> #![feature(iter_once_with)] </del> #![feature(lang_items)] #![feature(link_llvm_intrinsics)] #![feature(never_type)]

Discussion:
This is the tracking issue for . Currently in nightly, PR = .
Is this function now ready for stabilization?
I don’t see why not. Tracked here: fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
I noticed that this iterator has been stabilized a impl which I assume wasn't intentional so I've submitted to remove it.
Change:
self.lookup_and_handle_method(expr.hir_id); } hir::ExprKind::Field(ref lhs, ..) => { <del> self.handle_field_access(lhs, expr.hir_id); </del> <ins> if self.typeck_results().opt_field_index(expr.hir_id).is_some() { self.handle_field_access(lhs, expr.hir_id); } else { self.tcx.dcx().span_delayed_bug(expr.span, "couldn't resolve index for field"); } </ins> } hir::ExprKind::Struct(qpath, fields, _) => { let res = self.typeck_results().qpath_res(qpath, expr.hir_id);

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' 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: [livesymbolsandignoredderivedtraits] finding live symbols in crate [checkmod_deathness] checking deathness of variables in top-level module [analysis] running analysis passes on this crate --
Bisects to nightly-2023-06-02 commit[0] 2023-05-31: Auto merge of - oli-obk:valtrees2, r=lcnr commit[1] 2023-05-31: Auto merge of - petrochenkov:strictflavor, r=lqd,wesleywiser commit[2] 2023-06-01: Auto merge of - Urgau:upliftcastreftomut, r=b-naber commit[3] 2023-06-01: Auto merge of - oli-obk:constevalstep_limit, r=fee1-dead commit[4] 2023-06-01: Auto merge of - Dylan-DPC:rollup-93zj7jw, r=Dylan-DPC commit[5] 2023-06-01: Auto merge of - saethlin:enable-sroa, r=oli-obk,scottmcm commit[6] 2023-06-01: Auto merge of - cjgillot:separate-const-switch, r=oli-obk commit[7] 2023-06-01: Auto merge of - Kobzol:try-build-skip-docs, r=mark-simulacrum ERROR: no CI builds available between and within last 167 days
Minimized:
Very likely btw.
Change:
<ins> warning: dropping unsupported crate type `dylib` for target `thumbv7em-none-eabihf` </ins>

Discussion:
rustc --version; cat ; env RUSTBACKTRACE=1 rustc --emit asm --crate-type dylib -O --target thumbv7em-none-eabihf rustc 1.28.0-nightly ( 2018-05-21) #!

[nostd] pub fn pete() -u32 { 2 } warning: dropping unsupported crate type for target thread 'main' panicked at 'called on a value', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at at 2: std::panicking::defaulthook::{{closure}} at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanicfmt at 7: rustbeginunwind at 8: core::panicking::panicfmt at 9: core::panicking::panic at 10: rustccodegenllvm::base::writemetadata 11: rustc::util::common::time 12: rustccodegenllvm::base::codegencrate 13: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 14: rustc::util::common::time 15: rustcdriver::driver::phase4codegen 16: rustcdriver::driver::compileinput::{{closure}} 17: rustc::ty::context::tls::entercontext 18: <std::thread::local::LocalKey<T::with 19: rustc::ty::context::TyCtxt::createandenter 20: rustcdriver::driver::compileinput 21: rustcdriver::runcompilerwithpool 22: syntax::withglobals 23: <std::panic::AssertUnwindSafe<Fas core::ops::function::FnOnce<()::callonce 24: rustmaybecatchpanic at 25: rustcdriver::run 26: rustcdriver::main 27: std::rt::langstart::{{closure}} 28: std::panicking::try::docall at at 29: rustmaybecatchpanic at 30: std::rt::langstartinternal at at at 31: main 32: _libcstartmain 33: <unknownquery stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked.

this is a bug. note: we would appreciate a bug report: note: rustc 1.28.0-nightly ( 2018-05-21) running on x8664-unknown-linux-gnu note: compiler flags: --crate-type dylib
This does not happen on either stable or beta, only nightly.
if it's easy for you, any chance you could bisect with this tool? That would help us pinpoint precisely what introduced the fault. But this is presumably a simple fix...
Sorry, i was a little bit too sloppy. On stable it does not crash, but just because stable does not know the target thumv7em-none-eabi. Beta does indeed crash as well on the same error. I think will fix the problem, let's see. Hadn't time to do a bisect yet
Oh... this might be a new bug entiretly then. Most likely a bisection would point to the PR that said targets
I can confirm, that your patch fixes the ICE :) thanks . The question is, what is it supposed to do now. I creates a file, but it remains mostly empty (so no assembly is generated for that function). Is that what it is supposed to do?
I have no idea. Is that problematic?
Not at all, I'm just curious to know.
Change:
<ins> // Copyright 2016 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. // compile-pass #![feature(untagged_unions)] struct A; struct B; union U { a: A, b: B, } fn main() { unsafe { { let mut u = U { a: A }; let a = u.a; u.a = A; let a = u.a; // OK } { let mut u = U { a: A }; let a = u.a; u.b = B; let a = u.a; // OK } } } </ins>

Discussion:
review comments:
triage: P-medium. (We should look into this, but even if its wrong, I'm not going to push to a backport its hypothetical bug fix.)

review comments: For the record, here's the relevant part of the test in question ():
This should be NLL-complete, not NLL-sound, right?
Yeah, it should. My bad.
triage: P-high, not not Release milestone. This issue is bad enough for fix quickly, but there's no reason to beta-backport (as I explained on the PR itself here )
Change:
} } fn visit_trait_item(&mut self, it: &'tcx TraitItem) { <ins> debug!("find_existential_constraints: visiting {:?}", it); </ins> let def_id = self.tcx.hir().local_def_id(it.hir_id); self.check(def_id); intravisit::walk_trait_item(self, it);

Discussion:
Mentioning the existential types tracking issue Mentioning and
O_o I don't think I considered closures at all. Should closures be defining uses? Or just uses (and thus only be able to return that type by calling a function that defines the existential)?
As a motivating use case, existential types defined by a closure are required if we want to extend to support referring to local variables.
Yeah, any in-scope use (including in a binding) can be a defining use.
A binding like this? It looks like this is not currently picked up. It is why I had to write rather than simply in my previous comment.
Yeah, the RFC specifies that that should work.
I chose a simpler logic: any in scope use must be a defining use.
We've moved from segmentation faults to an ICE:
Change:
LL |             type B; |             ^^^^^^ <del> error: aborting due to 21 previous errors </del> <ins> error: aborting due to 22 previous errors </ins>

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see no output from the compiler. Instead, this happened: searched nightlies: from nightly-2022-09-22 to nightly-2022-09-27 regressed nightly: nightly-2022-09-25 searched commit range: regressed commit: This is a roll-up, seems the most likely culprit. cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: aarch64-apple-darwin Reproduce with: </details modify labels: +regression-from-stable-to-nightly -regression-untriaged
WG-prioritization assigning priority, probably a P-high since the lint malfunction is blocking valid code (iiuc) label -I-prioritize P-high T-compiler
any ideas how to address this or should I start digging in to it
In HIR desugars into two items (import in type namespace and import in value namespace). One of them is externally reachable and another is not (before both of them were incorrectly marked as externally reachable). Code in should somehow account for this desugaring and not report the as unnecessary if at least one of the imports is reachable.
I have been unable to fix this or apply a revert. can you look at implementing this before the beta cutoff?
Reverted in
Change:
<ins> #![feature(generic_const_exprs)] //~^ WARN the feature `generic_const_exprs` is incomplete trait B { type U<T>; } fn f<T: B<U<1i32> = ()>>() {} //~^ ERROR constant provided when a type was expected 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
searched nightlies: from nightly-2022-12-30 to nightly-2023-03-18 regressed nightly: nightly-2023-01-01 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegression in
aaah shit, the commit only modified the backtrace :laughing: so "panicked at" no longer triggers before that..
`
maybe
Change:
pub type ReallyLongTypeNameLongLongLong = Option<unsafe extern "C" fn(a: *const u8, b: *const u8) -> *const u8>; <ins> /// Short doc. </ins> pub const ReallyLongTypeNameLongLongLongConstBecauseWhyNotAConstRightGigaGigaSupraLong: u32 = 0; /// This also has a really long doccomment. Lorem ipsum dolor sit amet,

Discussion:
Crates with long type names result in a strange-looking error, see ! I've tested this on Chrome and Firefox, and by building the docs locally from I believe the text is rendering vertically due to long type names like which are auto-generated from OpenAPI. Link to original issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The issue is related to the rule which prevents breaking anywhere in the type name. Unfortunately using breaks . We even have a comment about the weird behaviour in the code, not sure how to fix this.
claim
Change:
| = help: try an outer attribute: `#[macro_use]` <ins> warning: `#[macro_escape]` is a deprecated synonym for `#[macro_use]` --> $DIR/issue-43106-gating-of-builtin-attrs.rs:438:1 | LL | #[macro_escape] | ^^^^^^^^^^^^^^^ </ins> warning: use of deprecated attribute `plugin_registrar`: compiler plugins are deprecated. See https://github.com/rust-lang/rust/pull/64675 --> $DIR/issue-43106-gating-of-builtin-attrs.rs:228:17 |

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. --Found an ICE with when trying to use it in the standard library (). cc . <!-- 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
I can hit an additional ICE by using an unknown attribute instead of a valid one: <details<summary<strongBacktrace</strong</summary<p</p</detailsI don't really think it's useful for this issue though, since it's a delayed error.
Fixed in
Change:
|        | |        ...because method `test` references the `Self` type in its `where` clause = help: consider moving `test` to another trait <del> = help: consider moving `test` to another trait </del> = help: only type `()` implements the trait, consider using it directly instead error: aborting due to previous error

Discussion:
made it so that we report all object safety violations at the same time. However, it also results in a redundant note: We should not add the same note multiple times.
Can we add a debug assertion for duplicate identical help messages? (sorta like we do for "Span must not be empty and have no suggestion" or "Suggestion may not have overlapping parts" ?
I guess we could, but I think there are multiple diagnostics that currently do this, so we'll have to fix them first.
Did not find tooo much... inside :
Change:
Copy for usize, u8, u16, u32, u64, u128, isize, i8, i16, i32, i64, i128, <del> f32, f64, </del> <ins> f16, f32, f64, f128, </ins> bool, char, {T: ?Sized} *const T, {T: ?Sized} *mut T,

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. --Playground nightly version: 1.79.0-nightly (2024-03-25 ) This isn't expected since it doesn't seem to hit a label +T-compiler +f-f16andf128 +I-ICE +requires-incomplete-features +S-has-mcve claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -needs-triage
Minimized:
Looks like it just expects primitives to be . I'm not sure where exactly this assumption comes from, but might as well fix it before the rest of libs support can get merged.
Change:
fn get(&self) -> usize; } <del> impl<T> MyTrait for T { </del> <ins> impl<T> MyTrait for T { //~ NOTE first implementation here </ins> fn get(&self) -> usize { 0 } }

Discussion:
From: src/test/compile- Error E0119 needs a spanlabel and a spannote converted to a span_label, updating it from: To:
Grabbed this one from the list.
Change:
// Ignore errors in function bodies if this is rustdoc // Be sure not to set this until the function signature has been resolved. let previous_state = replace(&mut this.in_func_body, true); <ins> // We only care block in the same function this.last_block_rib = None; </ins> // Resolve the function body, potentially inside the body of an async closure this.with_lifetime_rib( LifetimeRibKind::Elided(LifetimeRes::Infer),

Discussion:
When the error should mention bindings that are outside of the scope but within the same item <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Do you think we should suggest in this scenario? My local dev branch will suggest:
I removed it.
Change:
let label = "add `dyn` keyword before this trait"; let mut diag = rustc_errors::struct_span_err!(tcx.sess, self_ty.span, E0782, "{}", msg); <del> diag.multipart_suggestion_verbose(label, sugg, Applicability::MachineApplicable); </del> <ins> if self_ty.span.can_be_used_for_suggestions() { diag.multipart_suggestion_verbose( label, sugg, Applicability::MachineApplicable, ); } </ins> // check if the impl trait that we are considering is a impl of a local trait self.maybe_lint_blanket_trait_impl(&self_ty, &mut diag); diag.emit();

Discussion:
Given the following code: The current output is: Ideally the output should not suggest placing before in because the keyword is not valid in that position. Thank you to for finding the minimum reproducible that I used for this issue. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // check-pass macro_rules! foo { ($(: $p:path)? $(: $l:lifetime)? ) => { bar! {$(: $p)? $(: $l)? } }; } macro_rules! bar { ($(: $p:path)? $(: $l:lifetime)? ) => {}; } foo! {: 'a } fn main() {} </ins>

Discussion:
https://crater- cc
Possibly accidentally injected by Would be good to find out why this is happening, so let's ping cleanup and see if we can bisect / shrink the problem down to something usable for finding a fix.
ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Failed to confirm that is the cause: Seems like it regressed prior to
For code I used:
modify labels: -E-needs-bisection
Reduced example: () Errors:
Split the macro in two parts to make it easier to follow, and removed the special lifetime : () Error: I think we can now modify labels: -E-needs-mcve
I believe that the most probable culprit is , cc
is indeed the culprit, I can reproduce the bug on
This was . Assigning for now until we have a better understanding of what's going on.
Fixed in
Change:
resolved_self = format!("{}::{}", name, &path_str[6..]); path_str = &resolved_self; } <ins> } else if path_str.starts_with("crate::") { use rustc_span::def_id::CRATE_DEF_INDEX; // HACK(jynelson): rustc_resolve thinks that `crate` is the crate currently being documented. // But rustdoc wants it to mean the crate this item was originally present in. // To work around this, remove it and resolve relative to the crate root instead. // HACK(jynelson)(2): If we just strip `crate::` then suddenly primitives become ambiguous // (consider `crate::char`). Instead, change it to `self::`. This works because 'self' is now the crate root. resolved_self = format!("self::{}", &path_str["crate::".len()..]); path_str = &resolved_self; module_id = DefId { krate: item.def_id.krate, index: CRATE_DEF_INDEX }; </ins> } match self.resolve_with_disambiguator(

Discussion:
Crate exports from . is documented in quit and has no documentation in quitmacros. When that documentation has a link to , which is only in crate quit, it is unresolved. However, is resolved. Rustdoc gives no warnings with either. You can see the result with quit version 1.1.1 . cc cc
<details<summaryAll of this was wrong, I forgot to use +nightly</summaryThis isn't related to scopes, rustdoc will also fail to resolve these links: Something about the re-export itself is messing it up. </details
The good news is this is unrelated to proc-macros. Here's what I found: This is really strange. I would have expected it to resolve relative to , not relative to the current crate.
Ok, I found the issue: rustdoc and resolve disagree about which crate this is in For , rustdoc passes the original module of String, , and resolve correctly says there's no item named . But for , resolve thinks that refers to the current crate, not to alloc. This explains a lot of other broken links I've been seeing actually: anything that has will be wrong. So you were actually correct to start that this was the same issue as ;) The fix will be a little tricky ... there's no 'change ' button for resolve. There are a few things rustdoc can do: all links relative to the current module (the status quo before ). This is a no-go, because it means links will break on re-exports (). all links relative to the original module. This is what I thought was the current behavior. It means that additional documentation can't refer to things in the current lexical scope, which is non-intuitive (cc ). links in lexical scope: the original docs get resolved in the original module; the new docs get resolved in the module with the re-export. This is the ideal fix but somewhat hard to do because rustdoc doesn't distinguish between the two internally. A possible way to implement 2. is by stripping wherever we see it and resolving relative to the crate root instead of the current module. This is slightly_ hacky but should work fairly reliably.
Marking as P-high after discussing with ; it would be unfortunate to still have this bug on the first release after stabilization.
Change:
_ => None } }; // Verify that the parsed `if` condition makes sense as a condition. If it is a block, then // verify that the last statement is either an implicit return (no `;`) or an explicit // return. This won't catch blocks with an explicit `return`, but that would be caught by

Discussion:
The error here is if is missing in else if but compiler reports: error:
already points out at the place where the should be, even if it doesn't suggest it:
: I still wish the parser to detect that the code immediately following is a binary operation followed by a block, so that we can instead emit
CC in case you might be interested in looking at the parser :)
this seems like a neat fix, i'll take a stab at it
Change:
for arg in &fd.inputs { match arg.pat.node { hir::PatIdent(hir::BindByValue(hir::MutImmutable), _, None) => {} <ins> hir::PatWild(_) => {} </ins> _ => { span_err!(self.tcx.sess, arg.pat.span, E0022, "arguments of constant functions can only 

Discussion:
Willing to mentor this. Fix is simple, just need to check for . We should also add a run-pass test to ensure that the above code continues to compile. Feel free to ask me if you have further questions!
I've been willing for a long time to start getting involved in some contributions to Rust, so if it's ok for you I would like to give this one a go and make it my first contribution.
Go ahead!
Change:
<ins> error: unused doc comment --> $DIR/unused-doc-comments-for-macros.rs:7:5 | LL | /     /// line1 LL | |     /// line2 LL | |     /// line3 | |_____--------^ |       | |       rustdoc does not generate documentation for macro invocations | note: the lint level is defined here --> $DIR/unused-doc-comments-for-macros.rs:1:9 | LL | #![deny(unused_doc_comments)] |         ^^^^^^^^^^^^^^^^^^^ = help: to document an item produced by a macro, the macro must produce the documentation as part of its expansion error: unused doc comment --> $DIR/unused-doc-comments-for-macros.rs:13:5 | LL | /     /// line1 LL | |     /// line2 LL | |     /// line3 | |_____--------^ |       | |       rustdoc does not generate documentation for macro invocations | = help: to document an item produced by a macro, the macro must produce the documentation as part of its expansion error: aborting due to 2 previous errors </ins>

Discussion:
Other expressions work as expected: it reports just one error, for the whole sequence of doc comment lines. () Errors:
( is a rustc lint.)
True, but I as well since it's a rustdoc-related lint.