jiebi/CodeConvo huggingface dataset:
Change:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after reporting some other errors, and the input is not syntactically correct (), so low priority. Affected versions: I tried nightly 2021-12-31 and stable 1.57 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Triage: this has been fixed since nightly-2022-12-09, marking as .

Discussion:
<ins> //check-fail #![crate_type="lib"] fn r({) { Ok {             //~ ERROR mismatched types [E0308] d..||_=m } } //~^^^^^ ERROR expected parameter name, found `{` //~| ERROR expected one of `,`, `:`, or `}`, found `..` //~^^^^^ ERROR cannot find value `d` in this scope [E0425] //~| ERROR cannot find value `m` in this scope [E0425] //~| ERROR variant `Result<_, _>::Ok` has no field named `d` [E0559] </ins>

<ins> error: expected parameter name, found `{` --> $DIR/issue-92481.rs:5:6 | LL | fn r({) { |      ^ expected parameter name error: expected one of `,`, `:`, or `}`, found `..` --> $DIR/issue-92481.rs:5:6 | LL | fn r({) { |      ^ unclosed delimiter LL |     Ok { LL |         d..||_=m |          -^ |          | |          help: `}` may belong here error[E0425]: cannot find value `d` in this scope --> $DIR/issue-92481.rs:7:9 | LL |         d..||_=m |         ^ not found in this scope error[E0425]: cannot find value `m` in this scope --> $DIR/issue-92481.rs:7:16 | LL |         d..||_=m |                ^ not found in this scope error[E0559]: variant `Result<_, _>::Ok` has no field named `d` --> $DIR/issue-92481.rs:7:9 | LL |         d..||_=m |         ^ field does not exist --> $SRC_DIR/core/src/result.rs:LL:COL | = note: `Result<_, _>::Ok` defined here | help: `Result<_, _>::Ok` is a tuple variant, use the appropriate syntax | LL |     Result<_, _>::Ok(/* fields */) | error[E0308]: mismatched types --> $DIR/issue-92481.rs:6:5 | LL |   fn r({) { |           - help: a return type might be missing here: `-> _` LL | /     Ok { LL | |         d..||_=m LL | |     } | |_____^ expected `()`, found enum `Result` | = note: expected unit type `()` found enum `Result<_, _>` error: aborting due to 6 previous errors Some errors have detailed explanations: E0308, E0425, E0559. For more information about an error, try `rustc --explain E0308`. </ins>
Change:
A further performance improvement here would be to make sure that impls , in which case we could use rather than , avoiding the allocation of a temporary here. internally seems to just hold a and it has and methods already, so perhaps it would make sense to implement that trait? I'm not sure how big/relevant the performance improvement would be. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Since implementers get a generated for them by Askama's macro, the simpler way to get the meat of this change would probably be to call
claim Let me take a stab at it :)

Discussion:
buffer: String, } <ins> impl core::fmt::Write for Buffer { #[inline] fn write_str(&mut self, s: &str) -> fmt::Result { self.buffer.write_str(s) } #[inline] fn write_char(&mut self, c: char) -> fmt::Result { self.buffer.write_char(c) } #[inline] fn write_fmt(self: &mut Self, args: fmt::Arguments<'_>) -> fmt::Result { self.buffer.write_fmt(args) } } </ins> impl Buffer { crate fn empty_from(v: &Buffer) -> Buffer { Buffer { for_html: v.for_html, buffer: String::new() }

src_href: src_href.as_deref(), }; <del> let heading = item_vars.render().unwrap(); buf.write_str(&heading); </del> <ins> item_vars.render_into(buf).unwrap(); </ins> match *item.kind { clean::ModuleItem(ref m) => item_module(buf, cx, item, &m.items),
Change:
<!-- 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. --Example code: docs build successfully on 1.57.0: docs fail to build on 1.59.0-nightly ( 2022-01-04): </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --The generics appear necessary for the bug. Removing them from either the type or the trait resolves the failure. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Probably . searched nightlies: from nightly-2022-01-06 to nightly-2022-01-07 regressed nightly: nightly-2022-01-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: aarch64-apple-darwin Reproduce with: </details
just saw this, I think might be caused by this change: I'm looking into it
claim

Discussion:
ty ); // Fast path: if this is a primitive simple `==` will work <del> let saw_impl = impl_type == ty; </del> <ins> // NOTE: the `match` is necessary; see #92662. // this allows us to ignore generics because the user input // may not include the generic placeholders // e.g. this allows us to match Foo (user comment) with Foo<T> (actual type) let saw_impl = impl_type == ty || match (impl_type.kind(), ty.kind()) { (ty::Adt(impl_def, _), ty::Adt(ty_def, _)) => { debug!("impl def_id: {:?}, ty def_id: {:?}", impl_def.did, ty_def.did); impl_def.did == ty_def.did } _ => false, }; </ins> if saw_impl { Some(trait_) } else { None } })

pub type ExternType; } <ins> pub trait T { fn test(&self) {} } pub trait G<N> { fn g(&self, n: N) {} } </ins> impl ExternType { <del> pub fn f(&self) { </del> <ins> pub fn f(&self) {} } </ins> <del> } </del> <ins> impl T for ExternType { fn test(&self) {} } impl G<usize> for ExternType { fn g(&self, n: usize) {} </ins> } // @has 'extern_type/foreigntype.ExternType.html' // @has 'extern_type/fn.links_to_extern_type.html'  // 'href="foreigntype.ExternType.html#method.f"' <ins> // @has 'extern_type/fn.links_to_extern_type.html'  // 'href="foreigntype.ExternType.html#method.test"' // @has 'extern_type/fn.links_to_extern_type.html'  // 'href="foreigntype.ExternType.html#method.g"' </ins> /// See also [ExternType::f] <ins> /// See also [ExternType::test] /// See also [ExternType::g] </ins> pub fn links_to_extern_type() {}

<ins> #![deny(rustdoc::broken_intra_doc_links)] // Test intra-doc links on trait implementations with generics // regression test for issue #92662 use std::marker::PhantomData; pub trait Bar<T> { fn bar(&self); } pub struct Foo<U>(PhantomData<U>); impl<T, U> Bar<T> for Foo<U> { fn bar(&self) {} } // @has generic_trait_impl/fn.main.html '//a[@href="struct.Foo.html#method.bar"]' 'Foo::bar' /// link to [`Foo::bar`] pub fn main() {} </ins>
Change:
Given the following code (): The current output is: Ideally, the output should be the same as when such a call is made in a item: ... which can be improved further with the suggestion given in : modify labels: +A-const-eval +A-traits +D-confusing +D-terse +F-consttraitimpl +F-inlineconst <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

Discussion:
let body = self.tcx.hir().body(anon_const.body); // Create a new function context. <del> let fcx = FnCtxt::new(self, self.param_env, body.value.hir_id); </del> <ins> let fcx = FnCtxt::new(self, self.param_env.with_const(), body.value.hir_id); </ins> crate::check::GatherLocalsVisitor::new(&fcx).visit_body(body); let ty = fcx.check_expr_with_expectation(&body.value, expected);

<ins> #![allow(unused)] #![feature(const_fn_trait_bound, const_trait_impl, inline_const)] const fn f<T: ~const Drop>(x: T) {} struct UnconstDrop; impl Drop for UnconstDrop { fn drop(&mut self) {} } fn main() { const { f(UnconstDrop); //~^ ERROR the trait bound `UnconstDrop: Drop` is not satisfied } } </ins>

<ins> error[E0277]: the trait bound `UnconstDrop: Drop` is not satisfied --> $DIR/const-block-const-bound.rs:14:11 | LL |         f(UnconstDrop); |         - ^^^^^^^^^^^ the trait `Drop` is not implemented for `UnconstDrop` |         | |         required by a bound introduced by this call | note: required by a bound in `f` --> $DIR/const-block-const-bound.rs:4:15 | LL | const fn f<T: ~const Drop>(x: T) {} |               ^^^^^^^^^^^ required by this bound in `f` help: consider introducing a `where` bound, but there might be an alternative better way to express this requirement | LL | fn main() where UnconstDrop: Drop { |           +++++++++++++++++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>
Change:
<!-- 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. --Minimized from a program was trying to debug. I tried this code: I expected to see this happen: Instead, this happened: I see this on aarch64 and not on x86_64. I don't have access to any other architectures. Output is as expected with . I can also observe this bug on the previous stable (1.56.1), current beta (1.58.0-beta.3) and current nightly ( 2022-01-10). :
Was able to also test Rust 1.53 & 1.55, both perform as expected and show i: 0
Are the numbers printed the same every time or do they vary?
Consistently on the problem arch & compilers
Thanks. The reason I was asking is that, if you're reading invalid memory, the result is usually random. Since this result is consistent, something else is probably going on.
For the sake of convenience, could you please provide the output for this program?
here you go:
It might be a coincidence but, is (4 bytes in 32-bits) and rounded to the . Seems like maybe the bits are being inverted?
~I'm able to reproduce with , but if I emit the IR and then compile it with , I do not see the issue.~ I get different IR if I compile with vs. the entire command from . Only the 2nd has the bug. Edit: It's caused by . Lowering it to removes the problem.
When I use the llc from the rustup toolchain, I see LLVM going wild with clobbers: Note that also gets passed , so we're actually converting some condition flags to float, which makes about zero sense. Weirdly I don't see this when using the llc from my local rust build :/
For this example, the llc distributed by rustup produces (with ): While my own build produces:
Looks like it works if LLVM is compiled with assertions and breaks when compiled without assertions :(
Are you saying that you can reproduce two different results using the same IR? I was seeing the issue with distributed from Homebrew. Not sure if that's compiled with or without assertions. I only see the problem with IR generated with and compiling with . This is the line of IR that is causing the issues. It is only present with and removing it fixes the bug: Additionally, it's only a problem if I assign to the spill directly. If I store a constant or use a temporary, the issue goes away.
seems like it may be relevant. Switching to fixes the miscompilation.
Bisect shows this is fixed by on main. Edit: It looks that shortly after that landed and the change was reverted again.
The revert comment suggests that it should be fixed by . Are you able to confirm?
I've filed to check whether we can still get this in 13.0.1, though probably not. In that case I'll cherry-pick into our fork.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical

Discussion:
<del> Subproject commit 6b3dbcc81a470e5da84576d63fcfc19e3b1154cd </del> <ins> Subproject commit 221a195b62f4373a8893f4d022e4ce981b09a857 </ins>
Change:
Given the following code (): The current output is: <details<summaryMassive diagnostic</summary</detailsIdeally, the duplicate lines should be hidden: modify labels: +A-const-fn +D-verbose <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Discussion:
} // Add spans for the stacktrace. Don't print a single-line backtrace though. if self.stacktrace.len() > 1 { <ins> // Helper closure to print duplicated lines. let mut flush_last_line = |last_frame, times| { if let Some((line, span)) = last_frame { err.span_label(span, &line); // Don't print [... additional calls ...] if the number of lines is small if times < 3 { for _ in 0..times { err.span_label(span, &line); } } else { err.span_label( span, format!("[... {} additional calls {} ...]", times, &line), ); } } }; let mut last_frame = None; let mut times = 0; </ins> for frame_info in &self.stacktrace { <del> err.span_label(frame_info.span, frame_info.to_string()); </del> <ins> let frame = (frame_info.to_string(), frame_info.span); if last_frame.as_ref() == Some(&frame) { times += 1; } else { flush_last_line(last_frame, times); last_frame = Some(frame); times = 0; } </ins> } <ins> flush_last_line(last_frame, times); </ins> } // Let the caller finish the job. emit(err)

<ins> #![allow(unused)] const fn f<T>(x: T) { //~ WARN function cannot return without recursing f(x); //~^ ERROR any use of this value will cause an error //~| WARN this was previously accepted by the compiler } const X: () = f(1); fn main() {} </ins>

<ins> warning: function cannot return without recursing --> $DIR/recursive.rs:3:1 | LL | const fn f<T>(x: T) { | ^^^^^^^^^^^^^^^^^^^ cannot return without recursing LL |     f(x); |     ---- recursive call site | = note: `#[warn(unconditional_recursion)]` on by default = help: a `loop` may express intention better if this is on purpose error: any use of this value will cause an error --> $DIR/recursive.rs:4:5 | LL |     f(x); |     ^^^^ |     | |     reached the configured maximum number of stack frames |     inside `f::<i32>` at $DIR/recursive.rs:4:5 |     [... 126 additional calls inside `f::<i32>` at $DIR/recursive.rs:4:5 ...] |     inside `X` at $DIR/recursive.rs:9:15 ... LL | const X: () = f(1); | ------------------- | = note: `#[deny(const_err)]` on by default = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800> error: aborting due to previous error; 1 warning emitted </ins>
Change:
The Windows CI build with LLVM assertions enabled recently hung without an error message. It turned out to be an LLVM assertion failure resulting in a dialog which needed to be acknowledged, see According to the such a dialog is always displayed, but that is not the whole truth. Apparently can be used to customize assertion failure handling. We should definitely make assertions failures exit with error after printing failure information to stderr instead of displaying a dialog and hanging. label O-windows
Could this be part of why we're getting so many hangs in the CI?
That was responsible for four stuck builds recently. I don't think it was responsible for many timed out builds before that.
Posted with a possible solution.

Discussion:
extern "C" { pub fn LLVMRustInstallFatalErrorHandler(); <ins> pub fn LLVMRustDisableSystemDialogsOnCrash(); </ins> // Create and destroy contexts. pub fn LLVMRustContextCreate(shouldDiscardNames: bool) -> &'static mut Context;

let mut llvm_args = Vec::with_capacity(n_args + 1); llvm::LLVMRustInstallFatalErrorHandler(); <ins> // On Windows, an LLVM assertion will open an Abort/Retry/Ignore dialog // box for the purpose of launching a debugger. However, on CI this will // cause it to hang until it times out, which can take several hours. if std::env::var_os("CI").is_some() { llvm::LLVMRustDisableSystemDialogsOnCrash(); } </ins> fn llvm_arg_to_arg_name(full_arg: &str) -> &str { full_arg.trim().split(|c: char| c == '=' || c.is_whitespace()).next().unwrap_or("")

install_fatal_error_handler(FatalErrorHandler); } <ins> extern "C" void LLVMRustDisableSystemDialogsOnCrash() { sys::DisableSystemDialogsOnCrash(); } </ins> extern "C" char *LLVMRustGetLastError(void) { char *Ret = LastError; LastError = nullptr;
Change:
We already translate from C-style formatting strings to Rust formatting strings when passed to the family of macros. We should also detect invalid calls from other languages that were meant to be macro calls: currently emits the dry while it could be <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Mentoring on this issue label +E-mentor

Discussion:
"you may want to use a bool value instead", format!("{}", item_typo), )) <ins> // FIXME(vicnenzopalazzo): make the check smarter, // and maybe expand with levenshtein distance checks } else if item_str.as_str() == "printf" { Some(( item_span, "you may have meant to use the `print` macro", "print!".to_owned(), )) </ins> } else { suggestion };

<ins> // Suggest to a user to use the print macros // instead to use the printf. fn main() { let x = 4; printf("%d", x); //~^ ERROR cannot find function `printf` in this scope //~| HELP you may have meant to use the `print` macro } </ins>

<ins> error[E0425]: cannot find function `printf` in this scope --> $DIR/seggest_print_over_printf.rs:6:5 | LL |     printf("%d", x); |     ^^^^^^ not found in this scope | help: you may have meant to use the `print` macro | LL |     print!("%d", x); |     ~~~~~~ error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </ins>
Change:
You'd expect the impl for the boxed type to show up, but it doesn't. I seem to recall rustdoc displays impls anytime the type is contained in the generics, though, so it's odd that it's not happening. Originally reported by (with ) .
also reported a case involving a impl that didn't show up on the trait's page. IIRC this issue is somewhat known already though.
I can't find a case where the impl is if the type is in the generics. Do you have an example maybe?
On Vec's page: !
That one's happening because of this thing. Notice that the generics on the trait count, but the generics on don't. We definitely need to fix this, specifically, for types, because that's how you wind up with impls that aren't actually documented anywhere.

Discussion:
use rustc_data_structures::fx::{FxHashMap, FxHashSet}; use rustc_hir::def_id::{CrateNum, DefId}; use rustc_middle::middle::privacy::AccessLevels; <del> use rustc_middle::ty::TyCtxt; </del> <ins> use rustc_middle::ty::{self, TyCtxt}; </ins> use rustc_span::{sym, Symbol}; use crate::clean::{self, types::ExternalLocation, ExternalCrate, ItemId, PrimitiveType};

clean::Type::Path { ref path } | clean::BorrowedRef { type_: box clean::Type::Path { ref path }, .. } => { dids.insert(path.def_id()); <ins> if let Some(generics) = path.generics() && let ty::Adt(adt, _) = self.tcx.type_of(path.def_id()).kind() && adt.is_fundamental() { for ty in generics { if let Some(did) = ty.def_id(&self.cache) { dids.insert(did); } } } </ins> } clean::DynTrait(ref bounds, _) | clean::BorrowedRef { type_: box clean::DynTrait(ref bounds, _), .. } => {

<ins> // https://github.com/rust-lang/rust/issues/92940 // // Show traits implemented on fundamental types that wrap local ones. pub struct MyType; // @has 'impl_box/struct.MyType.html' // @has '-' '//*[@id="impl-Iterator"]' 'impl Iterator for Box<MyType>' impl Iterator for Box<MyType> { type Item = (); fn next(&mut self) -> Option<Self::Item> { todo!() } } </ins>
Change:
I just on URLO about when to implement or not to implement , and I noticed that the trait are lacking. In particular, I believe they should definitely point out that implementing will give a type a method via the trait. This is important to keep in mind when you’re designing an API; it’s also the reason why in the standard library doesn’t implement directly (but offers a method): because converting to is lossy or fallible, and an (implicitly) lossy method would not fit the API. label A-docs, C-enhancement, T-libs-api <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim Edit: Not sure if I stole this from you , on my end it looks like you were unassigned most recently.

Discussion:
/// Format trait for an empty format, `{}`. /// <ins> /// Implementing this trait for a type will automatically implement the /// [`ToString`][tostring] trait for the type, allowing the usage /// of the [`.to_string()`][tostring_function] method. Prefer implementing /// the `Display` trait for a type, rather than [`ToString`][tostring]. /// </ins> /// `Display` is similar to [`Debug`], but `Display` is for user-facing /// output, and so cannot be derived. /// /// For more information on formatters, see [the module-level documentation][module]. /// /// [module]: ../../std/fmt/index.html <ins> /// [tostring]: ../../std/string/trait.ToString.html /// [tostring_function]: ../../std/string/trait.ToString.html#tymethod.to_string </ins> /// /// # Examples ///
Change:
<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Slightly minimized:
I understand the issue here, and have a solution but it might not be optimal. claim

Discussion:
// of  the function signature. In our example, the GAT in the return // type is `<Self as LendingIterator>::Item<'a>`, so 'a and Self are arguments. let (regions, types) = <del> GATSubstCollector::visit(trait_item.def_id.to_def_id(), sig.output()); </del> <ins> GATSubstCollector::visit(tcx, trait_item.def_id.to_def_id(), sig.output()); </ins> // If both regions and types are empty, then this GAT isn't in the // return type, and we shouldn't try to do clause analysis

/// the two vectors, `regions` and `types` (depending on their kind). For each /// parameter `Pi` also track the index `i`. struct GATSubstCollector<'tcx> { <ins> tcx: TyCtxt<'tcx>, </ins> gat: DefId, // Which region appears and which parameter index its subsituted for regions: FxHashSet<(ty::Region<'tcx>, usize)>,

impl<'tcx> GATSubstCollector<'tcx> { fn visit<T: TypeFoldable<'tcx>>( <ins> tcx: TyCtxt<'tcx>, </ins> gat: DefId, t: T, ) -> (FxHashSet<(ty::Region<'tcx>, usize)>, FxHashSet<(Ty<'tcx>, usize)>) { <del> let mut visitor = GATSubstCollector { gat, regions: FxHashSet::default(), types: FxHashSet::default() }; </del> <ins> let mut visitor = GATSubstCollector { tcx, gat, regions: FxHashSet::default(), types: FxHashSet::default(), }; </ins> t.visit_with(&mut visitor); (visitor.regions, visitor.types) }

impl<'tcx> TypeVisitor<'tcx> for GATSubstCollector<'tcx> { type BreakTy = !; <ins> fn visit_binder<T: TypeFoldable<'tcx>>( &mut self, t: &ty::Binder<'tcx, T>, ) -> ControlFlow<Self::BreakTy> { self.tcx.liberate_late_bound_regions(self.gat, t.clone()).visit_with(self) } </ins> fn visit_ty(&mut self, t: Ty<'tcx>) -> ControlFlow<Self::BreakTy> { match t.kind() { ty::Projection(p) if p.item_def_id == self.gat => {

<ins> // check-pass #![feature(generic_associated_types)] pub trait Foo { type Assoc<'c>; fn function() -> for<'x> fn(Self::Assoc<'x>); } fn main() {} </ins>