jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: redundant explicit link target --> $DIR/issue-120444-2.rs:10:13 | LL | /// [`Vfs`][crate::Vfs] |      -----  ^^^^^^^^^^ explicit target is redundant |      | |      because label contains path that resolves to same destination | = note: when a link's destination is not specified, the label is used to resolve intra-doc links note: the lint level is defined here --> $DIR/issue-120444-2.rs:3:9 | LL | #![deny(rustdoc::redundant_explicit_links)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove explicit link target | LL | /// [`Vfs`] |     ~~~~~~~ error: aborting due to 1 previous error </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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage
Change:
def_id: fn_trait_def_id, substs: tcx.mk_substs(trait_substs), }); <del> ty::Binder((trait_ref, sig.0.output.unwrap())) </del> <ins> ty::Binder((trait_ref, sig.0.output.unwrap_or(ty::mk_nil(tcx)))) </ins> } impl<'tcx,O:Repr<'tcx>> Repr<'tcx> for super::Obligation<'tcx, O> {

Discussion:
Compiler panics, when closure marked as diverging. I tried this code: I expected to see this happen: Instead, this happened: : Backtrace:
Change:
<ins> error[E0277]: the trait bound `T: Clone` is not satisfied --> $DIR/derive-clone-for-eq.rs:6:17 | LL | #[derive(Clone, Eq)] |                 ^^ the trait `Clone` is not implemented for `T` | note: required because of the requirements on the impl of `PartialEq` for `Struct<T>` --> $DIR/derive-clone-for-eq.rs:9:19 | LL | impl<T: Clone, U> PartialEq<U> for Struct<T> |                   ^^^^^^^^^^^^     ^^^^^^^^^ note: required by a bound in `Eq` --> $SRC_DIR/core/src/cmp.rs:LL:COL | LL | pub trait Eq: PartialEq<Self> { |               ^^^^^^^^^^^^^^^ required by this bound in `Eq` = note: this error originates in the derive macro `Eq` (in Nightly builds, run with -Z macro-backtrace for more info) help: consider restricting type parameter `T` | LL | pub struct Struct<T: std::clone::Clone>(T); |                    +++++++++++++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
Let's say I want my struct to be comparable with anything that can be converted into the struct itself, but the actual comparison requires : () Errors:
For reference,
Change:
<ins> // The ayu theme has a different color for the "<code>" tags in the doc blocks. We need to // check that the rule isn't applied on other "<code>" elements. goto: file://|DOC_PATH|/test_docs/enum.AnEnum.html // We need to show the text, otherwise the colors aren't "computed" by the web browser. show-text: true // We set the theme to ayu. local-storage: {"rustdoc-theme": "ayu", "rustdoc-preferred-dark-theme": "ayu", "rustdoc-use-system-theme": "false"} // We reload to get the text appearing and the theme applied. reload: assert-css: (".docblock code", {"color": "rgb(255, 180, 84)"}, ALL) // It includes variants and the "titles" as well (for example: "impl RefUnwindSafe for AnEnum"). assert-css: ("div:not(.docblock) > code", {"color": "rgb(197, 197, 197)"}, ALL) </ins>

Discussion:
Ayu-only. The summary in the search results is now blue, when it used to be white. ! ! Ayu-only. The color of impls in Ayu has changed from white to yellow. This may be intentional, but it looked off when I saw it. Note that this happens for all impls, not just foreign impls. ! ! All themes. Certain auto-trait, foreign, unconditional impls have underlines. ! ! All themes. The phrase next to in the search results is now red in addition to itself being red, whereas used to be gray. ! ! All of the regressions seem to have occurred in beta (1.54.0).
Regression 3 is fixed in
Sending a fix for the three others.
Regressions 1 and 4 are fixed in .
Change:
<ins> trait Foo<const M: u8, const M: u8 = M> {} //~^ ERROR the name `M` is already used for a generic parameter in this item's generic parameters impl Foo<2> for () {} fn main() {} </ins>

Discussion:
Found with a <details<summaryFull output including backtrace</summary</detailsRegression in nightly-2021-04-26, possibly from ( label +A-const-generics
Here's a simpler case that ICEs in a similar way. It ICEd at least as far back as nightly-2018-01-01 (with the keyword removed for older versions). Output: <details<summaryFull output</summary</details
A similar thing was fixed a week ago in but maybe a more general fix is needed.
This fix probably needs to go into the resolver -- Using to distinguish the identifers in the example: I think the issue is that is resolving to , instead of , so when we do the partial substitution of default const params, we end up trying to look for while is being created.
Similar ICE with struct instead of impl trait:
This would be inconsistent with how lifetimes work. You can have . I suggest a check in astconv, replacing the self-referential type/const by error type/const.
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test calling methods on an impl for a bare trait. This test checks trait impls // must be in the same module as the trait. mod Foo { trait T {} } mod Bar { impl<'a> ::Foo::T+'a { //~ERROR: inherent implementations may only be implemented in the same fn foo(&self) {} } } fn main() {} </ins>

Discussion:
This code: generates this error: I couldn't find any existing issue on this, but this is expected to work, right?
cc
Was this in an RFC?
DST was pre-RFC (the design anyway), so no, it was not.
It as a good question whether this is supposed to work or not. Since traits are types now, just unsized, I would say "yes". But since an impl for a trait is no different to just providing default methods, perhaps we want to avoid that overlap. Shouldn't be hard to fix if we all agree on "yes", but cc to check he agrees.
As I understand it, an for a trait would be quite different than providing default methods: Even when a trait object is formed, there's no dynamic dispatch (vtable entries) for these methods. The methods cannot be overridden in an . The methods may also exist on the trait, in which case (according to our dispatch rules) the inherent versions would take precedence. I think the closer correspondence is to creating an extension trait with a blanket -- and given that inherent s are in some sense supposed to be equivalent to "anonymous", always-in-scope extension traits, I think that makes sense. My guess is that this was an intended, but implicit part of the DST proposal, but can speak more directly to that.
These subtle differences make me want it less. But the blanket impl-like use case seems legitimate. I agree with the intended but implicit assessment - I vaguely remember this coming up as a use case at some point
I've always assumed this would work but I'm curious was there a specific point in the libraries that required it?
IIRC this came out of playing around with the method definitions, which are currently all provided by extension traits. Not a huge deal if we can't do this for 1.0.
I started looking at this, but the hard bits seem to be some adjustment to method selection, so I'll wait on landing before doing this
I think there is some serious utility in providing this, especially for things like Any. I will try to dig up some other use-cases. Note that since is currently marked adding this later would mean deprecations etc.
Change:
use fmt; use hash::{Hash, self}; use iter::IntoIterator; <del> use marker::{Sized, Unsize}; </del> <ins> use marker::{Copy, Sized, Unsize}; </ins> use option::Option; use slice::{Iter, IterMut, SliceExt};

Discussion:
broke this code:
Clone is not implemented for anymore, because it now requires (previously ), which doesn't hold for arrays bigger than 32.
I'm assuming that trying to call on an would previously ICE the compiler?
In certain contexts, such as it would / will ICE yes, issue
Ah, the bound was before.
If only we had type level integers so we could just properly implement Clone for all fixed size array sizes without massive bloat.
It doesn't even requires actual numbers, most of impls act on "size-erased" arrays. Something like would be enough.
how would that work? Don't you need to loop N times to do the actual clone?
Something like: So is not used explicitly in the implementation, although it is still needed by internally. Whether it is easier to implement than type level integers or not is a separate question.
Change:
variant_index: VariantIdx, ) -> InterpResult<'tcx, Option<(ScalarInt, usize)>> { match self.layout_of(ty)?.variants { <del> abi::Variants::Single { index } => { assert_eq!(index, variant_index); Ok(None) } </del> <ins> abi::Variants::Single { .. } => Ok(None), </ins> abi::Variants::Multiple { tag_encoding: TagEncoding::Direct,

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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: [tagforvariant] computing variant tag for enum [evaluateobligation] evaluating trait selection obligation --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
That is the transmutability check asking for the discriminant of an uninhabited variant. I'm not sure what that code is doing with this information, but probably it makes sense to just remove the assertion and treat uninhabited variants like niched variants -- writing their discriminant is a NOP, but then the validation we do will definitely fail as the uninhabited variant cannot actually be represented in-memory. Cc
claim
Change:
RegionsNoOverlap(a, b) => { return tcx.lift(&(a, b)).map(|(a, b)| RegionsNoOverlap(a, b)) } <del> RegionsInsufficientlyPolymorphic(a, b) => { return tcx.lift(&b).map(|b| RegionsInsufficientlyPolymorphic(a, b)) </del> <ins> RegionsInsufficientlyPolymorphic(a, b, ref c) => { let c = c.clone(); return tcx.lift(&b).map(|b| RegionsInsufficientlyPolymorphic(a, b, c)) </ins> } <del> RegionsOverlyPolymorphic(a, b) => { return tcx.lift(&b).map(|b| RegionsOverlyPolymorphic(a, b)) </del> <ins> RegionsOverlyPolymorphic(a, b, ref c) => { let c = c.clone(); return tcx.lift(&b).map(|b| RegionsOverlyPolymorphic(a, b, c)) </ins> } IntMismatch(x) => IntMismatch(x), FloatMismatch(x) => FloatMismatch(x),

Discussion:
This code: Produces this internal compiler error: Interestingly, changing to or causes the code compile fine (modulo unused variable warnings). : Backtrace:
This is a regression in 1.17.0-beta. Earlier versions give:
Duplicate of .

Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.
Change:
<ins> error[E0282]: type annotations needed for `A<std::result::Result<std::result::Result<(), E>, Error>>` --> $DIR/issue-104649.rs:24:9 | LL |     let a = A(Result::Ok(Result::Ok(()))); |         ^ | help: consider giving `a` an explicit type, where the type for type parameter `E` is specified | LL |     let a: A<std::result::Result<std::result::Result<(), E>, Error>> = A(Result::Ok(Result::Ok(()))); |          +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0282`. </ins>

Discussion:
<details</summary</details<!-- 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. --:
I will try to reduce this to an MCVE.
Changing to appears to avoid the ICE, so that may be a useful place to focus.
Minimized it down to 60 lines without any dependencies. Maybe it can be minimized further but it's getting really hard. I've also left a few comments to say what's going on. <details<summary"Minimized" </summary</details
This appears to have regressed in Rust 1.64
This continues to ICE on beta and nightly
I bisected the regression, here is the output of : searched nightlies: from nightly-2022-06-24 to nightly-2022-08-05 regressed nightly: nightly-2022-07-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
Out of these seems the most likely, cc
Zooming onto changeset.
Found MVCE: <details<summaryOutput from Rust Playground</summary</details
Change:
//! This module contains the entry points for `slice::sort`. <del> #[cfg(not(feature = "optimize_for_size"))] </del> <ins> #[cfg(not(any(feature = "optimize_for_size", target_pointer_width = "16")))] </ins> use crate::cmp; use crate::intrinsics; use crate::mem::{self, MaybeUninit, SizedTypeProperties}; <del> #[cfg(not(feature = "optimize_for_size"))] </del> <ins> #[cfg(not(any(feature = "optimize_for_size", target_pointer_width = "16")))] </ins> use crate::slice::sort::shared::smallsort::{ SMALL_SORT_GENERAL_SCRATCH_LEN, StableSmallSortTypeImpl, insertion_sort_shift_left, }; pub(crate) mod merge; <del> #[cfg(not(feature = "optimize_for_size"))] </del> <ins> #[cfg(not(any(feature = "optimize_for_size", target_pointer_width = "16")))] </ins> pub(crate) mod drift; <del> #[cfg(not(feature = "optimize_for_size"))] </del> <ins> #[cfg(not(any(feature = "optimize_for_size", target_pointer_width = "16")))] </ins> pub(crate) mod quicksort; <del> #[cfg(feature = "optimize_for_size")] </del> <ins> #[cfg(any(feature = "optimize_for_size", target_pointer_width = "16"))] </ins> pub(crate) mod tiny; /// Stable sort called driftsort by Orson Peters and Lukas Bergdoll.

Discussion:
Run Or And you'll get this diagnostic (cargo miri setup makes it a warning, lol): I don't know what effect this has at runtime but it can't be good.
It's worse than one might think, because many AVR microarchitectures, including the atmega328 we nominally support, have only 2KiB of SRAM, which means that this line is literally impossible:
these targets should probably use some of the code in with perhaps a few more tweaks.
Good to know, 16-bit wasn't something we had in mind during development, in terms of less standard targets, we did test big endian with miri. I agree with the code in would be a better fit for such targets. What kind of tweaks did you have in mind?
There are other places in driftsort and ipnsort that use stack arrays, e.g: They are all size bound to <= 4KiB through various means, but still a poor fit for tiny chips.
I think that's necessary, I don't believe driftsort could ever meaningfully run on machines this small.
You already figured it out: dropping all the stack arrays to the absolute minimum. Note that you are not obligated to fix these targets, as usual.
I think it should be a single additional in the impl, so I don't mind doing it.
Yeah, we'd get CI failures way too often if we errored on warnings for tier 3 targets.
Related:
Who is using Tier 3 targets in CI?
Miri is, by running a test with . We should probably change that.
Thinking a bit more about it, is there any scenario where you'd compile Rust for 16-bit targets and don't want to use ? Independent of sort. I'd think that such targets are always binary-size limited and welcome any reduction of it.
Change:
check_ci_llvm!(llvm.allow_old_toolchain); check_ci_llvm!(llvm.polly); <del> // CI-built LLVM is shared config.llvm_link_shared = true; </del> <ins> // CI-built LLVM can be either dynamic or static. let ci_llvm = config.out.join(&*config.build.triple).join("ci-llvm"); let link_type = t!(std::fs::read_to_string(ci_llvm.join("link-type.txt"))); config.llvm_link_shared = link_type == "dynamic"; </ins> } if config.llvm_thin_lto {

Discussion:
From Switching to static linking would preclude any of the improvements from , so it would be better to use dynamic linking instead which would allow any contributor to get started without building LLVM from source or using system LLVM. That said, it sounds like dynamic linking will be very hard to do on other platforms. cc
Cc - do we know what the right way to bring the issues (bugs?) I found to LLVM developers? Are there active maintainers of LLVMs build system?
LLVM’s bugzilla is pretty much the only place for bug reports. If its something less defined than a precise bug report, talking it out on the mailing lists is the way to go.
In which way is static linking making downloaded LLVM impossible?
I don't think it's impossible to download/ship the statically linked LLVM, it's something I want to explore. That said, we want to move to dynamically linking LLVM because we ideally want to be applying ThinLTO to LLVM everywhere, not just on x86_64-unknown-linux-gnu, and since LTO happens at link-time, we want that to happen once, not on the multiple LLVM links occurring during CI.
Change:
f!(()); } <ins> // Regression test for issue #117014. async fn desugaring_span_ctxt() { for x in [] {}.await //~ ERROR `()` is not a future } </ins> fn main() {}

Discussion:
File: auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: Version information Command:
&lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details
additional ices with &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details
&lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details
slightly more reduced
Change:
/// # Examples /// /// ``` <del> /// #![feature(str_strip)] /// </del> /// assert_eq!("foo:bar".strip_prefix("foo:"), Some("bar")); /// assert_eq!("foo:bar".strip_prefix("bar"), None); /// assert_eq!("foofoo".strip_prefix("foo"), Some("foo")); /// ``` #[must_use = "this returns the remaining substring as a new slice,  without modifying the original"] <del> #[unstable(feature = "str_strip", reason = "newly added", issue = "67302")] </del> <ins> #[stable(feature = "str_strip", since = "1.45.0")] </ins> pub fn strip_prefix<'a, P: Pattern<'a>>(&'a self, prefix: P) -> Option<&'a str> { prefix.strip_prefix_of(self) }

Discussion:
Cc Will fill the content later. Creating this so that can be merged and tracked.
The code generated by is really complicated and inefficient. Godbolt link: Should we add / method directly to or trait?
Oof that does indeed look pretty bad.
I whipped up that fix here: Not sure if it's actually the ideal fix, but figured it would be a good point to launch the discussion from.
Ok, the code should be far more optimized now. What remains to be done? The main issue description has yet to be filled in.
On , I'm seeing that is much faster than , at least for newlines only. Is this only because I'm stripping off a very small amount of text, or is this function more optimized than (assuming that I didn't screw something up)? See "Standard strip suffix" versus "Standard trim end", with "unix" having the input of and "win" being : !
Ah, yeah, looks the optimizations I made to stripprefix/stripsuffix in are optimizations that don't exist for : I wonder if could be reimplemented as a loop over ... By the way, since I'm here, (or anyone else on the Rust team), what remains to be done for this issue?
If you want to change the implementation this is a good time. Else, the thing left is stabilisation with the libs team approving it (if needed) but i'd wait for some time to check if there are any other issues.
The implementation is now faster than the existing similar stable functions and , so I think we're in a good spot implementation wise. Would you be able to add a note about the progress and when we expect to start the stabilization discussion in the issue description? (Or whatever normally goes in there?)
you can submit a stabilisation PR by following the instructions here:
Change:
<ins> // compile-pass fn main() { let s = &["0x00"; 4][..]; //Slice of any value const MAGIC_TEST: &[&str] = &["4", "5", "6", "7"]; //Const slice to pattern match with match s { MAGIC_TEST => (), ["0x00", "0x00", "0x00", "0x00"] => (), ["4", "5", "6", "7"] => (), // this should warn _ => (), } match s { ["0x00", "0x00", "0x00", "0x00"] => (), MAGIC_TEST => (), ["4", "5", "6", "7"] => (), // this should warn _ => (), } match s { ["0x00", "0x00", "0x00", "0x00"] => (), ["4", "5", "6", "7"] => (), MAGIC_TEST => (), // this should warn _ => (), } } </ins>

Discussion:
Attempting to pattern match a slice with a constant value and THEN a slice literal causes an ICE. Simple test case: However simply changing the order to test the slice literal and then the const slice compiles fine: Error message: rustc version:
So... I do have a fix for byte slices, but that just exposed that we have the same ICE for other slices: This can be fixed, too, but I need to wait for to be merged before being able to do this in a reasonable way.
Change:
| Range(_, Some(e), _) | Ret(Some(e)) | Unary(_, e) <del> | Yield(Some(e)) => { </del> <ins> | Yield(Some(e)) | Yeet(Some(e)) | Become(e) => { </ins> expr = e; } Closure(closure) => { expr = &closure.body; } Gen(..) | Block(..) | ForLoop(..) | If(..) | Loop(..) | Match(..) | Struct(..) <del> | TryBlock(..) | While(..) => break Some(expr), _ => break None, </del> <ins> | TryBlock(..) | While(..) | ConstBlock(_) => break Some(expr), // FIXME: These can end in `}`, but changing these would break stable code. InlineAsm(_) | OffsetOf(_, _) | MacCall(_) | IncludedBytes(_) | FormatArgs(_) => { break None; } Break(_, None) | Range(_, None, _) | Ret(None) | Yield(None) | Array(_) | Call(_, _) | MethodCall(_) | Tup(_) | Lit(_) | Cast(_, _) | Type(_, _) | Await(_, _) | Field(_, _) | Index(_, _, _) | Underscore | Path(_, _) | Continue(_) | Repeat(_, _) | Paren(_) | Try(_) | Yeet(None) | Err => break None, </ins> } } }

Discussion:
I believe the intention in let-else is that this code should be considered syntactically invalid, but it compiles successfully today. If you replace with , it correctly fails to parse.
I believe here is the missing case for ExprKind::ConstBlock: This should be changed to an exhaustive match so that future new ExprKind variants are forced to touch this code. Some other unhandled cases that can end in : ExprKind::Become ExprKind::FormatArgs ExprKind::IncludedBytes ExprKind::InlineAsm ExprKind::MacCall ExprKind::OffsetOf ExprKind::Yeet