jiebi/CodeConvo huggingface dataset:
Change:
<ins> // revisions:cfail1 #![feature(const_generics)] //[cfail1]~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct S<T, const N: usize>([T; N]); fn f<T, const N: usize>(x: T) -> S<T, {N}> { panic!() } fn main() { f(0u8); //[cfail1]~^ ERROR type annotations needed } </ins>

Discussion:
A clean rust project on the latest nightly rustc with just this : produces the following error on cargo check/build: <details</detailsThe error is most likely caused by the inability to deduce the value of the const generic parameter ; when it is made clear (with, say, ) the ICE no longer occurs. Thus the expected behavior is probably still a failure to build (just not an ICE).
EDIT: Apparently const-generics in array repeat positions isn't a thing yet, at all. I apologize for the not-even-currently-valid example. I get the same ICE for this code: <details</detailswhich does give the explicit type, so it's not (entirely) a deduction thing. Entire build log: <details</details
Could you check the ICE still appears? I cannot reproduce it with latest nightly on playground.
Although this isn't throwing an error on the playground, I get an assertion failure when adding a test: Let's leave this open until we have a test for it.

() Errors:
/cc Related to but different from
This can be avoided by expressly allowing the type to be inferred:
: (as compared to )
After , this isn't fixed, but commenting out the call will cause it to error without ICEing (at the moment, it ICEs even without that line).
I configure struct by complicated const value and get this ICE. My code does something like this: Error: Note that type erase (as proposed does not help in my case. Until I found a way around this ICE.
Same error on:
I tried to port 's from to . Some of code is commented because of this bug and several other. I think this is good test for
Cannot reproduce the ICE with the above playground link.
It should be noted that while this no longer ICEs, this is because rustc no longer attempts to infer the type parameter causing it to fail to compile.

A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .
Change:
<ins> // revisions:cfail1 #![feature(const_generics)] //[cfail1]~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct S<T, const N: usize>([T; N]); fn f<T, const N: usize>(x: T) -> S<T, {N}> { panic!() } fn main() { f(0u8); //[cfail1]~^ ERROR type annotations needed } </ins>

Discussion:
I started to further investigate the bug blocking . The following is a minimised test case: Results in (with debug assertions enabled): Here with the backtrace: <details</detailsI would love to investigate further, but I am too confused and the panic message doesn't tell me anything useful either. But please tell me if I can do anything else to help you solve the bug. I'd love to have it fixed so that I can continue working on . CC
It's this debug assertion that's failing: Debug assertions are not turned on on released artifacts, but your local probably has them enabled.
Ohhh, that explains the weirdness. Should have thought of that myself. Thanks! But anyway, it's still a bug I assume. And I couldn't find another const generic bug with this error message.
The test case is sufficient with debug assertions (I can reproduce locally). Sorry, I've been meaning to look into this for ages. Having a minimal test case is helpful.
No problem, I'm happy for every minute you spend working on const generics ^_^
Sounds like inference variables are leaking out of somewhere. EDIT: wait, canonical variables reuse some of that infra - is the definition of symmetrical between , and ?
I had a quick look, and didn't spot any obvious asymmetries, but there surely must be for this error to occur…
This doesn't seem to have an analogue anymore in /: This mentions regions even though it shouldn't:
The first has an analogue in: I'll fix the second one.
I think the problem is here: We are creating a new canonical variable for the const value but are returning the type unchanged. So if the type has inference variables in it they will leak through.
So was replaced by ? The same should be done for consts.
Opened for that.
Change:
use crate::Determinacy::{self, *}; use crate::Namespace::*; use crate::{module_to_string, names_to_string, ImportSuggestion}; <del> use crate::{AmbiguityKind, BindingKey, ModuleKind, ResolutionError, Resolver, Segment}; </del> <ins> use crate::{ AmbiguityError, AmbiguityErrorMisc, AmbiguityKind, BindingKey, ModuleKind, ResolutionError, Resolver, Segment, }; </ins> use crate::{Finalize, Module, ModuleOrUniformRoot, ParentScope, PerNS, ScopeSet}; use crate::{NameBinding, NameBindingKind, PathResult};

Discussion:
thread 'rustc' panicked at ': inconsistent resolution for an import', <details<summaryBacktrace</summary</detailsRegression in nightly-2018-12-30 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Same error message as , but this one is self-contained and might be a separate bug.
claim
how about make this to an error with diagonostic? Seems we don't have a chance to insert , because the is before the later . If we change code to this: It will be:
Could we register an exactly in the place we ICE?
Yes, this is also a solution, and then we can report error in the same function .
Change:
<del> error[E0309]: the associated type `<Left as HasChildrenOf>::T` may not live long enough </del> <ins> error: `impl` associated type signature for `TRef` doesn't match `trait` associated type signature </ins> --> $DIR/issue-86787.rs:23:5 | <ins> LL |       type TRef<'a>; |       -------------- expected ... </ins> LL | /     type TRef<'a> LL | | LL | | LL | |     where LL | |     <Left as HasChildrenOf>::T: 'a, LL | |     <Right as HasChildrenOf>::T: 'a <del> | |                                    - help: consider adding a where clause: `, <Left as HasChildrenOf>::T: 'a` </del> LL | |     = Either<&'a Left::T, &'a Right::T>; <del> | |________________________________________^ ...so that the definition in impl matches the definition from the trait </del> <ins> | |________________________________________^ found </ins> <del> error[E0309]: the associated type `<Right as HasChildrenOf>::T` may not live long enough </del> <ins> error: `impl` associated type signature for `TRef` doesn't match `trait` associated type signature </ins> --> $DIR/issue-86787.rs:23:5 | <ins> LL |       type TRef<'a>; |       -------------- expected ... </ins> LL | /     type TRef<'a> LL | | LL | | LL | |     where LL | |     <Left as HasChildrenOf>::T: 'a, LL | |     <Right as HasChildrenOf>::T: 'a <del> | |                                    - help: consider adding a where clause: `, <Right as HasChildrenOf>::T: 'a` </del> LL | |     = Either<&'a Left::T, &'a Right::T>; <del> | |________________________________________^ ...so that the definition in impl matches the definition from the trait </del> <ins> | |________________________________________^ found </ins> error: aborting due to 2 previous errors <del> For more information about this error, try `rustc --explain E0309`. </del>

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: A slightly better error message Instead, this happened: A slightly confusing error message <!-- 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
Change:
#![default_lib_allocator] <ins> // Always use alloc_system during stage0 since we don't know if the alloc_* // crate the stage0 compiler will pick by default is enabled (e.g. // if the user has disabled jemalloc in `./configure`). // `force_alloc_system` is *only* intended as a workaround for local rebuilds // with a rustc without jemalloc. // The not(stage0+msvc) gates will only last until the next stage0 bump #![cfg_attr(all( not(all(stage0, target_env = "msvc")), any(stage0, feature = "force_alloc_system")), feature(global_allocator))] #[cfg(all( not(all(stage0, target_env = "msvc")), any(stage0, feature = "force_alloc_system")))] #[global_allocator] static ALLOC: alloc_system::System = alloc_system::System; </ins> // Explicitly import the prelude. The compiler uses this same unstable attribute // to import the prelude implicitly when building crates that depend on std. #[prelude_import]

Discussion:
Since bumped the bootstrap compiler, stage0 libstd fails to build when jemalloc is disabled: I believe it needs to restore the logic removed here: I tried to add this to : Then stage0 passed, but stage1 std failed like:
cc
We should probably add a builder for this...
or just get on with evicting jemalloc...
is not the right way to fix this - I that so I could build rust with a local rust that does not have jemalloc i.e. unless the following two conditions are true: you're using a local rust (as opposed to the automatic stage0 download) and your local rust does not have jemalloc (you compiled the whole thing yourself with ) it's irrelevant. Edit: to be clear, by "not the right way to fix this" I mean "it worked fine before I that flag, so its removal is probably not the root cause". That's doesn't exclude the possibility that we could perform some incantations with this flag and fix the issue. Edit2: sorry, I thought you were exclusively referring to rather than all the logic. I read and thought this issue was about the same thing.
Generally, the two conditions you list are actually true for me. I build Fedora's rustc without jemalloc, and I use that as the local stage0 to build the next release. And i think the force flag does come into play too, because if we need to rebuild the current release then the local rust gets treated as a stage1. But right now it's more direct. I am using the downloaded stage0, which wants to default to jemalloc. Since I'm disabling that for my build, stage0 can't find it.
Interesting, I kinda figured I was the only one! Rereading , I see I'm wrong about my two conditions above - it actually applies when trying to build something without jemalloc, from something that defaults to it. Anyway, it should all be fixed soonish...
Change:
[dependencies] core = { path = "../core" } <del> libc = { version = "0.2.51", features = ['rustc-dep-of-std'], default-features = false } </del> <ins> libc = { version = "0.2.79", features = ['rustc-dep-of-std'], default-features = false } </ins> compiler_builtins = "0.1.0" cfg-if = "0.1.8"

Discussion:
Reasons for: . According to , musl caused a program to run 9x slower. Musl is also known to be slower in certain configurations in C. This varies a lot with the use case and some might even see a performance increase with musl. docker containers using . It is possible to link glibc statically as demonstrated . From what I can tell, on the user facing side, this would be enable using as described in .
The reddit thread mentions libm. And another source of speedups might be the malloc implementation (glibc 2.26 introduced thread-local caches). One can already use custom global allocators, maybe it would make sense to link a custom libm too?
First blocker is the license. Glibc is licensed under LGPL, it has dynamic linking exception so one can freely link dynamically to it. Static linking doesn't fall under this exception. I'm not a lawyer but I think Rust would have to be licensed as (L)GPL to fit it. Another thing is glibc doesn't really support static linking, sure it works well for small software but bites you when you need more of it's features.
(Obviously not a lawyer but), I'm pretty sure that as long as the code it is linked against is (L)GPLed, it should work.
Also as long as the program it is linked against is licensed under a GPL compatible license, it is allowed. The MIT license, is compatible. All this information can be confirmed by looking at the above link. You can even link proprietary code against LGPL if you provide the object files.
because of we need special linking arguments because of the symbols. see also for and glibc uses for the nss modules.
The former should be doable. The latter is a tradeoff that people will need to understand if they statically link glibc, and it's something they already have to deal with if they use .
Implementation instructions: Add an entry for glibc-based targets you want to support to (Same as for musl, but -, because is undesirable ().) Perhaps libm or libpthread will need to be linked in the same way. Set to in target specifications for glibc-based targets you want to support (in ). Test that it actually works, this will require some building of libstd with cargo overridden libc dependency.

I'd be happy to submit the necessary changes, if you can outline what needs doing. () See the comment above.
Thanks!
I have this successfully working; just waiting on a release of the libc crate containing .
Change:
use crate::tool::{self, SourceType, Tool}; use crate::toolstate::ToolState; use crate::util::{self, add_link_lib_path, dylib_path, dylib_path_var, output, t}; <del> use crate::Crate as CargoCrate; </del> use crate::{envify, CLang, DocTests, GitRepo, Mode}; const ADB_TEST_DIR: &str = "/data/tmp/work";

Discussion:
I tried this code: I expected to see this happen: bootstrap documents the whole compiler, like it does for . Instead, this happened: The problem is that is too naive and expects the name of each crate to match its file path on disk: It needs to map from the path to the name somehow. There's already a way to go from the name to the path: but I don't think there's a way to do the reverse. HEAD is . label +A-bootstrap
label: +A-bootstrap
label: +E-mentor +A-rustbuild
Change:
<ins> // Copyright 2013 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. extern mod extra; fn o<T: Owned>(_: &T) {} fn c<T: Const>(_: &T) {} fn main() { let x = extra::rc::rc_mut_from_owned(0); o(&x); //~ ERROR instantiating a type parameter with an incompatible type `extra::rc::RcMut<int>`, which does not fulfill `Owned` c(&x); //~ ERROR instantiating a type parameter with an incompatible type `extra::rc::RcMut<int>`, which does not fulfill `Const` } </ins>

Discussion:
It seems the decoding of [mutable] and [nonowned] is broken: specifically it seems they are ignored when applied on a struct in an external module, when another attribute follows. In particular, it seems that when more than one attribute is present, only the last_ attribute survives encode+decode, and the others are somehow lost.
Nominating for the production ready milestone.
Should be fixable with the following patch:
Fixed by .
Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(rustc_attrs)] macro_rules! foo { ($x:tt) => (type Alias = $x<i32>;) } foo!(Box); #[rustc_error] fn main() {} //~ ERROR compilation successful </ins>

Discussion:
See discussion on .
The ability to convert token-trees AST is also needed to
Do we need that ability here? It's only about interpolated matches.
Fixed in .
Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(rustc_attrs)] macro_rules! foo { ($x:tt) => (type Alias = $x<i32>;) } foo!(Box); #[rustc_error] fn main() {} //~ ERROR compilation successful </ins>

Discussion:
I haven't finished investigating this, so I'm making an issue just so I don't forget it:
Actually, I'm really not sure this should work. I'm nominating this for well-defined.
Actually... this definitely shouldn't work in our current system. The basic issue is that a lonely sigil is not a complete "thing". The "tt" macro option is only intended for macros that expand into macro invocations. There are a number of ways around this; at the most basic level, you can insist that the user provide the sigil and the thing it's attached to. This works, but it may be unsatisfying if you want the sigil to be attached to names that are introduced by the macro. In this case, you have a couple of choices. use an unhygienic macro (and tell everyone what name you want to attach to the sigil, ugh) explicitly have three different versions of the macro, one for each sigil (bleah) clean up the second option by nesting one macro definition inside another one make sigils expand into macro invocations. Anyhow, I would say that as of right now, at least, this is not a bug. I'm going to leave this as nominated mostly because this came up in Vancouver as something that Graydon and I both expected to work.
Visiting for triage: still doesn't work, nothing more to add.
accepted for well-defined milestone
You can work around this by using a dummy macro so that you can pass the directly to it, e.g. for the example in the issue:
reading this workaround makes me feel like our macro system is really broken :(.
/cc
The modernized example gives me which looks like .
notes that another hacky work-around is a nested macro invocation, which avoids needing to define/export dummy macros (although one will want to be careful about giving that internal macro a fairly unique name to avoid trampling on any other macros in scope, unfortunately :disappointed: ).
Updated example: error:
Triage: This is an ancient P-low bug but per it actually comes up in the wild a lot - macro writers have to know how to do this workaround. Can this be escalated? Is there a solution somebody could mentor?
Discussed at lang meeting, we believe this should remain p-low since we don't know a very easy fix.

It should be fixed by converting macro_rules to expand to pure tokens then parsing, rather than mixing the two steps (which we hop would be back-compat). cc
Fixed in .
Change:
// constructing the HIR for `impl bounds...` and then lowering that. let impl_trait_node_id = self.next_node_id(); <ins> // Shift `impl Trait` lifetime captures from the associated type bound's // node id to the opaque node id, so that the opaque can actually use // these lifetime bounds. self.resolver .remap_extra_lifetime_params(constraint.id, impl_trait_node_id); </ins> self.with_dyn_type_scope(false, |this| { let node_id = this.next_node_id();

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
Regression in nightly-2023-08-29 Regression in cc
Change:
} } } <ins> fn check_incompatible_features(sess: &Session) { let features = sess.features_untracked(); let declared_features = features .declared_lang_features .iter() .copied() .map(|(name, span, _)| (name, span)) .chain(features.declared_lib_features.iter().copied()); for (f1, f2) in rustc_feature::INCOMPATIBLE_FEATURES .iter() .filter(|&&(f1, f2)| features.enabled(f1) && features.enabled(f2)) { if let Some((f1_name, f1_span)) = declared_features.clone().find(|(name, _)| name == f1) { if let Some((f2_name, f2_span)) = declared_features.clone().find(|(name, _)| name == f2) { let spans = vec![f1_span, f2_span]; sess.struct_span_err( spans.clone(), &format!( "features `{}` and `{}` are incompatible, using them at the same time  is not allowed", f1_name, f2_name ), ) .help("remove one of these features") .emit(); } } } } </ins>

Discussion:
I expect the code below code to compile, but it fails. should allow more than just the types whitelisted in , but it seems rustc only looks at the flag in this case. The error message is:
You are right But why would you want to use the two of them?
I imagine this to happen whenever at first you only decide to use , but then later also switch to . You might just follow rustc, which tells you to add to your project, so you do, but then you get the behaviour as described in this issue. This could also perhaps get triggered in a more subtle way where you write a library that uses to enable or disable features.
what do you think ?
It probably makes sense to instead check if we are not using here, but there are a quite a few places were we check for , we maybe want to instead emit an error/warning when using both and in the same crate.
Created a way to produce an error in case of incompatible features, like this one
I have one question, how does using 'incompatible feature' cause maybe undefined behavior? Are there other incompatible features? In this case, wouldn't it be better to produce an error message like "feature(constgenerics) is a superset of feature(minconst_generics)"?
Note that: results in a : So currently is not a superset of .
You are missing a in your feature. I still think constgenerics are a superset of minconstgenerics, but rustc just suggest using the smaller one in this case becouse that's the subset aiming to be stabilized for now
Ah of course, my bad I was confused looking at some ui tests for const generics, and missed that those now have support differentiating between expected behavior under and , and thought a particular error was always being thrown, instead of only under .