jiebi/CodeConvo huggingface dataset:
Change:
let ocx = ObligationCtxt::new(infcx); let norm_cause = ObligationCause::misc(return_span, impl_m_hir_id); <del> let impl_return_ty = ocx.normalize( </del> <ins> let impl_sig = ocx.normalize( </ins> norm_cause.clone(), param_env, <del> infcx .replace_bound_vars_with_fresh_vars( return_span, infer::HigherRankedType, tcx.fn_sig(impl_m.def_id), ) .output(), </del> <ins> infcx.replace_bound_vars_with_fresh_vars( return_span, infer::HigherRankedType, tcx.fn_sig(impl_m.def_id), ), </ins> ); <ins> let impl_return_ty = impl_sig.output(); </ins> let mut collector = ImplTraitInTraitCollector::new(&ocx, return_span, param_env, impl_m_hir_id); <del> let unnormalized_trait_return_ty = tcx </del> <ins> let unnormalized_trait_sig = tcx </ins> .liberate_late_bound_regions( impl_m.def_id, tcx.bound_fn_sig(trait_m.def_id).subst(tcx, trait_to_placeholder_substs), ) <del> .output() </del> .fold_with(&mut collector); <del> let trait_return_ty = ocx.normalize(norm_cause.clone(), param_env, unnormalized_trait_return_ty); </del> <ins> let trait_sig = ocx.normalize(norm_cause.clone(), param_env, unnormalized_trait_sig); let trait_return_ty = trait_sig.output(); </ins> <del> let wf_tys = FxHashSet::from_iter([unnormalized_trait_return_ty, trait_return_ty]); </del> <ins> let wf_tys = FxHashSet::from_iter( unnormalized_trait_sig.inputs_and_output.iter().chain(trait_sig.inputs_and_output.iter()), ); </ins> match infcx.at(&cause, param_env).eq(trait_return_ty, impl_return_ty) { Ok(infer::InferOk { value: (), obligations }) => {

Discussion:
While working on an experimental runtime and using a couple of experimental features I found that the compiler while in resolving the async call on a trait crash badly. This is a minimal reproducible example and this is the stacktrace generated N.B: I guess this happens with any runtime? BTW also if happens only with rio the compiler should not crash, but I do not think this is related to a specific runtime, but I guess instead, the runtime triggers the resolution of the futures <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-async-await +T-compiler
In the meanwhile, I will try to swim inside the codebase to catch the problem! claim
this is fixed by .
Minimized so it doesn't depend on rio:
Cool great work :)

gives happens with either rustc 1.66.0-dev () 66.0-nightly (2022-09-25 )
label +F-asyncfnin_traits
label +T-compiler +C-bug +I-ICE +requires-nightly Please use the ICE issue template for subsequent ICE issues. Thanks.
This is fixed by

I tried this code: I expected this to compile without error, since it is implementing the trait correctly. Instead, the following error was shown: It suggests replacing the code with the code I already have, which doesn't make much sense, as well as complaining that two things which appear identical are not. . : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +T-compiler +requires-nightly +F-returnpositionimpltraitin_trait +D-invalid-suggestion
claim
Change:
pub fn main() { assert!(Some(box() ()).is_some()); <ins> let xs: Box<[()]> = box []; assert!(Some(xs).is_some()); </ins> struct Foo; assert!(Some(box Foo).is_some()); <ins> let ys: Box<[Foo]> = box []; assert!(Some(ys).is_some()); </ins> }

Discussion:
I this to get DST landed. For types I use a fat pointer. If the vector is empy I use null for the pointer, so when this deallocates via drop glue jemalloc segfaults. It should be fairly easy to do a zero sized allocation or something and use that value and then we can remove the null check. That also allows us to use the Option to non-null pointer optimisation. For now I just want to get this branch landed though. cc
FWIW, as the sentinel value for this sort of situation (to ensure that still works, since that uses the "non-null" pointer as the discriminant).
It seems that landed the non-null pointer optimization for slices so this shouldn't be required anymore. Can it be closed?
This ended up landing as part of the initial implementation, but I don't think it is actually accomplishing anything.
Change:
<del> Subproject commit d2df509867fbbbd35730c90aef54a8e73b046cd6 </del> <ins> Subproject commit b5ddc94bf02c641e5acbb08ae742014f40347f10 </ins>

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! cc the PR reviewer, and -- nominating for prioritization.
from
Looks like a bunch of tests are affected the same way:
Cc this is likely caused by your change, somehow.
Likely caused by a missing in function pointer validation. Should be fixed by
I merged branches with my branches in both the rust and miri repos and all the tests passed :D
triage: P-medium, removing nomination, already assigned to
Miri upstream CI passes now, but only because I disabled a bunch of tests. I felt that was the better alternative, compared to not being able to land any update in Miri until a fix happens on the rustc side. But this means we shouldn't update the in-tree Miri tool yet.
PR fixing things for Miri: Blocked on
Miri master got broken again, . Do you want to try to fix that?
I believe broke miri. Hopefully I get time to fix it?
Should be an easy fix by making Miri not use that trait explicitly. It's yours!
Hooray, landed! Looks like this is blocked on a serde regression now, judging from https://travis- EDIT: blocked on , actually.
Change:
} // Function types <del> ty::FnDef(def_id, substs) | ty::Closure(def_id, substs) | ty::Generator(def_id, substs, ..) => { </del> <ins> ty::FnDef(def_id, substs) | ty::Closure(def_id, substs) => { </ins> // u<length><name>[I<element-type1..element-typeN>E], where <element-type> is <subst>, // as vendor extended type. let mut s = String::new();

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 --
claim
Change:
hash_spans: bool, hash_bodies: bool) -> Self { <del> let check_overflow = tcx.sess.opts.debugging_opts.force_overflow_checks .unwrap_or(tcx.sess.opts.debug_assertions); </del> <ins> let check_overflow = tcx.sess.overflow_checks(); </ins> StrictVersionHashVisitor { st: st,

Discussion:
Tracking issue for
FWIW this should be a relatively easy bug to knock out! The option is and we'd just want to add a new flag to the (we'll delete the flag once everyone's migrated). There's a few uses throughout the codebase which I believe will need an update:    After that we'd just need to add a test which validates this behavior, likely a addition with a annotation at the top. Likewise the Cargo support should be relatively easy:
I'd like to tackle this!
OK, so this is pretty straightforward. Couple questions after actually implementing this: The RFC says the option is , but comments on the RFC suggest that people expect this to be , so one could have (I guess) . Which variant should be supported? It seems better to make the value in the single source of truth to be used throughout the compiler by setting it based on the value of or ; this makes the uses easier to read and also makes any future removal of straightforward. How should interact with ? Should we just consider any explicit setting of to "win" and only consult if the option was not explicitly provided? I guess that would mean that we'd almost have to implement the variant above?
I think it's fine to just reuse the existing  which accepts a "standard variety" of boolean options. Makes sense to me to have a single source of truth! Right now I don't think we have a lot of precedent for modifying after creation so this may not be easy. Perhaps a helper method on though? That's what a . Yeah let's just have trump . The precise semantics likely don't matter too much anyway as we'll quickly phase out the version anyway.
Change:
guidelines as of yet, but basic rules like 4 spaces for indentation and no more than 99 characters in a single line should be kept in mind when writing code. <del> - `rustup toolchain link <name> build/<host-triple>/<stage>` - Use the custom compiler build via [rustup](https://github.com/rust-lang-nursery/rustup.rs#working-with-custom-toolchains-and-local-builds). </del> <ins> ### Using your local build If you use Rustup to manage your rust install, it has a feature called ["custom toolchains"][toolchain-link] that you can use to access your newly-built compiler without having to install it to your system or user PATH. If you've run `python x.py build`, then you can add your custom rustc to a new toolchain like this: [toolchain-link]: https://github.com/rust-lang-nursery/rustup.rs#working-with-custom-toolchains-and-local-builds ``` rustup toolchain link <name> build/<host-triple>/stage2 ``` Where `<host-triple>` is the build triple for the host (the triple of your computer, by default), and `<name>` is the name for your custom toolchain. (If you added `--stage 1` to your build command, the compiler will be in the `stage1` folder instead.) You'll only need to do this once - it will automatically point to the latest build you've done. Once this is set up, you can use your custom toolchain just like any other. For example, if you've named your toolchain `local`, running `cargo +local build` will compile a project with your custom rustc, setting `rustup override set local` will override the toolchain for your current directory, and `cargo +local doc` will use your custom rustc and rustdoc to generate docs. (If you do this with a `--stage 1` build, you'll need to build rustdoc specially, since it's not normally built in stage 1. `python x.py build --stage 1 src/libstd src/tools/rustdoc` will build rustdoc and libstd, which will allow rustdoc to be run with that toolchain.) </ins> ## Pull Requests

Discussion:
talks about producing builds but not how to use them. i.e. do they need to packaged and installed someplace? Where is this? How do use multiple ones at the same time? etc.
So right now, the includes a little note about , including a link to about the linked toolchain feature. I'll take the opportunity to expand the note into its own section, though.
I've opened up to expand the rustup note into its own section.
Change:
let port = swap_unwrap(&mut *port); // The weak task service is itself a weak task debug!("weakening the weak service task"); <del> unsafe { rust_inc_kernel_live_count(); } </del> <ins> unsafe { rust_dec_kernel_live_count(); } </ins> run_weak_task_service(port); }.finally { debug!("unweakening the weak service task"); <del> unsafe { rust_dec_kernel_live_count(); } </del> <ins> unsafe { rust_inc_kernel_live_count(); } </ins> } }

Discussion:
/ and / do the same thing.
So, should registertask/unregistertask then be exposed in rust_builtin so it can be called from Rust?
Yes, though I suggest renaming it, since it will no longer just be used for 'registering', nor does it strictly have anything to do with tasks or weak tasks from the kernel's perspective - this count is only for determining when to shutdown the runtime. Maybe for the method name and for the builtin. It's not great either, but is less wed to implementation details.
Change:
<ins> use std::cell::Cell; #[rustfmt::skip] fn f( f: for<'a, 'b, 'c, 'd, 'e, 'f, 'g, 'h, 'i, 'j, 'k, 'l, 'm, 'n, 'o, 'p, 'q, 'r, 's, 't, 'u, 'v, 'w, 'x, 'y, 'z, 'z0> fn(Cell<(&   i32, &'a i32, &'b i32, &'c i32, &'d i32, &'e i32, &'f i32, &'g i32, &'h i32, &'i i32, &'j i32, &'k i32, &'l i32, &'m i32, &'n i32, &'o i32, &'p i32, &'q i32, &'r i32, &'s i32, &'t i32, &'u i32, &'v i32, &'w i32, &'x i32, &'y i32, &'z i32, &'z0 i32)>), ) -> i32 { f //~^ ERROR mismatched types } fn main() {} </ins>

Discussion:
label regression-from-stable-to-nightly regression in , cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label A-diagnostics
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
} /// Currently used by macro_rules! compilation to extract a little information from the `Failure` case. <del> pub struct FailureForwarder; </del> <ins> pub struct FailureForwarder<'matcher> { expected_token: Option<&'matcher Token>, } impl<'matcher> FailureForwarder<'matcher> { pub fn new() -> Self { Self { expected_token: None } } } </ins> <del> impl<'matcher> Tracker<'matcher> for FailureForwarder { </del> <ins> impl<'matcher> Tracker<'matcher> for FailureForwarder<'matcher> { </ins> type Failure = (Token, usize, &'static str); fn build_failure(tok: Token, position: usize, msg: &'static str) -> Self::Failure {

Discussion:
one of the desired output should be much help, rather than: No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
) => false, (ParamCandidate(other), ParamCandidate(victim)) => { <del> if other.value == victim.value && victim.constness == Constness::NotConst { </del> <ins> let value_same_except_bound_vars = other.value.skip_binder() == victim.value.skip_binder() && !other.value.skip_binder().has_escaping_bound_vars(); if value_same_except_bound_vars { // See issue #84398. In short, we can generate multiple ParamCandidates which are // the same except for unused bound vars. Just pick the one with the fewest bound vars // or the current one if tied (they should both evaluate to the same answer). This is // probably best characterized as a "hack", since we might prefer to just do our // best to *not* create essentially duplicate candidates in the first place. other.value.bound_vars().len() <= victim.value.bound_vars().len() } else if other.value == victim.value && victim.constness == Constness::NotConst { </ins> // Drop otherwise equivalent non-const candidates in favor of const candidates. true } else {

Discussion:
Hello After upgrading nightly rustc, I'm getting a lot of type inference errors on code that was compiling fine previously. Moreover, these are not at the call site, but at the definition site, so there doesn't seem to be any place to put any type annotations, like this: It spills more kinds of errors that make little sense, but I have the impression these will have a common cause: The problematic code is both released on (crate spirit, version 0.4.16, but I expect that to be happening through most of the history of the crate), and in master (). I think this is a regression, as it was compiling previously. It compiles fine with older nightly (and stable is fine way back, this particular code is looking mostly the same for some 2 years or more): Breaks with (Unfortunately, I haven't been keeping fully up to date recently, so I don't have a smaller range).
Bisected: searched nightlies: from nightly-2021-01-01 to nightly-2021-04-20 regressed nightly: nightly-2021-04-01 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: </detailsRegressed PR is , cc
An MCVE would be extremely helpful here.
ping icebreakers-cleanup-crew I've tried without success to reduce this, it's buried in layers of crates. Maybe one of you will have better luck.
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Reduced:
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-high
I can try to look into this over the weekend.
So, a bit of info: We end up trying to prove . We end up with two candidates: and that both evaluate to okay. This is ambiguous and WF checking fails.
This regression now slipped into beta 1.53.0.
Change:
<ins> // Regression test for issue #121898. trait Base { type Base<B>; } trait Functor<A>: Base { fn fmap<B>(self, f: impl Fn(A) -> B) -> Self::Base<B> where Self::Base<B>: Functor<B>; } fn fmap2<T, A, B, C>(input: T, f1: impl Fn(A) -> B, f2: impl Fn(B) -> C) -> T::Base<C> where T: Functor<A>, T::Base<B>: Functor<B, Base<C> = T::Base<C>>, { input.fmap(f1).fmap(f2) //~^ ERROR the trait bound `<T as Base>::Base<C>: Functor<C>` is not satisfied } 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. --issue appeared when going from 1 -2, was able to fix it by adding 3 <!-- 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
I've only skimmed the code but this is very likely due to the diagnostic method constructing a projection, more precisely an , with created for the trait item, not the associated type (with (pseudo) ), so we're missing the own generic arguments for the GAT.
Change:
// Colorize addition/replacements with green. for &SubstitutionHighlight { start, end } in highlight_parts { <del> // Account for tabs when highlighting (#87972). let tabs: usize = line_to_add .chars() .take(start) .map(|ch| match ch { 't' => 3, _ => 0, }) .sum(); buffer.set_style_range( *row_num, max_line_num_len + 3 + start + tabs, max_line_num_len + 3 + end + tabs, Style::Addition, true, ); </del> <ins> // This is a no-op for empty ranges if start != end { // Account for tabs when highlighting (#87972). let tabs: usize = line_to_add .chars() .take(start) .map(|ch| match ch { 't' => 3, _ => 0, }) .sum(); buffer.set_style_range( *row_num, max_line_num_len + 3 + start + tabs, max_line_num_len + 3 + end + tabs, Style::Addition, true, ); } </ins> } *row_num += 1; }

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. --code is from clippy: :warning: you need rustc build with debug assertions :warning: <!-- 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
Run into this while fuzzing, here is a minimized test case: Note that you need rustc with debug assertions enabled. Reproduced in nightly 2022-02-25.
Another test case:
OP and seem to be fixed on latest master (). now outputs "Span must not be empty and have no suggestion" <details<summarybacktrace</summary</details
I can confirm that both of my examples have been fixed on latest master () so this issue can be closed.
Change:
#[allow(non_camel_case_types)]; <ins> #[experimental] </ins> #[simd] pub struct i8x16(i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8, i8); <ins> #[experimental] </ins> #[simd] pub struct i16x8(i16, i16, i16, i16, i16, i16, i16, i16); <ins> #[experimental] </ins> #[simd] pub struct i32x4(i32, i32, i32, i32); <ins> #[experimental] </ins> #[simd] pub struct i64x2(i64, i64); <ins> #[experimental] </ins> #[simd] pub struct u8x16(u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8, u8); <ins> #[experimental] </ins> #[simd] pub struct u16x8(u16, u16, u16, u16, u16, u16, u16, u16); <ins> #[experimental] </ins> #[simd] pub struct u32x4(u32, u32, u32, u32); <ins> #[experimental] </ins> #[simd] pub struct u64x2(u64, u64); <ins> #[experimental] </ins> #[simd] pub struct f32x4(f32, f32, f32, f32); <ins> #[experimental] </ins> #[simd] pub struct f64x2(f64, f64);

Discussion:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this
Change:
/// The current Rust channel pub channel: String, <ins> /// Whether adding git commit information such as the commit hash has been enabled for building pub git_hash: bool, </ins> /// The default Rust edition pub edition: Option<String>,

Discussion:
stable is fine: but beta and nightly are no longer showing commit-hash and commit-date information: ` <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
it's weird because the info is still displayed correctly in the very first oneliner-summary, but if there was some tool that reads the data by looking at or we still should display the right thing.
This appears to have been introduced by . The issue is that the macro uses CFGVERDATE/CFGVERHASH which is only set when compiling rustc. One option is to try to share some code with . Another option is to go the other way and get rustc to share some code with .
Mentoring instructions: set in (Maybe we should try to unify those functions so they don't duplicate so much code and problems like this don't happen in the future?)
I think it should be possible to write a run-make test ensuring this works properly.
claim
Hi im starting my journey of contributing to Rust, i found this issue a good starter for myself, do you think you would be open to let me take this chance to get familiar with the code base?
Hey! Go for it!
Alternatively, you could check out . I THINK that might be more straightforward. But I'll let you decide(:
claim
I tried doing this change in Then i did a and tried running this command on the stage2 rustodc But it appears that the commit-hash and commit-date is still unknown. Im wondering if the issue is that is passed as true in This is my first time making changes and testing in this project, please feel free to correct me if im testing / building in the wrong way.
I'd suggest changing to use instead of so it's easier to tell when these variables are unset without having to build a full stage 2 compiler.
Retagging as stable/stable regression, this already shipped in 1.67 as far as I can tell.
Are you still (interested in) working on this issue? I'd like to claim it otherwise.
please go ahead and claim it!
claim