jiebi/CodeConvo huggingface dataset:
Change:
<ins> //@ compile-flags: -O //@ min-llvm-version: 18.1.3 #![crate_type = "lib"] #![no_std] // The code is from https://github.com/rust-lang/rust/issues/122805. // Ensure we do not generate the shufflevector instruction // to avoid complicating the code. // CHECK-LABEL: define{{.*}}void @convert( // CHECK-NOT: shufflevector // CHECK: insertelement <8 x i16> // CHECK-NEXT: insertelement <8 x i16> // CHECK-NEXT: insertelement <8 x i16> // CHECK-NEXT: insertelement <8 x i16> // CHECK-NEXT: insertelement <8 x i16> // CHECK-NEXT: insertelement <8 x i16> // CHECK-NEXT: insertelement <8 x i16> // CHECK-NEXT: insertelement <8 x i16> // CHECK-NEXT: store <8 x i16> // CHECK-NEXT: ret void #[no_mangle] pub fn convert(value: [u16; 8]) -> [u8; 16] { let addr16 = [ value[0].to_be(), value[1].to_be(), value[2].to_be(), value[3].to_be(), value[4].to_be(), value[5].to_be(), value[6].to_be(), value[7].to_be(), ]; unsafe { core::mem::transmute::<_, [u8; 16]>(addr16) } } </ins>

Discussion:
I tried this code: I expected to see this happen: these two pieces of code produced the same assembly Instead, this happened: the first version generates worse code It most recently worked on: 1.76 :
The main branch of LLVM may have fixed this issue:
Whoops, compared against 1.76, my mistake.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
I have bisected to (). But I'm not sure if this match the backport rules. I have submitted , but it may be rejected.
label llvm-fixed-upstream
Change:
visit::walk_param_bound(self, bound) } <del> fn visit_pat(&mut self, pat: &'a Pat) { match &pat.kind { PatKind::Lit(expr) => { self.check_expr_within_pat(expr, false); } PatKind::Range(start, end, _) => { if let Some(expr) = start { self.check_expr_within_pat(expr, true); } if let Some(expr) = end { self.check_expr_within_pat(expr, true); } } _ => {} } visit::walk_pat(self, pat) } </del> fn visit_poly_trait_ref(&mut self, t: &'a PolyTraitRef, m: &'a TraitBoundModifier) { self.check_late_bound_lifetime_defs(&t.bound_generic_params); visit::walk_poly_trait_ref(self, t, m);

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. --Note: this only occurs when the type of the code block is a result. Removing the line and swapping for does not yield the ICE. //! use rustice::sub; //! //! let x = sub::makestruct()?; //! //! assert!(matches!(x, sub::En::A(sub::B { inner: vec![], .. }))); //! Ok::<(), &'static str(()) //! <!-- 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. --: and after a rustup, (still getting the same ICE): <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Here's a reproduction without rustdoc involved:
Minimized:
Change:
match &result { &Ok(Some(ref vtable)) => { <ins> // If we see an explicit negative impl (e.g. 'impl !Send for MyStruct'), // we immediately bail out, since it's impossible for us to continue. match vtable { Vtable::VtableImpl(VtableImplData { impl_def_id, .. }) => { // Blame tidy for the weird bracket placement if infcx.tcx.impl_polarity(*impl_def_id) == hir::ImplPolarity::Negative { debug!("evaluate_nested_obligations: Found explicit negative impl {:?}, bailing out", impl_def_id); return None; } }, _ => {} } </ins> let obligations = vtable.clone().nested_obligations().into_iter(); if !self.evaluate_nested_obligations(

Discussion:
Hi, I noticed a weird internal error using . The smallest example I could make to reproduce the bug is an basic library project () whose contains: , , and all work fine; and as mentioned in the code, the place where is declared seems to matter. Here is the output and trace of : [log was from an out of date nightly rust, see my comment below for the log for the latest nightly as of this edit] Have a nice day.
My bad, I appear to have accidentally used a version of rust that wasn't up to date. The bug still occurs in the latest nightly, here's the backtrace: Sorry again about that.
It looks like is only checking for explicit negative impls at the very beginning, and not throughout the process. I should have a fix for this later today.
Looks like this error has been there the whole time that synthetic impls have been there - that sample fails all the way back to 1.26.0.
Change:
fn f4<X: T>(x: &X) { } <del> // Test with unsized enum. enum E<X: ?Sized> { V(X), } </del> fn f5<Y>(x: &Y) {} fn f6<X: ?Sized>(x: &X) {} <del> fn f7<X: ?Sized>(x1: &E<X>, x2: &E<X>) { f5(x1); //~^ ERROR `X: std::marker::Sized` is not satisfied f6(x2); // ok } </del> // Test with unsized struct. struct S<X: ?Sized> {

Discussion:
Backtrace: This seems to occur when using a non-struct type that contains an unsized type. This is probably because  only handles and the base unsized types. This should be extended to handle enums and tuples as well.
This is still happening. Does this mean we should avoid using DSTs for complex custom types for now?
Visiting for triage This is still an issue:
ICE also happens with a tupled trait object:
I've seen this too with: Reproducer: Version: Backtrace:
No longer reproduces but the other tests do.
cc
Is this the same as or related to ?
leads to . As mentioned inline, using the correct type works (). I'm using the Ubuntu PPA "rust-nightly", version ~~vivid.
Does not compile for other reasons that the ICE anymore. I've adjusted to the following and could not reproduce it anymore.
Another example hitting this same ICE:
Bugs similar to this one have been reported numerous times (most of the references to this issue are duplicates). Although it would be nice for reporters to search for similar issues before filing a new one, it's hard to blame them, since the ICE message from rustc tells people to file an issue. This issue itself was opened over two years ago. Separate from fixing the underlying problem, we should at least investigate displaying a real error instead of an ICE.
Change:
fn make_run(run: RunConfig<'_>) { let builder = run.builder; let compiler = builder.compiler(builder.top_stage, run.build_triple()); <ins> let test_kind = builder.kind.into(); let krate = builder.crate_paths[&run.path]; </ins> <del> let make = |mode: Mode, krate: &CargoCrate| { let test_kind = builder.kind.into(); builder.ensure(Crate { compiler, target: run.target, mode, test_kind, krate: krate.name, }); }; for krate in builder.in_tree_crates("test", Some(run.target)) { if krate.path.ends_with(&run.path) { make(Mode::Std, krate); } } </del> <ins> builder.ensure(Crate { compiler, target: run.target, mode: Mode::Std, test_kind, krate }); </ins> } /// Runs all unit tests plus documentation tests for a given crate defined

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:
<del> Subproject commit 46e64911ad43c519c61d22afef7f82625dd9c4a8 </del> <ins> Subproject commit fb33fad08e8f08c032b443bab0df299ce22fe61b </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. 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.
I just tried to update my rustc nightly, it breaks and says component is not available: Could the issue be also related to this one?
yes, very much related. I had a fix yesterday, but it didn't get through in time for todays nightly. Try again tomorrow
Change:
update_env_for_crate = bind identity_update_env_for_crate[ENV](_,_), update_env_for_item = bind identity_update_env_for_item[ENV](_,_), <ins> update_env_for_view_item = bind identity_update_env_for_view_item[ENV](_,_), </ins> update_env_for_block = bind identity_update_env_for_block[ENV](_,_), update_env_for_stmt = bind identity_update_env_for_stmt[ENV](_,_), update_env_for_decl = bind identity_update_env_for_decl[ENV](_,_),

Discussion:
I was trying to build the stdlibs for the target like this: However, the build fails with the following error: Here is the full build log: I'm using Xubuntu 15.10. At the time of building, the Rust master was at .
Unfortunately is a which means that we don't guarantee that it builds in-tree right now. Patches are certainly welcome to fix this, however! We tend to not keep issues tracking build support for all Tier 3 platforms, however, so I'm going to close this. If you're interested in promoting this to at least tier 2 you could also help modify out to be able to support this target!
Change:
add_without_unwanted_attributes(attributes, hir_map.attrs(item.hir_id()), is_inline); } <del> let def_id = if let [.., parent_segment, _] = &path.segments { match parent_segment.res { hir::def::Res::Def(_, def_id) => def_id, _ if parent_segment.ident.name == kw::Crate => { // In case the "parent" is the crate, it'll give `Res::Err` so we need to // circumvent it this way. tcx.parent(item.owner_id.def_id.to_def_id()) } _ => break, } } else { // If the path doesn't have a parent, then the parent is the current module. tcx.parent(item.owner_id.def_id.to_def_id()) }; let Some(parent) = hir_map.get_if_local(def_id) else { break }; // We get the `Ident` we will be looking for into `item`. let looking_for = path.segments[path.segments.len() - 1].ident; visitor.reset(looking_for); match parent { hir::Node::Item(parent_item) => { hir::intravisit::walk_item(&mut visitor, parent_item); } hir::Node::Crate(m) => { hir::intravisit::walk_mod( &mut visitor, m, tcx.local_def_id_to_hir_id(def_id.as_local().unwrap()), ); } _ => break, } if let Some(i) = visitor.item { </del> <ins> if let Some(i) = visitor.find_target(tcx, item.owner_id.def_id.to_def_id(), path) { </ins> item = i; } else { break;

Discussion:
When running with the above code, the docs list the following items: <details<summaryDocs</summary </detailsI would expect to be listed as a reexport, not a struct. The way it is now, it looks like and are different types, which is not the case. If is made , everything looks as it's supposed to. label +T-rustdoc
It's the intended behaviour. Since the module is private, is inlining the item into .
Yes, but is public, so should it really be inlined a second time?
Ok sorry I misunderstood what you meant. No, it shouldn't be inlined a second time.
Change:
<ins> #!/bin/sh # 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. set -ex # We need to mitigate rust-lang/rust#34978 when compiling musl itself as well export CFLAGS="-fPIC -Wa,-mrelax-relocations=no" export CXXFLAGS="-Wa,-mrelax-relocations=no" MUSL=musl-1.1.14 curl https://www.musl-libc.org/releases/$MUSL.tar.gz | tar xzf - cd $MUSL ./configure --prefix=/musl-x86_64 --disable-shared make -j10 make install cd .. rm -rf $MUSL # To build MUSL we're going to need a libunwind lying around, so acquire that # here and build it. curl -L https://github.com/llvm-mirror/llvm/archive/release_37.tar.gz | tar xzf - curl -L https://github.com/llvm-mirror/libunwind/archive/release_37.tar.gz | tar xzf - mkdir libunwind-build cd libunwind-build cmake ../libunwind-release_37 -DLLVM_PATH=/build/llvm-release_37  -DLIBUNWIND_ENABLE_SHARED=0 make -j10 cp lib/libunwind.a /musl-x86_64/lib </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:
) -> Result<&'tcx FnAbi<'tcx, Ty<'tcx>>, &'tcx FnAbiError<'tcx>> { let sig = cx.tcx.normalize_erasing_late_bound_regions(cx.param_env, sig); <del> let conv = conv_from_spec_abi(cx.tcx(), sig.abi); </del> <ins> let conv = conv_from_spec_abi(cx.tcx(), sig.abi, sig.c_variadic); </ins> let mut inputs = sig.inputs(); let extra_args = if sig.abi == RustCall {

Discussion:
While testing variadic function support with I discovered that Rust requires such functions to use either "C" or "cdecl" ABIs but requires the "system" ABI on non-x86 Windows. My undertstanding from discussing with is that this is not an issue with itself but with Rust's insistence that such functions aren't allowed to use the "system" ABI. It's just that is very strict about calling convention so that's where the issue surfaced. On x64 I should be able to compile this but Rust says no: This example works if I change the ABI to "cdecl" but that's not meant to be a valid ABI on x64 and so when I try to compile this with it fails: The practical result is that it is impossible to link this function with on non-x86.
cc which originally variadics support to some other calling conventions (though not it seems) behind the feature gate .
A workaround is to use "C" on non-x86 as I implemented here:
Thoughts on permitting variadic parameters with the calling convention for non-x86 Windows? If gets merged then we'll be pushing folks to use so that they get the correct calling convention for Windows APIs on all architectures, but that breaks compatibility with variadic parameters.
This work-around is . Would be great if there was a way that it could be avoided. :)
There's a comment saying this can't work: I don't understand anything about these ABIs so I can't say how accurate this is. Also I see nothing here special-casing x86, so why does the issue specifically mention non-x86?
Happy to update as soon as there's a way to avoid it.
Can we make equal to when applied to a variadic function? It's supposed to be whatever ABI is correct for the system api and is the correct ABI for a variadic win32 function. According to the acts as when applied to a variadic function.
Went ahead and opened for this.
Change:
#[stable(feature = "rust1", since = "1.0.0")] impl<T> io::Seek for Cursor<T> where T: AsRef<[u8]> { fn seek(&mut self, style: SeekFrom) -> io::Result<u64> { <del> let pos = match style { SeekFrom::Start(n) => { self.pos = n; return Ok(n) } SeekFrom::End(n) => self.inner.as_ref().len() as i64 + n, SeekFrom::Current(n) => self.pos as i64 + n, </del> <ins> let (base_pos, offset) = match style { SeekFrom::Start(n) => { self.pos = n; return Ok(n); } SeekFrom::End(n) => (self.inner.as_ref().len() as u64, n), SeekFrom::Current(n) => (self.pos, n), </ins> }; <del> if pos < 0 { Err(Error::new(ErrorKind::InvalidInput, "invalid seek to a negative position")) </del> <ins> let new_pos = if offset >= 0 { base_pos.checked_add(offset as u64) </ins> } else { <del> self.pos = pos as u64; Ok(self.pos) </del> <ins> base_pos.checked_sub((offset.wrapping_neg()) as u64) }; match new_pos { Some(n) => {self.pos = n; Ok(self.pos)} None => Err(Error::new(ErrorKind::InvalidInput, "invalid seek to a negative or overflowing position")) </ins> } } }

Discussion:
Seems to be a reroll . I have some idea how to fix it, will try to draft a pull request later, but it basically requires checking the sign of the , ging if required and casting to , and using or . I will divide into cases to demonstrate that this is required, to save repeating phrases, I will use the following notation: S means , L means ; P means , N means ; O+ means we will notice bads by checking OF on add (), O- means we will notice them by checking OF on sub ( after ), Z+ means we will notice by adding as and making sure result is non-negative, Z- is making sure it is negative, D+ mean we will notice bads by asserting OF is set on add (), D- is likewise for sub (). Note the we don't need to consider , because after and we still get the right, large, positive number. So, we have the following cases and appropriate checks that spot trouble: SP -O+Z+D- (there's never a problem, but the others false-positive) LP -O+Z-D- (but D- requires also that the result is non-zero). SN -O-Z+D+ LN -O-D+ (there's never a problem, but the others false-positive) Overall, we see that there is no one test which works for all cases, and a minimum of two cases (and tests) yields the solution described above.
Thanks for the report! I'd definitely believe that the exact implementation here is slightly wrong and could use some tweaking.
I wrote a test that should fail and an implementation that should fix, just waiting for build & tests to finish on my machine before PR. Edit: PR
Change:
<del> error[E0118]: no base type found for inherent implementation </del> <ins> error[E0118]: no nominal type found for inherent implementation </ins> --> $DIR/E0118.rs:1:6 | LL | impl (u8, u8) { <del> |      ^^^^^^^^ impl requires a base type </del> <ins> |      ^^^^^^^^ impl requires a nominal type </ins> | = note: either implement a trait on it or create a newtype to wrap it instead

Discussion:
] To : This should probably use the covered/local terminology from instead of "base type" to avoid the problematic overlap with subtyping/inheritance terminology.
] ] ] (Not really [C-bug], but it was the closest of the template options.)
Just fyi, you can do modify labels to -C-bug +A-diagnostics +C-enhancement +D-newcomer-roadblock which will let you apply most labels yourself. .
Error: Label D-newcomer-roadblock can only be set by Rust team members Please let know if you're having trouble with this bot.
... Oh, unless that happens.
A second attempt :stuckouttongue: modify labels to -C-bug +A-diagnostics +C-enhancement
In the reference, we use the term "nominal type". The error code explanation should also mention unions and trait objects ( is valid). If the person use or , it should also hint at removing the reference and putting them on in the associated items. Not sure if I should open a new issue for that one or not though.
Change:
"rustc_interface", "rustc_metadata", "rustc_mir", <ins> "rustc_plugin", </ins> "rustc_plugin_impl", "rustc_save_analysis", "rustc_target",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. 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.
should fix this
Change:
Cargo = "cargo", HtmlDocs = "rust-docs", RustAnalysis = "rust-analysis", <del> Clippy = "clippy", Rustfmt = "rustfmt", </del> Rls = "rls"; preview = true, RustAnalyzer = "rust-analyzer"; preview = true, <ins> Clippy = "clippy"; preview = true, Rustfmt = "rustfmt"; preview = true, </ins> LlvmTools = "llvm-tools"; preview = true, Miri = "miri"; preview = true, JsonDocs = "rust-docs-json"; preview = true,

Discussion:
It should not be possible that clippy component is missing since we are gating on it in CI..? cc
I think this is a rustup bug somehow, it's looking specifically for : I can back this out to give rustup time to fix it in a new release, this wasn't an urgent fix. I want to spend another few minutes investigating first though.
I don't think rustup's rename system is designed to allow changing the name of a component. contains more information about how and why this was done.
says I need at a minimum to keep the key for clippy-preview. I will try to test that out today but I don't have permissions for a dist-static build and it might take me a bit so I'll put up a revert in the meantime.
I'm happy to run dev-static builds as needed, but I agree that a revert is appropriate for the time being. Please feel free to poke on Zulip if you need a quick review, etc. I'm a little surprised our testing in didn't catch this -- let's make sure we understand how to test it in the future.
what went wrong in is that worked before and after, but running before and after did not. I'll make sure to test that in any future PR.
Change:
.data .get_opt_name() .expect("given a DefId that wasn't a module"); <del> // This unwrap is safe since we know this isn't the root let parent = Some(self.get_module(DefId { index: def_key.parent.expect("failed to get parent for module"), ..def_id })); </del> <ins> let parent = Some(self.nearest_mod_parent(def_id)); </ins> (name, parent) };

Discussion:
Found in the crater run: ICEs: ` This ICE happens on: but only shows a compiler error.
Assigning as and removing .
This is because an integration gets checked, which relies on the feature to be enabled. Once it is enabled, does not fail anymore, and yet the ICE persists . I'll thus kindly ask for this to be "re-prioritized", if possible, thanks. modify labels: +I-prioritize
Assigning and removing as in the prioritization working group.
ping cleanup This needs mcve and bisection
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
searched nightlies: from nightly-2020-07-20 to nightly-2020-08-25 regressed nightly: nightly-2020-07-28 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summary
Minimized:
Change:
); ocx.resolve_regions_and_report_errors(impl_m_def_id, &outlives_env)?; <del> let mut collected_tys = FxHashMap::default(); </del> <ins> let mut remapped_types = FxHashMap::default(); </ins> for (def_id, (ty, args)) in collected_types { match infcx.fully_resolve((ty, args)) { Ok((ty, args)) => {

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-07-11 Regression in cc ^^
This is possibly fixed by , or alternatively . I'll have to look into it, but I'll look into it regardless by tomorrow.
Change:
self.value_count += 1; } <del> if let Some(ref_ty) = ty.builtin_deref(true) && let ty::Slice(..) = ref_ty.ty.kind() { </del> <ins> if let ty::Ref(_, ref_ty, _) | ty::RawPtr(ty::TypeAndMut { ty: ref_ty, .. }) = ty.kind() && let ty::Slice(..) = ref_ty.kind() { </ins> assert!(self.places[place].value_index.is_none(), "slices are not scalars"); // Prepend new child to the linked list.

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
cc