jiebi/CodeConvo huggingface dataset:
Change:
<del> Subproject commit 4729175045b41b688ab903120860866ce7a22ba9 </del> <ins> Subproject commit c416fb60b11ecfd2a1ba0fb8567c9a92590b5d28 </ins>

Discussion:
Reported on Unfortunately the source is not available, but can you perhaps help reproduce?
What do you mean source is not available? How did you find the regression in the first place?
I mean that I can't find the git repo. The source can be acquired from the published crate tarball. Edit: er, I didn't file this bug, but that's what meant.
The repo has been deleted for some time now - I tried to delete it from cargo but that's not allowed.
Should probably still be investigated, unless doesn't want us testing his yanked crate. We'll have to grab it from I wonder if maybe cargobomb shouldn't test yanked crates.
This is a regression in Cargo. With a that looks like: And files at and on stable Cargo will compile , on beta Cargo will compile instead. cc is this related to perhaps?
Hi will investigate this today, but looks like it is related.
Thanks
Sorry about the hassle guys. I removed it because I didn't want my useless and dead project polluting things up, but that just caused more trouble! No worries about testing my yanked crate.
oh no worries! This crate helped us detect a regression and what's what we're worried about :)
Hi I think this was caused by this: , but it worked because of the bug I fixed in 3609 (cargo always assumed as a source file for a bin target). You can find the proposed fix in rust-lang/cargo. I tried to get rid of quick fixes and implement a full featured solution for inferring bin target's source file paths. Please review the inferring logic — I am not 100% sure that it covers all cargo's usecases, but it seems reasonable for me.
Awesome thanks for the investigation
Change:
To contribute to Rust, please see [CONTRIBUTING](CONTRIBUTING.md). <del> Rust has an [IRC] culture and most real-time collaboration happens in a variety of channels on Mozilla's IRC network, irc.mozilla.org. The most popular channel is [#rust], a venue for general discussion about Rust. And a good place to ask for help would be [#rust-beginners]. </del> <ins> Most real-time collaboration happens in a variety of channels on the [Rust Discord server][rust-discord], with channels dedicated for getting help, community, documentation, and all major contribution areas in the Rust ecosystem. A good place to ask for help would be the #help channel. </ins> The [rustc guide] might be a good place to start if you want to find out how various parts of the compiler work. Also, you may find the [rustdocs for the compiler itself][rustdocs] useful. <del> [IRC]: https://en.wikipedia.org/wiki/Internet_Relay_Chat [#rust]: irc://irc.mozilla.org/rust [#rust-beginners]: irc://irc.mozilla.org/rust-beginners </del> <ins> [rust-discord]: https://discord.gg/rust-lang </ins> [rustc guide]: https://rust-lang.github.io/rustc-guide/about-this-guide.html [rustdocs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/

Discussion:
There are still of IRC in the repo. Removing them is not a priority but it will avoid confusion for newcomers.
Should these places be replaced with references to the rust discord server, or just be removed outright?
Probably replaced. Gonna update title.
Opened to address this.
This is horrible. Replacing IRC with Discord.. :/
If you haven't read about it yet, is the post from April.
Yeah I read already. I'd remove the mention of any particular discussion channel, instead of putting Discord in. I can't wait for Matrix to become more mature so the Rust project can use it. Falling back to Discord is quite bad for a FOSS project.
IMO we should just mirror subreddit solution and point to Discord.
Change:
fn check_macro_export(&self, hir_id: HirId, attr: &Attribute, target: Target) { if target != Target::MacroDef { <del> self.tcx.emit_spanned_lint(UNUSED_ATTRIBUTES, hir_id, attr.span, errors::MacroExport); </del> <ins> self.tcx.emit_spanned_lint( UNUSED_ATTRIBUTES, hir_id, attr.span, errors::MacroExport::Normal, ); } else if let Some(meta_item_list) = attr.meta_item_list() && !meta_item_list.is_empty() { if meta_item_list.len() > 1 { self.tcx.emit_spanned_lint( INVALID_MACRO_EXPORT_ARGUMENTS, hir_id, attr.span, errors::MacroExport::TooManyItems, ); } else { if meta_item_list[0].name_or_empty() != sym::local_inner_macros { self.tcx.emit_spanned_lint( INVALID_MACRO_EXPORT_ARGUMENTS, hir_id, meta_item_list[0].span(), errors::MacroExport::UnknownItem { name: meta_item_list[0].name_or_empty(), }, ); } } </ins> } }

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. --I tried this code: I expected to see this happen: it shouldn't compile Instead, this happened: it compiles <!-- 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<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
For anyone who would like to work on this, the following code needs to be adjusted to check if the meta-item list is empty or if it only contains the identifier (i.e. only allowing the attribute to be or : Due to backward compatibility concerns, probably only a future-incompat warning should be issued if the verification fails. label T-compiler A-attributes
claim
First rust-lang/rust contribution I hope this goes well
Change:
} n }]; <ins> s.nonexistent_method(); </ins> }

Discussion:
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
Regression in nightly-2023-06-02 Regression in cc
Change:
<del> #!/bin/bash set -euo pipefail IFS=$'nt' source "$(cd "$(dirname "$0")" && pwd)/../shared.sh" if isWindows; then pacman -S --noconfirm --needed base-devel ca-certificates make diffutils tar  binutils # Detect the native Python version installed on the agent. On GitHub # Actions, the C:hostedtoolcachewindowsPython directory contains a # subdirectory for each installed Python version. # # The -V flag of the sort command sorts the input by version number. native_python_version="$(ls /c/hostedtoolcache/windows/Python | sort -Vr | head -n 1)" # Make sure we use the native python interpreter instead of some msys equivalent # one way or another. The msys interpreters seem to have weird path conversions # baked in which break LLVM's build system one way or another, so let's use the # native version which keeps everything as native as possible. python_home="/c/hostedtoolcache/windows/Python/${native_python_version}/x64" cp "${python_home}/python.exe" "${python_home}/python3.exe" ciCommandAddPath "C:hostedtoolcachewindowsPython${native_python_version}x64" ciCommandAddPath "C:hostedtoolcachewindowsPython${native_python_version}x64Scripts" fi </del>

Discussion:
On 2019-10-24 we had a CI outage due to the ca-certificates msys2 package being broken. The hack implemented (:heart:) is to download an older, known good package beforehand and install it after msys2 updated its packages. Once is fixed we should revert the hack, but I think at this point it's worth investing in vendoring msys2 as a whole.
msys2 is using and other tools from archlinux distro. Arch Linux provides per-day official repositories snapshots. User can "pin" to a specific date. I think it is possible to reuse that mechanism to vendoring msys2 as a whole, by providing a mirror of a specific date's version. See here for more descriptions .
that would be nice but msys doesn't remove old packages from their repo so the mirror would be enormous. Search for in , only those packages take dozens of GiB. Also extracting it from archive would make CI a bit faster because you won't be modifying thousands of small files over and over. On Linux that is not a problem but working through cygwin emulation a bit struggles on this part.
No update on this, planning to discuss what to vendor at the all hands.
At the last infra meeting we decided a good step is to move towards using the pre-installed msys2 packages. In theory this is as simple as removing the msys2 installation step and pointing things at the right location on the images in CI.
Change:
// // Not OK: `T` is not sized. <del> enum Bar<U: ?Sized> { BarSome(U), BarNone } fn bar1<T: ?Sized>() { not_sized::<Bar<T>>() } fn bar2<T: ?Sized>() { is_sized::<Bar<T>>() } //~^ ERROR `T: std::marker::Sized` is not satisfied // // Not OK: `Bar<T>` is not sized, but it should be. </del> fn main() { }

Discussion:
Backtrace: This seems to occur when using a non-struct type that contains an unsized type. This is probably because  only handles and the base unsized types. This should be extended to handle enums and tuples as well.
This is still happening. Does this mean we should avoid using DSTs for complex custom types for now?
Visiting for triage This is still an issue:
ICE also happens with a tupled trait object:
I've seen this too with: Reproducer: Version: Backtrace:
No longer reproduces but the other tests do.
cc
Is this the same as or related to ?
leads to . As mentioned inline, using the correct type works (). I'm using the Ubuntu PPA "rust-nightly", version ~~vivid.
Does not compile for other reasons that the ICE anymore. I've adjusted to the following and could not reproduce it anymore.
Another example hitting this same ICE:
Bugs similar to this one have been reported numerous times (most of the references to this issue are duplicates). Although it would be nice for reporters to search for similar issues before filing a new one, it's hard to blame them, since the ICE message from rustc tells people to file an issue. This issue itself was opened over two years ago. Separate from fixing the underlying problem, we should at least investigate displaying a real error instead of an ICE.
Change:
} } <del> fn recover_stmt_local( </del> <ins> fn recover_stmt_local_after_let( </ins> &mut self, lo: Span, attrs: AttrWrapper, subdiagnostic: fn(Span) -> InvalidVariableDeclarationSub, ) -> PResult<'a, Stmt> { <del> let stmt = self.recover_local_after_let(lo, attrs)?; </del> <ins> let stmt = self.collect_tokens_trailing_token(attrs, ForceCollect::Yes, |this, attrs| { let local = this.parse_local(attrs)?; // FIXME - maybe capture semicolon in recovery? Ok(( this.mk_stmt(lo.to(this.prev_token.span), StmtKind::Local(local)), TrailingToken::None, )) })?; </ins> self.sess.emit_err(InvalidVariableDeclaration { span: lo, sub: subdiagnostic(lo) }); Ok(stmt) }

Discussion:
<!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details label A-parser A-macros <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
cc this should probably be gated with your "may eagerly recover" work as well
This code is actually already mentioned in ;)
claim
Yeah, gating this recovery behind a is the correct fix here.
Also very fun that these things can ICE sometimes.
Found these also panic: Since these are highly related to the case, one pull request can fix all of these (maybe).
Change:
<ins> fn main() { // this closure is fine, and should not get any error annotations let em = |v: f64| -> f64 { v }; let x: f64 = em(1i16.into()); let y: f64 = 0.01f64 * 1i16.into(); //~^ ERROR type annotations needed //~| HELP try using a fully qualified path } </ins>

Discussion:
I tried this code: () The error message: I expected to see this happen: The error is reported on the line for . Instead, this happened: The error is reported for the closure… Nighty, Beta and Stable affected.
modify labels: +A-diagnostics +C-bug +D-incorrect (someone other than the issue creator do this?)
More minimal repro: The closure just needs to be exist anywhere inside . Even this code reports the same error: Edit: this triggers the same issue:
This is essentially the same issue as
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-92010-trait-bound-not-satisfied.rs:8:43 | LL |     fn y(&self, y: f64) -> Self { P{y, .. self.clone() } } |                                           ^^^^^^^^^^^^ expected struct `P`, found `&P<T>` | = note: expected struct `P<T>` found reference `&P<T>` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </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. --The following code: triggers a panic in the compiler (see below). All works as expected if I write . <!-- 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
Output on stable: (An awkward but correct error - without , the compiler uses autoref to resolve as which returns .) searched nightlies: from nightly-2021-10-16 to nightly-2021-11-28 regressed nightly: nightly-2021-11-10 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details label regression-from-stable-to-beta
Probably ?
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I think this is a duplicate of , and I also put up a fix in (along with both in and in ) which has been waiting for a review for quite some time.. Not sure which one of our PRs should be approved, but at least one of them should :^) -- re: , I agree with Aaron that this is the simpler and more targeted fix for the bug, so I'll just close mine after this gets approved probably. (edit: made it clearer who I was referring to in the original comment - lol, sorry)
thanks for the note! I'll also add (as a self-reminder) that in Aaron also that might be a better fix.
Change:
} fn main() { <del> // FIXME(generic_const_exprs): Improve the error message here. </del> use_dyn(&()); //~^ ERROR type annotations needed }

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. --Based on the example in , which after the changes in would output an error. The following code, however, does not output such an error, although I believe it should. Given the following code: <!-- Please provide a link to --The current output is: This only happens if the is included. This also compiles if you don't include the call of in main. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
dont think this is related to adtconstparams as this has the same error:
the reason this happens is because from we don't infer the value for . The error message should be improved by using in this branch for that the predicates should be searched for a relevant inference variable.
going to mentor this issue in case someone wants to fix this
claim
Change:
<ins> #[derive(Clone)] //~  trait objects must include the `dyn` keyword //~| trait objects must include the `dyn` keyword struct Foo; trait Foo {} //~ the name `Foo` is defined multiple times fn main() {} </ins>

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> error[E0080]: evaluation of `Bar::<0>::ASSERT` failed --> $DIR/mono-reachable-invalid-const.rs:8:9 | LL |         ["oops"][b]; |         ^^^^^^^^^^^ index out of bounds: the length is 1 but the index is 1 note: erroneous constant encountered --> $DIR/mono-reachable-invalid-const.rs:13:19 | LL |         let val = Self::ASSERT; |                   ^^^^^^^^^^^^ note: erroneous constant encountered --> $DIR/mono-reachable-invalid-const.rs:13:19 | LL |         let val = Self::ASSERT; |                   ^^^^^^^^^^^^ | = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` note: the above error was encountered while instantiating `fn Bar::<0>::assert` --> $DIR/mono-reachable-invalid-const.rs:22:5 | LL |     Bar::<0>::assert(); |     ^^^^^^^^^^^^^^^^^^ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0080`. </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. --I encountered an ICE while playing with 's that has to do with its comptime assertions. I have not been able to reproduce the ICE when inlining the constant value in which the checks are performed. Perhaps it is related with the fact that originally there was a crate boundary? I have an inkling const blocks' merger might be to blame. <!-- 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
It would be useful to have a minimal example that doesn't involve the entire tagged_ptr crate.
Reduced: , needs This bisects to cc label A-monomorphization S-has-mcve -E-needs-mcve
ye olde "compiler must not crash on invalid code" problem
PR with a fix is up. Thanks for catching this before the bug hit beta
No, thanks to you all for not only fixing it, but running this amazing project every day. I hope I have more time in the future so that I can spend it here and be a part of this.
Change:
let did = i.trait_.as_ref().unwrap().def_id().unwrap(); let assoc_link = AssocItemLink::GotoSource(did, &i.provided_trait_methods); <del> doctraititem(w, cx, trait_item, assoc_link, render_static, </del> <ins> doctraititem(w, cx, trait_item, assoc_link, render_static, true, </ins> outer_version)?; } Ok(())

Discussion:
I use documentation on my trait impls to tell users about how my types behave: This documentation is not rendered anymore. I expect to see it under the entry for the implementation of the type. I think this was lost after (the otherwise very awesome!) documentation changes by
Note: Documentation on top of the item itself is properly rendered. If you too agree this is adequate, please close the issue again.
Just for reference: this also leaves the (perhaps not entirely obvious) operator impls on HashSets undocumented. Also see on this issue.
Yes, is dup of this. It is hiding stable parts of std from me:
Change:
<del> Subproject commit 4b85255772114ca4946d95fe591933dae7d61991 </del> <ins> Subproject commit 2a2ea6b49e79325e0d10d33fac2b10ea3bebcc7c </ins>

Discussion:
My project uses arm neon intrinsics. The arm test starts failing after 2022-10-04. Reproduce: works (incremental compilation enabled) fails (incremental compilation disabled) I'm not sure how to find a MCVE for this issue, so I put the original context 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. --:
Looks like stdarch hardcodes LLVM intrinsic mangling in a few places. These should be changed from p0i8 to just p0 in LLVM 15: Usually this gets gracefully handled through intrinsic remangling, I don't know why that doesn't occur for your particular case. Updating stdarch to directly use the right names should avoid any problems though. cc
Does this apply to all extensions or just ? For example .
It applies to all extensions.
Minimal reproduction on godbolt: Any idea why LLVM auto-upgrade isn't working in this case?
Thanks for the minimal reproducer. This turned out to be a simple typo, fixed in This was hidden when doing simple tests with opt because the IR parser was doing another redundant remangle (fixed in and ). Backport request:
Change:
#[stable(feature = "core_c_void", since = "1.30.0")] pub use core::ffi::c_void; <del> #[unstable(feature = "core_ffi_c", issue = "94501")] pub use core::ffi::{ c_char, c_double, c_float, c_int, c_long, c_longlong, c_schar, c_short, c_uchar, c_uint, c_ulong, c_ulonglong, c_ushort, }; #[unstable(feature = "c_size_t", issue = "88345")] pub use core::ffi::{c_ptrdiff_t, c_size_t, c_ssize_t}; </del> #[unstable( feature = "c_variadic", reason = "the `c_variadic` feature has not been properly tested on 

Discussion:
https://crater- https://crater- https://crater- https://crater- Introduced by , most likely, cc
One reasonable fix is to stabilize these types in . That will allow using reexports instead of type aliases, which will remove the ambiguities. They are the same types as stable types in just exposed from a different (but also stable) location in the same crate. (That said, glob vs glob is an acceptable breakage according to the library policy.)
That would be a fast stabilization, but given that they're rather simple types, that seems potentially reasonable.
If we were to stabilize, presumably we'd do that on master and back out the PR from beta? I am reluctant to backport a stabilization to fix this (particularly a fast one, as you mention).
Yeah, reverting the PR on beta seems fine for now.
Change:
fn report_cast_error(&self, fcx: &FnCtxt<'a, 'gcx, 'tcx>, e: CastError) { match e { CastError::NeedDeref => { <ins> let error_span = self.span; </ins> let cast_ty = fcx.ty_to_string(self.cast_ty); <del> let mut err = fcx.type_error_struct(self.cast_span, </del> <ins> let mut err = fcx.type_error_struct(error_span, </ins> |actual| { format!("casting `{}` as `{}` is invalid", actual, cast_ty) }, self.expr_ty); <del> err.span_label(self.expr.span, </del> <ins> err.span_label(error_span, </ins> &format!("cannot cast `{}` as `{}`", fcx.ty_to_string(self.expr_ty), cast_ty)); if let Ok(snippet) = fcx.sess().codemap().span_to_snippet(self.expr.span) { <del> err.span_label(self.expr.span, </del> <ins> err.span_help(self.expr.span, </ins> &format!("did you mean `*{}`?", snippet)); } err.emit();

Discussion:
When working on PR , I ended up with the following output: The second span label points at the first character of the span, but because there's already a larger span there, the actual extent of that span is lost. I believe that either the shortest span should be shown within the existing span: there should be a new character introduced for when multiple labels overlap: or at the very least, colorize the smaller span with the secondary label's color:
Will be fixed when PR gets merged.