jiebi/CodeConvo huggingface dataset:
Change:
<ins> // ignore-tidy-linelength #![feature(arbitrary_self_types)] #![feature(type_alias_impl_trait)] use std::ops::Deref; trait Foo { type Bar: Foo; fn foo(self: impl Deref<Target = Self>) -> Self::Bar; } impl<C> Foo for C { type Bar = impl Foo; fn foo(self: impl Deref<Target = Self>) -> Self::Bar { //~^ Error type parameter `impl Deref<Target = Self>` is part of concrete type but not used in parameter list for the `impl Trait` type alias self } } fn main() {} </ins>

Discussion:
here is the example: this example will compile well if you remove
Backtrace: `
Hmm I reproduced same ICE with next snippet without :
Smaller repro: Edit: AFAICT the problem is the existential assoc type is being made dependent on the type parameter of the trait method ('s in this repro, 's in the OP). So it would be a compile error if it weren't for the ICE.
compiles without ICE.
sorry it needs to be feature or used 2018 edition. Here is complete one which fails to compile regardless feature:
Right, 2015 doesn't hit the error until you actually try to use the type. Regardless, as I said in my previous comment, this code should be a compile error anyway regardless of edition, since it's trying to declare an associated type that depends on the type parameters of the trait method rather than the trait.
hey have you had a chance to look into this yet? Do you think you will be looking at it in the near term, or should we unassign you?
Removed my assignment. Unfortunately I'm running behind on the not-time-critical issues I assigned to myself.
Discussed in T-compiler meeting. This is a blocker for the existential type feature. But there is no schedule yet set for stabilizing that feature. Thus, downgrading fixing this to P-medium.
This no longer produces an ICE on the latest nightly.
Yes, it was fixed by
Change:
<ins> #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash trait A {} struct B; impl A for B {} fn test<const T: &'static dyn A>() { //~^ ERROR must be annotated with `#[derive(PartialEq, Eq)]` to be used unimplemented!() } fn main() { test::<{ &B }>(); } </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. --: Note that the error is also present on stable (1.42.0). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
cc I don't think should be structurally matchable.
Note that this isn't matching on , it's matching on . There's a double pointer indirection because AtomicPtr requires T to be Sized.
References match by their pointee value, unlike raw pointers. You should use if you want to actually compare the pointers.
Change:
<ins> #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash trait A {} struct B; impl A for B {} fn test<const T: &'static dyn A>() { //~^ ERROR must be annotated with `#[derive(PartialEq, Eq)]` to be used unimplemented!() } fn main() { test::<{ &B }>(); } </ins>

Discussion:
Pretty straightforward. The idea is to plug logic into a template. This seems like something that should/could work. Playground link: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
"smaller": Error:
claim
release-assignment is not structural match so this should not compile. We probably shouldn't ICE here though :laughing: cc
It shouldn't be, but it currently is. To fix it you need to change , .
Change:
"libc", "once_cell", "opener", <del> "pretty_assertions", </del> <ins> "pretty_assertions 0.7.2", </ins> "serde", "serde_json", "tar",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.
Change:
} // Prohibit explicit lifetime arguments if late-bound lifetime parameters are present. <ins> let mut reported_late_bound_region_err = None; </ins> if !infer_lifetimes { if let Some(span_late) = def.has_late_bound_regions { let msg = "cannot specify lifetime arguments explicitly 

Discussion:
Compiler crashes with Also, I wonder what is the right way (or is there any way) to write a with expected behavior. Thanks.
Reduced:
Regression first occurred in 1.30 according to godbolt.
One can leave out the trait in your MCVE, still crashes. Bug was introduced somewhere between ... Sadly that's a very big range, but there are no nightlys available in between and also no bors artifacts because they are older than 167
triage: P-high
Smaller example from :
I was trying to remove as many type parameters as possible, and ended up with this: Removing after still cuases an ICE. Adding a after stops causing the ICE. Removing the also stops causing the ICE. Not sure if it's any more or less helpful, but just putting this here.
claim Looks like that didn't work, either way, I'm taking a look into this issue.
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please let know if you're having trouble with this bot.
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please let know if you're having trouble with this bot.
Change:
<ins> pub trait TestTrait { type MyType; fn func() -> Option<Self> where Self: Sized; } impl<T> dyn TestTrait<MyType = T> where Self: Sized, // pesky sized predicate { fn other_func() -> dyn TestTrait<MyType = T> { match Self::func() { None => None, //~^ ERROR mismatched types } } } 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
bisected to cc
This can be made to ICE on stable as well:
duplicate of

<!-- 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
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `
Change:
// NOTE: generics must be cleaned before args let generics = clean_generics(generics, cx); let args = clean_args_from_types_and_body_id(cx, sig.decl.inputs, body_id); <del> let decl = clean_fn_decl_with_args(cx, sig.decl, args); </del> <ins> let mut decl = clean_fn_decl_with_args(cx, sig.decl, args); if sig.header.is_async() { decl.output = decl.sugared_async_return_type(); } </ins> (generics, decl) }); Box::new(Function { decl, generics })

Discussion:
produces: But I think it should be. For the HTML backend, rustdoc "resugars" the return type to get the from I think we should move this to a pass. cc does this change seem like a good idea. modify labels: +T-rustdoc +A-rustdoc-json
I'm not sure if it's worth adding a pass for this... Maybe handling this into a specific function shared between both formats could be a better idea?
We could call in . Or we could move this to when constructing . I'm not sure which makes most sense.
In directly seems like a good approach.
Change:
pub candidate_span: Option<Span>, } <del> pub struct StringReader<'a> { </del> <ins> crate struct StringReader<'a> { </ins> sess: &'a ParseSess, /// Initial position, read-only. start_pos: BytePos,

Discussion:
In , we would like to tweak the structure of the tokens rustc uses. One of the components which heavily depends on the current structure is ( and module use ). I think, for this issue and in general, it makes sense to switch over to , which produces lower-level guaranteed lossless tokens, which look like a better fit for the task of syntax highlighting. I plan to do this refactor myself, but I want to check with if this is a good idea. EDIT: cc
sgtm
I'm fine with it as well. :)
BTW, is there some chat room for rustdoc team on zulip on discord? I'd like to ask some questions :)
There is one on discord (simply called "rustdoc").
It's linked at (which is I agree pretty hard to find). Also the text there is wrong and mentions , we should probably fix that.
Change:
<ins> error[E0261]: use of undeclared lifetime name `'d` --> $DIR/issue-109299.rs:6:12 | LL | impl Lexer<'d> { |     -      ^^ undeclared lifetime |     | |     help: consider introducing lifetime `'d` here: `<'d>` error: aborting due to previous error For more information about this error, try `rustc --explain E0261`. </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-02-17 to nightly-2023-03-18 regressed nightly: nightly-2023-02-21 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: </details
cc is this fixed by your branch?
No, it's not. The stacktrace does indeed contain but that's not the root cause of the problem. It just calls which ices (changing it to doesn't help either). The actual (?) bug is probably inside of the code I assume.
Ah, wait. If it's a bug to pass s to the type relating functions then it is the fault of and it should probably return early if a type . Edit: But it that case?
Hm, actually I think we should just fix the relate code instead.
Sure. I also feel like I've seen this ICE message pop up several times already on this issue tracker. I might be mistaken tho.
More minimal:
Reassigning to myself since the approach involving region erasure during selection we talked about fixes this issue (obviously) and since I'd like to integrate this into my PR to be able to write UI tests that exercise the bound region code used during IAT confirmation (otherwise we would never go past selection in those cases). claim label F-inherentassociatedtypes
Change:
use rustc_middle::ty::query::Providers; use rustc_middle::ty::{ParamEnv, TyCtxt}; use rustc_session::lint::builtin::{ <del> CONFLICTING_REPR_HINTS, INVALID_DOC_ATTRIBUTES, UNUSED_ATTRIBUTES, </del> <ins> CONFLICTING_REPR_HINTS, INVALID_DOC_ATTRIBUTES, INVALID_MACRO_EXPORT_ARGUMENTS, UNUSED_ATTRIBUTES, </ins> }; use rustc_session::parse::feature_err; use rustc_span::symbol::{kw, sym, Symbol};

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:
<ins> // normalize-stderr-test: "long-type-d+" -> "long-type-hash" // Fixes #110131 // // The issue is that we were constructing an `ImplDerived` cause code for the // `&'a T: IntoIterator<Item = &'a u8>` obligation for `Helper::new`, which is // incorrect because derived obligations are only expected to come from *traits*. struct SeqBuffer<'a, T> where &'a T: IntoIterator<Item = &'a u8>, { iter: <&'a T as IntoIterator>::IntoIter, } struct Helper<'a, T> where &'a T: IntoIterator<Item = &'a u8>, { buf: SeqBuffer<'a, T>, } impl<'a, T> Helper<'a, T> where &'a T: IntoIterator<Item = &'a u8>, { fn new(sq: &'a T) -> Self { loop {} } } struct BitReaderWrapper<T>(T); impl<'a, T> IntoIterator for &'a BitReaderWrapper<T> where &'a T: IntoIterator<Item = &'a u8>, { type Item = u32; type IntoIter = Helper<'a, T>; //~^ ERROR `Helper<'a, T>` is not an iterator fn into_iter(self) -> Self::IntoIter { Helper::new(&self.0) //~^ ERROR overflow evaluating the requirement `&_: IntoIterator` } } 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized via  and some manual item deletion: I can take a quick look into this one I guess. claim
Change:
// doing more work yet if !pending_obligation.stalled_on.is_empty() { if pending_obligation.stalled_on.iter().all(|&ty| { <del> let resolved_ty = selcx.infcx().resolve_type_vars_if_possible(&ty); </del> <ins> let resolved_ty = selcx.infcx().shallow_resolve(&ty); </ins> resolved_ty == ty // nothing changed here }) { debug!("process_predicate: pending obligation {:?} still stalled on {:?}",

Discussion:
This takes ~2 seconds to type check (according to ): Doubling (respectively, halving) the number of invocations multiplies (resp. divides) the time by 4. It applies to arithmetic in s/s too which is, I imagine, where this will occur most often in practice (it's how I found it). Observations: for , , and , annotating either side (e.g. ) or both sides makes it take only 0.03s and behave linearly (AFAICT) for and : annotating the LHS () reduces the time to ~1.5s, annotating the RHS () reduces it to ~1.1s but both are still quadratic, annotating both takes it to 0.04s and linear it seems to only be dependent on the number of operations in a single function/item, separating the 4 big chunks above across 4 functions reduces the time to ~0.5s. there's no significant difference between using the macro or writing the operations inline (I only use to allow easier experimentation) cc
This must be what's making my old macro-abusing inflate implementation take almost 300 seconds in typeck. It almost sounds like type-checking a function is quadratic over the number of inference variables. Having ran callgrind on the sample and also half of it, I'm seeing the following trace: An unrefined conclusion is that either shouldn't call or should be constant-time.
Is this the same issue as ?
I'm not too familiar with fulfill and infer, but couldn't track the latest snapshot it processed and look at the new information there?
We have exactly for this reason. It doesn't work for some reason tho.
This is the same issue as This is a different issue from (I think I will fix that one separately).
Change:
objdir=$root_dir/obj dist=$objdir/build/dist <ins> if [ -d "$root_dir/.git" ]; then IS_GIT_SOURCE=1 fi </ins> source "$ci_dir/shared.sh" CACHE_DOMAIN="${CACHE_DOMAIN:-ci-caches.rust-lang.org}"

Discussion:
I have this totally normal config: Then I want to run Then inside the container, Bootstrap is compiled, but then emits this: My repository history is not too shallow. The only way to use the CI scripts seems to be to set . The reason download-ci-llvm doesn't work seems to be the ownership of the mount: So maybe this is an easy fix? Can we just run that somewhere? It seems to work, I'm just not sure where it would be run.
That script should set the uid of the processes inside the container to match what you use outside of the container and thus who owns the source repo: If you use podman, are you maybe using a version of podman which doesn't contain the literal string in ? And can you run outside and inside the container?
I am not using Podman
Outside the container: After
I assume this is related with your docker privileges (the user group assigned on docker). Can't reproduce this on my side.
That seems reasonable? What should that be instead?
should be able to handle this
That's very nice of you, but if I have a scuffed Docker setup on my dev machine I'd like to know in what way it's scuffed if you don't mind :sweat_smile:
By default, docker runs under root mode, and I believe this is the main issue here. On the other hand, podman runs in rootless mode by default: I was able to reproduce the problem by running podman under root privileges. I believe the problem here is more related to the nature of docker rather than an issue with your docker setup.
The snippet I mentioned in should ensure that the programs inside the container run as the same user as the one with which was invoked.
And when the user is root (e.g., running the script with root user), you get .
Change:
// another. This is an error. However, if we already know that // the arguments don't match up with the parameters, we won't issue // an additional error, as the user already knows what's wrong. <del> if arg_count.correct.is_ok() && arg_count.explicit_late_bound == ExplicitLateBound::No { </del> <ins> if arg_count.correct.is_ok() { </ins> // We're going to iterate over the parameters to sort them out, and // show that order to the user as a possible order for the parameters let mut param_types_present = defs

Discussion:
This is ICE since 1.50.0, error -ICE. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bisected: searched nightlies: from nightly-2020-01-01 to nightly-2021-03-17 regressed nightly: nightly-2020-11-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Thanks for bisecting, I believe is the cause.
Assigning and removing as in the prioritization working group. label: +P-medium -I-prioritize
claim
Change:
<ins> error[E0423]: expected value, found type parameter `O` --> $DIR/issue-69654.rs:5:25 | LL | impl<O> Bar<O> for [u8; O] {} |                         ^ help: a tuple variant with a similar name exists: `Ok` | ::: $SRC_DIR/libcore/result.rs:LL:COL | LL |     Ok(#[stable(feature = "rust1", since = "1.0.0")] T), |     --------------------------------------------------- similarly named tuple variant `Ok` defined here error: aborting due to previous error For more information about this error, try `rustc --explain E0423`. </ins>

Discussion:
ran cargo-bisect-rustc on this. It reports: searched nightlies: from nightly-2019-11-18 to nightly-2019-12-02 regressed nightly: nightly-2019-12-02 searched commits: from to regressed commit:
i.e. this was injected by (rollup) PR its not immediately obvious to me which associated PR from that rollup is to blame. Maybe ?
The ICE no longer occurs with latest nightly, I guess fixed it. Marked as E-needs-test.
Change:
/// instance, it will behave *as if* an instance of the type `T` were /// present for the purpose of various automatic analyses. /// <del> /// For example, embedding a `PhantomData<T>` will inform the compiler </del> <ins> /// # Examples /// /// When handling external resources over a foreign function interface, `PhantomData<T>` can /// prevent mismatches by enforcing types in the method implementations, although the struct /// doesn't actually contain values of the resource type. /// /// ``` /// # trait ResType { fn foo(&self); }; /// # struct ParamType; /// # mod foreign_lib { /// # pub fn new(_: usize) -> *mut () { 42 as *mut () } /// # pub fn do_stuff(_: *mut (), _: usize) {} /// # } /// # fn convert_params(_: ParamType) -> usize { 42 } /// use std::marker::PhantomData; /// use std::mem; /// /// struct ExternalResource<R> { ///    resource_handle: *mut (), ///    resource_type: PhantomData<R>, /// } /// /// impl<R: ResType> ExternalResource<R> { ///     fn new() -> ExternalResource<R> { ///         let size_of_res = mem::size_of::<R>(); ///         ExternalResource { ///             resource_handle: foreign_lib::new(size_of_res), ///             resource_type: PhantomData, ///         } ///     } /// ///     fn do_stuff(&self, param: ParamType) { ///         let foreign_params = convert_params(param); ///         foreign_lib::do_stuff(self.resource_handle, foreign_params); ///     } /// } /// ``` /// /// Another example: embedding a `PhantomData<T>` will inform the compiler </ins> /// that one or more instances of the type `T` could be dropped when /// instances of the type itself is dropped, though that may not be /// apparent from the other structure of the type itself. This is

Discussion:
This isn't a big deal but the documentation is slightly out of date for the variant of . Reference: The comment should read: I will fix this if I have time, otherwise it is a small tweak that someone looking to contribute could make. cc
I've taken the liberty of fixing that comment :)
can you open up a pull request please?
Yep, done! Is this the right way to do it?