jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: unexpected `==` --> $DIR/issue-101477-let.rs:4:11 | LL |     let x == 2; |           ^^ help: try using `=` instead error: aborting due to previous error </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest replacing the with where appropriate as the suggestion for incorrect usage of in place of already exist. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> FROM ubuntu:16.04 RUN apt-get update && apt-get install -y --no-install-recommends  g++  make  file  curl  ca-certificates  python2.7  git  cmake  xz-utils  sudo  gdb  patch  libssl-dev  pkg-config WORKDIR /build/ COPY build-musl.sh /build/ RUN sh /build/build-musl.sh && rm -rf /build RUN curl -OL https://github.com/Yelp/dumb-init/releases/download/v1.2.0/dumb-init_1.2.0_amd64.deb &&  dpkg -i dumb-init_*.deb &&  rm dumb-init_*.deb ENTRYPOINT ["/usr/bin/dumb-init", "--"] RUN curl -o /usr/local/bin/sccache  https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-02-25-sccache-x86_64-unknown-linux-musl &&  chmod +x /usr/local/bin/sccache ENV RUST_CONFIGURE_ARGS  --target=x86_64-unknown-linux-musl  --musl-root-x86_64=/musl-x86_64 # Newer binutils broke things on some vms/distros (i.e., linking against # unknown relocs disabled by the following flag), so we need to go out of our # way to produce "super compatible" binaries. # # See: https://github.com/rust-lang/rust/issues/34978 ENV CFLAGS_x86_64_unknown_linux_musl=-Wa,-mrelax-relocations=no ENV SCRIPT  python2.7 ../x.py test --target x86_64-unknown-linux-musl &&  python2.7 ../x.py dist --target x86_64-unknown-linux-musl </ins>

Discussion:
Causing our builds to fail. I have no idea why ;_;
According to https://travis- We have 30GB of disk space 23 of which is available on the start of a build: ` At the end of the build, the dir is 23 GB: And such, we're filling up.
cc
According to https://travis- we start out with 5/30GB taken up
Word from travis is that we can't increase disk size right now.
According to the run-pass output directory is 17GB
"Hello world" for musl is 3.5 MB. With 2.8k tests and three separate targets being tested, that's ~30GB. That's where the space is going.
1MB of that 3.5 is debuginfo
Change:
} else { // Only point to return type if the expected type is the return type, as if they // are not, the expectation must have been caused by something else. <del> debug!("return type {:?}", hir_ty); </del> <ins> debug!(?hir_ty, "return type"); </ins> let ty = self.lowerer().lower_ty(hir_ty); <del> debug!("return type {:?}", ty); debug!("expected type {:?}", expected); </del> <ins> debug!(?ty, "return type (lowered)"); debug!(?expected, "expected type"); </ins> let bound_vars = self.tcx.late_bound_vars(hir_ty.hir_id.owner.into()); let ty = Binder::bind_with_vars(ty, bound_vars); let ty = self.normalize(hir_ty.span, ty);

Discussion:
The statement "the caller chooses a type for which can be different from " is confusing because and are always different. I think it would be best to supress that note when the types only differ in reference-ness. The message was introduced in . No response No response
label +D-confusing
Thanks, that note definitely doesn't make sense. CC (). I suggested to move out of in order to catch more cases but that was a bit too aggressive as can be witnessed here — that's on me. We should replicate some parts of , namely checking that the type param in question does not occur in the return expression type. That did cross my mind back then but I didn't really follow up on that thought for some reason.
Thanks for the cc I'll take a look ~today/tomorrow
Opened to avoid making the note if found return type contains the expected return type (type parameter).
Change:
/// ``` #[stable(feature = "open_options_ext", since = "1.10.0")] fn custom_flags(&mut self, flags: i32) -> &mut Self; <del> /// Get the flags as [`libc::c_int`]. /// /// This method allows the reuse of the OpenOptions as flags argument for [`libc::open`]. /// /// [`libc::c_int`]: https://docs.rs/libc/*/libc/type.c_int.html /// [`libc::open`]: https://docs.rs/libc/*/libc/fn.open.html /// /// # Examples /// /// ```no_run /// # #![feature(rustc_private)] /// #![feature(open_options_ext_as_flags)] /// extern crate libc; /// use std::ffi::CString; /// use std::fs::OpenOptions; /// use std::os::unix::fs::OpenOptionsExt; /// /// let mut options = OpenOptions::new(); /// options.write(true).read(true); /// let file_name = CString::new("foo.txt").unwrap(); /// let file = unsafe { libc::open(file_name.as_c_str().as_ptr(), options.as_flags().unwrap()) }; /// ``` #[unstable(feature = "open_options_ext_as_flags", issue = "76801")] fn as_flags(&self) -> io::Result<libc::c_int>; </del> } #[stable(feature = "fs_ext", since = "1.1.0")]

Discussion:
The following code compiles fine with nightly-2020-09-22 (and stable rustc since 1.10.0) but not nightly-2020-09-23. This is minimized from Mentioning , ,
Whoops, I didn't realize the trait itself was stable. Probably the PR should either be reverted or add a default implementation for .
Assigning P-critical as as part of the Prioritization Working Group procedure and removing I-prioritize.
is now broken on nightly as well:
I was under the impression that the traits were not intended to be implemented outside of which means this is really an issue with which shouldn't have implemented at all.  for example has had several methods to it since 1.0. Is there something different with or is this just that it was implemented by a popular crate?
The trait likely should have been , but I think sealed traits were not invented until after 1.0.0.
Can we retroactively seal ? It seems like we should, if we keep adding methods like in
Wouldn't that be a breaking change?
Yes, just like adding more methods to it (which has been done several times)
We could do a crater run to see if sealing it would break anything.
Well clearly it would - it would break async-std the same way broke async std. We need to get them not to use before we can change anything here.
My comment was in reference to sealing , not .
Change:
pub fn check_for_substitution<'a>(reader: &StringReader<'a>, ch: char, <del> err: &mut DiagnosticBuilder<'a>) { </del> <ins> err: &mut DiagnosticBuilder<'a>) -> bool { </ins> UNICODE_ARRAY .iter() .find(|&&(c, _, _)| c == ch)

Discussion:
This code: () Looks pretty identical to this code: But the first one doesn't compile because I accidentally used a unicode minus sign (−) instead of a dash (-). This happened to me when I pasted a constant from Wikipedia. We already produce an error about things like this in other cases. For example with an en space: We produce the following: Maybe we could do the same for the minus sign since it is a pretty confusing error to receive?
The unicode minus sign is already on the list of similar characters: However it looks like it doesn't work in this context.
Change:
/// header, we convert it to an in-band lifetime. fn collect_fresh_in_band_lifetime(&mut self, span: Span) -> ParamName { assert!(self.is_collecting_in_band_lifetimes); <del> let index = self.lifetimes_to_define.len(); </del> <ins> let index = self.lifetimes_to_define.len() + self.in_scope_lifetimes.len(); </ins> let hir_name = ParamName::Fresh(index); self.lifetimes_to_define.push((span, hir_name)); hir_name

Discussion:
Hello, I ran into a problem using lifetime with async struct methods, here is the example: struct Foo<'a{ swag: &'a i32 } impl Foo<'{ async fn bar(&self) -i32 { 1337 } } The error is: '_ Everything is fine if I use explicit lifetime like . Version: 1.39 Nighly (2019-09-19 on playground)
This is happening because the desugaring of uses the lifetime. This is sort of unfortunate, but seems backwards compatible to fix, so I don't think we should block on this.
We decided to focus on this one in the WG meeting -- you still interested in working on it?
Yes, I'm still interested in working on this. I don't think that this should be too hard to fix though if someone else wants it.
Change:
} FieldsShape::Union(_) => { if !arg_layout.is_zst() { <ins> if arg_layout.is_transparent() { let non_1zst_elem = arg_layout.non_1zst_field(cx).expect("not exactly one non-1-ZST field in non-ZST repr(transparent) union").1; return should_use_fp_conv_helper( cx, &non_1zst_elem, xlen, flen, field1_kind, field2_kind, ); } </ins> return Err(CannotUseFpConv); } }

Discussion:
The types and do not have the same ABI, as demonstrated by this testcase: The first is The second is Not sure whom to ping for RISC-V issues.
I think the fix will have to be to treat repr(transparent) unions specially somewhere around here
Cc
I'm afraid that the semantics of on unions are not clearly defined enough to figure out exactly how they should be specially treated (which variant should be used? etc.). Can you ping other people who have more knowledge on this? (If on unions turns out to be incompatible with ABIs that have content destructuring semantics that depends on the types of the field in the (e.g. the RISC-V C psABI) then we definitely have a bigger problem.)
I have no idea who would know anything about RISC-V calling conventions. :shrug: and no other ABI is failing this test. Basically, when the ABI description says "unions do X", then this should only apply to repr(C) and repr(Rust) unions. A repr(transparent) union must be treated exactly like its non-ZST field.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
I haven't seen the Rust representation before - is the example saying that is splitting the values into float and integer registers and passing them, whereas is treating the whole thing as an bigger opaque integer? If so then based on section 18.2 here, I think the first one would be correct, assuming Rust doesn't ever make its tuples opaque helped me with something RISC-V at some point so may know where to look. Or deferring to clang
I honestly don't know what that means, it is sadly mostly undocumented. But I know it must be the same for the types to be ABI-compatible. has been opened to fix this issue.
now that this is fixed, is there a CI test to catch regressions?
There is a test in  but we don't run tests for riscv, since it's a tier 2 target.
Also see for another ABI issue that affects riscv (and more).
Are tier 2 tests run once before release or anything like that? It seems like at least a subset of tests (this one) are important enough that we should raise a red flag if we brake them somehow on any targets.

But that doesn't fit well into the tiering structure...
I'm not aware of any process like that. Part of the point of being tier 2 is not to burden all contributors with keeping the target working, is it? If we do want to accept that burden, we could consider running something like for tier 2 targets. But having this discussion in a closed issue makes little sense. Do you want to open a new issue or Zulip thread for discussing tier 2 target test coverage?
Inspired by I found a way to have a test for this:
Awesome! Thanks for the update here
Change:
} FieldsShape::Union(_) => { if !arg_layout.is_zst() { <ins> if arg_layout.is_transparent() { let non_1zst_elem = arg_layout.non_1zst_field(cx).expect("not exactly one non-1-ZST field in non-ZST repr(transparent) union").1; return should_use_fp_conv_helper( cx, &non_1zst_elem, xlen, flen, field1_kind, field2_kind, ); } </ins> return Err(CannotUseFpConv); } }

Discussion:
The types and do not have the same ABI, as demonstrated by this testcase: The first is The second is RISC-V had , so the fix will likely . I couldn't find an O-loongarch label. Cc'ing the people listed on
The loongarch ABI seems to be pretty much exactly like the RISC-V ABI, so I wonder if it would make sense to share some of that code so that bugs like this only have to be fixed once.
Thanks for the report! The LoongArch ABI is indeed closely modeled after that of RISC-V, so yeah the fix should look similar. should be able to follow up tomorrow.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
I don't think you meant to tag me. Don't know much about rust.
Doh, the correct Rust/LoongArch person is who happens to have another handle of "hev". Sorry for the noise!
Thanks for your pointing out. I don't think the types and would have the same ABI on LoongArch64. The key point of the problem is that is a , which is different from a : For types and , they are same ABI: The first is: The second is: And it seems that the current ABI of is the same as that of C language on LoongArch64: The first is: The second is:
I haven't studied the LoongArch psABI as closely, but from a Rust semantics perspective: is "a -sized area that may or may not hold an initialized ", so and really should behave the same when that's the case -- implying the two must have the same ABI. So this is something to look into and fix after all...
It's a Rust union, but it doesn't have , so whatever applies to C unions is completely irrelevant. For instance, many ABIs (e.g. x86) treat structs different from integers, and still has the same ABI as -- that's because is not a struct, so its ABI doesn't have to match that of a C struct. We promise that has the same ABI as for all on all targets, so this is really not optional. Your C example, when translated to Rust, needs on all types. The ABI of those types obviously needs to match the C types. But that's completely compatible with also treating types differently.

Thank you for your explanation. Hmm, I'm not familiar with Rust ABI, and it seems to have less relevance to psABI. OK, I will follow the RISC-V patches to fix LoongArch.
It's the same problem we have on all targets: there is a target ABI that is defined in terms of C types, and now every other language has to figure out how to map their types to C types to then compute the ABI from that. Unfortunately the Rust compiler has no central infrastructure for that (there's no function to "give me the C type that describes the ABI of a given Rust type"), and so each target has to implement that mapping itself, and they are all making similar mistakes...
label +O-loongarch
Change:
}, 1, ), <del> bodies: Default::default(), </del> <ins> bodies, </ins> }))); <del> feed.feed_owner_id().hir_attrs(hir::AttributeMap::EMPTY); </del> <ins> feed.feed_owner_id().hir_attrs(attrs); </ins> } /// Given an `opaque_ty_def_id` corresponding to an `impl Trait` in an associated

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' File: --auto-reduced (treereduce-rust): original: 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&lt;!-- query stack: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [associatedtypeforimpltraitintrait] creating the associated item corresponding to the opaque type [associatedtypesforimpltraitsinassociatedfn] creating associated items for opaque types returned by [associateditemdefids] collecting associated items or fields of [associateditems] collecting associated items of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
This will probably make a simple crash in a lot of cases :3
cc
minimal repro:
Hmm, when writing I tried to trigger the case by enabling , but it didn't ICE. I'll check what is the difference with what cargo does.
Fixed in
A workaround to this issue should be to use or which should disable incremental compilation.
run on nightly rust also  but. if you use to switch stable version rust will be run will successful
There’s also an environment variable to control incremental compilation, so you could set CARGO_INCREMENTAL=0 to do that.
I think this error should be completely fixed, otherwise it will still fail to compile in the IDE environment and the automatic build environment of GitHub Action
Sure, we were just offering a workaround to unblock people temporarily. The fix is already present on master and should be available in tomorrow’s nightly.
Oh, this is great
Change:
<ins> // Check that we do not ICE due to unresolved segments in visibility path. #![crate_type = "lib"] extern crate alloc as b; mod foo { mod bar { pub(in b::string::String::newy) extern crate alloc as e; //~^ ERROR failed to resolve: `String` is a struct, not a module [E0433] } } </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
glacier ""
searched nightlies: from nightly-2022-10-05 to nightly-2023-03-16 regressed nightly: nightly-2022-10-12 searched commit range: regressed commit:
Newer version of cargo-bisect-rustc can bisect through rollups
The one that is not released yet? :smile: Thx, will install git then.. :)
label +S-bug-has-mcve
Change:
<del> use std::any::Any; </del> <ins> use std::any::{type_name, Any}; </ins> use std::cell::{Cell, RefCell}; use std::collections::BTreeSet; use std::env;

Discussion:
While debugging the CI failure in , I saw the following output in the logs: The first one is and the second I think is , by the fields it has. But we should just print that in the debug logs rather than having to guess. label +A-contributor-roadblock +C-enhancement
This will be annoying to fix because we'll have to remove for and implement it by hand. Maybe we could introduce a new macro making it easier? The module name is available through
label +E-medium +E-mentor +A-rustbuild
The way to go is likely to add type_name to the timing print rather than solely relying on Debug.
Change:
prints: Vec::new(), cg: basic_codegen_options(), color: ColorConfig::Auto, <del> show_span: None, </del> externs: HashMap::new(), crate_name: None, alt_std_name: None,

Discussion:
Not a breaking change since it is an unstable option.
Is it already an unstable option?
this issue is saying that should be changed to . It is already an unstable option.
So can accept as arguments. How would those be specified if were changed to a ?
Hopefully exactly the same way, not sure how possible that is. If it is not possible right now, then this probably isn't an easy issue to fix. I can look into it next week.
We've got kinda our own syntax for the flags so where today you pass it could instead be
Change:
Scalar(v), Undef }); <ins> /// Gets the bytes of a constant slice value. pub fn get_slice_bytes<'tcx>(cx: &impl HasDataLayout, val: ConstValue<'tcx>) -> &'tcx [u8] { if let ConstValue::Slice { data, start, end } = val { let len = end - start; data.get_bytes( cx, // invent a pointer, only the offset is relevant anyway Pointer::new(AllocId(0), Size::from_bytes(start as u64)), Size::from_bytes(len as u64), ).unwrap_or_else(|err| bug!("const slice is invalid: {:?}", err)) } else { bug!("expected const slice, but found another const value"); } } </ins>

Discussion:
Results in cc
modify labels: I-ICE C-Bug T-compiler A-const-generics
I'm looking into this currently.
Partially as a note to myself and partially as an update to anyone interested The root cause of this bug seems to be the fact that we currently don't explicitly handle slice const values in , and therefore we always say they cannot match. This error eventually bubbles up to to produce all three errors.
Change:
<ins> error[E0380]: auto traits cannot have associated items --> $DIR/assoc-ty.rs:10:10 | LL | auto trait Trait { |            ----- auto traits cannot have associated items LL | LL |     type Output; |     -----^^^^^^- help: remove these associated items error[E0658]: auto traits are experimental and possibly buggy --> $DIR/assoc-ty.rs:8:1 | LL | / auto trait Trait { LL | | LL | |     type Output; LL | | LL | | } | |_^ | = note: see issue #13231 <https://github.com/rust-lang/rust/issues/13231> for more information = help: add `#![feature(auto_traits)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date error[E0308]: mismatched types --> $DIR/assoc-ty.rs:15:36 | LL |     let _: <() as Trait>::Output = (); |            ---------------------   ^^ expected associated type, found `()` |            | |            expected due to this | = note: expected associated type `<() as Trait>::Output` found unit type `()` = help: consider constraining the associated type `<() as Trait>::Output` to `()` or calling a method that returns `<() as Trait>::Output` = note: for more information, visit https://doc.rust-lang.org/book/ch19-03-advanced-traits.html error: aborting due to 3 previous errors Some errors have detailed explanations: E0308, E0380, E0658. For more information about an error, try `rustc --explain E0308`. </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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<strongICE location label +A-auto-traits +F-unboxed_closures
Minimized: <details<summaryError output</summary</details label -F-unboxedclosures +F-autotraits
Regression in nightly-2023-06-18 (...)
probably just another duplicate of

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unexpected builtin trait with associated type: <u16 as Z<'b, u16', 'error: internal compiler error: unexpected builtin trait with associated type: <u16 as Z<'b, u16' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in nightly-2023-06-18 Regression in / ping
The depth of the stack at the ICE depends on the recursion limit. Add and it still ICEs, but with only 8 repeated stack portions.
Simplified to use only locally defined traits, not use a lifetime parameter, and hit fewer errors: Oddly enough, this variant hits the same ICE but without such a deep stack.
You can replace the bound with a lifetime bound to reproduce too, such as .