jiebi/CodeConvo huggingface dataset:
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. // error-pattern:thread 'main' panicked at 'attempt to multiply with overflow' // compile-flags: -C debug-assertions fn main() { let _x = 2u32.pow(1024); } </ins>

Discussion:
Today I learned that eight to the power of eight is zero. Who'da thunk? Incorrect: :arrowright: :x: :arrowright: :x: :arrowright: :x: Correct: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: Oddly enough, this one breaks the pattern: :arrowright: overflow :whitecheck_mark: Haven't bothered with further cases; at this point it's probably best to just look at the implementation and see what's going on.
was supposed to fix this; looks like it missed the unsigned version?
says that is on nightly.
I meant that fixed this for pow() on signed integers, but not on unsigned integers; it looks like the implementation is copy-pasted for some reason.
Could I take a stab at this?
Sure; feel free to ask if you have questions.
Is overflow checking off in the libcore tests? It'd be nice to be able to write some standard tests for overflow, but they seem to not panic even on cases that should right now.
Overflow checking in unit tests () reflects whether the whole compiler was built in debug or release mode. If you need to specify the overflow mode, you can use a separate test which explicitly specifies , like .
This has since been fixed, in , which it looks like also a test, so closing.
Change:
return None; } <ins> use crate::rustc_trait_selection::infer::TyCtxtInferExt; use crate::rustc_trait_selection::traits::query::normalize::AtExt; use rustc_middle::traits::ObligationCause; </ins> // Try to normalize `<X as Y>::T` to a type let lifted = ty.lift_to_tcx(cx.tcx).unwrap(); <del> match cx.tcx.try_normalize_erasing_regions(cx.param_env, lifted) { </del> <ins> let normalized = cx.tcx.infer_ctxt().enter(|infcx| { infcx .at(&ObligationCause::dummy(), cx.param_env) .normalize(lifted) .map(|resolved| infcx.resolve_vars_if_possible(resolved.value)) }); match normalized { </ins> Ok(normalized_value) => { <del> trace!("normalized {:?} to {:?}", ty, normalized_value); </del> <ins> debug!("normalized {:?} to {:?}", ty, normalized_value); </ins> Some(normalized_value) } Err(err) => { <del> info!("failed to normalize {:?}: {:?}", ty, err); </del> <ins> debug!("failed to normalize {:?}: {:?}", ty, err); </ins> None } }

Discussion:
It'd be good to minimize this and reproduce this outside of rustc. ! !
This bisects to . Stop looking at me like that! is still a thing! And no, before someone asks, I do not volunteer to do this sort of thing on a regular basis. It took all day. I did other stuff at the same time, but still...
Thank you so much! FYI, using  (with and ) would've probably been a lot faster :)
cc
I guess the issue here is that is erasing the lifetimes (=regions) in the type, hence its name. cc as well
I'm working on it.
I feel very embarrassed. I figured that it wouldn't work, because generally cargo explodes whenever I try to use it on the compiler. I take it would actually work though?
Actually, I think you're right to use . cargo-bisect-rustc doesn't usually work on the compiler Sorry about that!
The underlying principle should work though, by specifying rustc = ... in pointing to a rustup-toolchain-install-master'd binary (and potentially cargo = and/or rustdoc =).
Change:
/// Using [`Acquire`] as success ordering makes the store part of this /// operation [`Relaxed`], and using [`Release`] makes the final successful /// load [`Relaxed`]. The (failed) load ordering can only be [`SeqCst`], <del> /// [`Acquire`] or [`Relaxed`] and must be equivalent to or weaker than the /// success ordering. </del> <ins> /// [`Acquire`] or [`Relaxed`]. </ins> /// /// **Note:** This method is only available on platforms that support atomic /// operations on `u8`.

Discussion:
Currently requires the failure ordering to "be equivalent to or weaker than a success ordering". On the other hand C11/C++11 requires only that "failure shall be no stronger than the success", which arguably means that one can write e.g. in C/C++ but not in Rust. Arguably, because neither C11 standard nor C++11 standard defines what it means for an ordering to be stronger from another. When the issue was raised in [LWG2445], the proposed and accepted resolution was to lift those restrictions altogether, leaving only requirement that "the failure argument shall not be nor ". It would be beneficial to remove success/failure ordering restrictions for reasons described in C++ proposal [P0418r2]. [LWG2445]: [P0418r2]: EDIT: Restrictions were lifted in clang & LLVM:
Blocked on The cmpxchg release acquire is accepted by LLVM but miscompiled on AArch64.
I'm about to send a PR that implements this.
I do have implementation ready as well, but that's fine, I can review instead :-).
I split it in a PR that renames the intrinsics first, and a separate PR for exposing the new ordering combinations afterwards.
Looks like llvm 12 doesn't support this: Can we make things conditionally fall back to a stronger ordering depending on the llvm version? I don't think we do anything like that in the library right now, but maybe the compiler already does things differently for different llvm versions?
Ah yes, some code checks . I suppose Builder::atomic_cmpxchg could check the same, and upgrade the ordering if necessary in that case.
Did exactly that in
To do: [x] Add codegen test. [x] Publicly expose the new orderings. [x] Update memory order lint to accept the new orderings.
Change:
use std::collections::HashMap; use std::env; use std::fs::{self, File}; <del> use std::path::{PathBuf, Path}; </del> <ins> use std::path::{Component, PathBuf, Path}; </ins> use std::process::Command; use build_helper::{run_silent, output};

Discussion:
When building from git source, the build system makes a deep clone of git submodules, even those, like or , that had been disabled with configure options. ( and respectively) Not downloading a couple hundred megabytes of data spread over tens of thousands of small files is especially important on flash devices (and slow connections).
At the very least it should probably do a shallower clone of those repos. As best I can tell, you should be able to just pass to just fine.
Yep, that would be a great start. However the gist of this report is to completely forego downloading the source trees that are never going to be used.
I've just tested your patch, having done a shallow clone first and is not cloned at all but still is. Still, a huge improvement; thanks! I also paid attention to the amount of data downloaded by fully cloning other modules, like , , etc. and it seems bootstrapping from a source snapshot is still the fastest option, requiring a 50% smaller download.
Change:
<ins> error[E0433]: failed to resolve: use of undeclared type `E` --> $DIR/non-ADT-struct-pattern-box-pattern-ice-121463.rs:6:17 | LL |     let mut a = E::StructVar { boxed: Box::new(5_i32) }; |                 ^ |                 | |                 use of undeclared type `E` |                 help: a trait with a similar name exists: `Eq` error[E0433]: failed to resolve: use of undeclared type `E` --> $DIR/non-ADT-struct-pattern-box-pattern-ice-121463.rs:9:9 | LL |         E::StructVar { box boxed } => { } |         ^ |         | |         use of undeclared type `E` |         help: a trait with a similar name exists: `Eq` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain 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

<!-- [31mICE[0m: Rustc '-Zcrate-attr=feature(constrefstostatic) -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: expected wide pointer extra data (e.g. slice length or trait object vtable)', 'error: internal compiler error: expected wide pointer extra data (e.g. slice length or trait object vtable)' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [evaltoallocationraw] const-evaluating + checking [evaltoconstvalueraw] simplifying constant for the type system [analysis] running analysis passes on this crate --
cc
You can add to get this kind of stacktrace:
Change:
self.process_switch_int(discr, targets, bb, &mut state); self.find_opportunity(pred, state, cost, depth + 1); } <del> _ => self.recurse_through_terminator(pred, &state, &cost, depth), </del> <ins> _ => self.recurse_through_terminator(pred, || state, &cost, depth), </ins> } <del> } else { </del> <ins> } else if let &[ref predecessors @ .., last_pred] = &predecessors[..] { </ins> for &pred in predecessors { <del> self.recurse_through_terminator(pred, &state, &cost, depth); </del> <ins> self.recurse_through_terminator(pred, || state.clone(), &cost, depth); </ins> } <ins> self.recurse_through_terminator(last_pred, || state, &cost, depth); </ins> } let new_tos = &mut self.opportunities[last_non_rec..];

Discussion:
File: season two 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
cc
I cannot reproduce the original anymore, but does reproduce. The body is impossible because of the where clauses, so no MIR opts should ever run on it... I'll take a look.
I can still reproduce this with the original mvce when I use the flags that I listed.
bisected with searched nightlies: from nightly-2023-09-01 to nightly-2023-10-01 regressed nightly: nightly-2023-09-09 searched commit range: regressed commit: bisected with <a href=''cargo-bisect-rustc</av0.6.8 cc oli was right:
The bisection here isn't useful sadly, but thank you anyways. I took a look and yeah, the issue is what I suspected. () checks whether there are any impossible predicates (like here). It sadly has to filter out "non-global" predicates, which belongs to. It has to do this because of overflows as mentioned above. told me that the new trait solvers non-fatal handling of overflow will allow this to be fixed. But until then, there's nothing we can do. As for getting the code working, the solution here so to avoid these impossible bounds wherever possible. In the example here, that's easy to do, just delete it. In that's a bit more annoying, I don't really see a solution. We could try playing whack-a-mole by trying to make the MIR opts sorta-handle these cases that slip through, but I don't think that's very sustainable. Might work at least for the trivial cases like though, but I don't open PRs for that.
another one
I'm afraid that this has reached stable with 1.78. I couldn't reproduce it with the minimal example in the previous comment, but a crate of mine now fails on stable, but compiled fine on 1.77.2: <details<summaryfull output</summary</detailsThe code responsible for this is fairly simple: Removing that impl makes the crate compile again.

Will we still just wait for the new solver, now that it's a stable-stable regression?
I managed to minimize the example from : (, ICE in release mode)
Change:
variance); } <del> ty::ty_trait(box ty::TyTrait { def_id, ref substs, .. }) => { </del> <ins> ty::ty_trait(box ty::TyTrait { def_id, ref substs, bounds }) => { </ins> let trait_def = ty::lookup_trait_def(self.tcx(), def_id); let generics = &trait_def.generics;

Discussion:
If you pass an immutable reference through two structs, one of which is a trait, you can take an immutable reference to a variable that will be mutated later, and the compiler will compile. For a proof of concept, see , and if you want to see it in an actual use case, see (look in the main file). I don't know if this is an issue or not, it didn't cause any safety issues when I used it. Is there a rust-ier way of doing the type of thing I did in the second example (allow an immutable reference to a value that will be mutated, in order to see the new value).
The whole thing in one piece: Thanks for filing, these memory safety bugs are very important to catch, however, I think this may be a duplicate of another bug which I cannot find right now (iirc was interacting with those other bugs). I believe the underlying problem here is the function is invalid, the boxing/returning that happens should be disallowed without the having the lifetime too.
FWIW, I’ve reduced the issue a little more ():
Nominating
As I posted on IRC, this is a variance problem - is unsoundly bivariant:
Thanks for cutting it down. I still am not a good Rust programmer, so I was just copying, as close as I could, the original, accidental, version.
cc
P-backcompat-lang, 1.0.
seems to be dup of
I tested and this is indeed fixed by PR . Too bad I didn't look into this bug first rather than , since I see that other people already worked out the variance connection already.
Change:
span, if span_to_replace.is_some() { constraint.clone() <ins> } else if constraint.starts_with("<") { constraint.to_string() </ins> } else if bound_list_non_empty { format!(" + {constraint}") } else {

Discussion:
When a type parameter is expected, but an unconstrained associated type is found rustc suggests a syntactically incorrect fix with a misleading help message about trait bounds instead of associated type constraints. No response
Change:
elif color == "never": args.append("--color=never") <del> run(args, env=env, verbose=self.verbose) </del> <ins> # Run this from the source directory so cargo finds .cargo/config run(args, env=env, verbose=self.verbose, cwd=self.rust_root) </ins> def build_triple(self): """Build triple as in LLVM

Discussion:
When downloading a tarball ( from ) and building it with file with , the build fails early with: I have this behaviour in beta since 2022-08-09, and with nightly since 2022-06-25. My file is: rustc and cargo binaries are 1.62.1-stable. The build is done on OpenBSD (but as it is failing at first cargo invocation, I think it is OS agnostic).
Which directory are you invoking from? Is it the source directory or somewhere else? I think the necessary for vendoring to work may be missed if you invoke it from another directory than the source directory. cc
is invoked from outside the source directory. I will check that
ok, I confirm that invoking from inside the source directory solves the problem. now I need to use and to keep my original behavior to build outside the source directory, but it isn't a big deal. it might be something to mention in changelog file. I think it is common in downstream dsitribution to use a different build and source directories. thanks for the help
I think we should support building outside the source directory again.
fixed a bunch of these issues - can you try with a tarball from the latest nightly and see if it's fixed there?
That PR only changes the rust code of rustbuild, not the python code. This issue is while compiling rustbuild. The problem is that is not in the current working directory when compiling rustbuild and as such ignored.
I confirm that the latest nightly doesn't build outside the directory. also, please note that currently the problem is in both beta and nightly channels.
Ah, I see. That seems possible to fix, we can run the command from the source root. The working directory of the build itself shouldn't affect any of the runtime configuration.
Change:
pub(super) fn new_os(code: i32) -> Self { let utagged = ((code as usize) << 32) | TAG_OS; // Safety: `TAG_OS` is not zero, so the result of the `|` is not 0. <del> let res = Self(unsafe { NonNull::new_unchecked(utagged as *mut ()) }); </del> <ins> let res = Self(unsafe { NonNull::new_unchecked(utagged as *mut ()) }, PhantomData); </ins> // quickly smoke-check we encoded the right thing (This generally will // only run in libstd's tests, unless the user uses -Zbuild-std) debug_assert!(

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: either it to compile or not compile. Instead, this happened: it compiled but only on 64-bit platforms. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.59 (where it did not compile no matter what platform) <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Not sure what the best approach is here. We could just to restore consistency from which made auto-implement . cc
which non-64bit platform does reproduce the issue (not sure if this question matters a lot)?
All platforms that have and . For example, . This is caused by this code:
Ah, should have or something along those lines. I'll get a fix for this up later this evening or tomorrow.
Hmm, this should probably not be closed, unless prioritization will still see it if it is closed.
Yeah, for backports I think the issue stays open until the backport is landed or decided against. Reopened for tracking.
Change:
<ins> // edition:2018 #![crate_type="lib"] #![crate_name="xcrate_issue_61711_b"] pub struct Struct; pub use crate as alias; </ins>

Discussion:
I have three crates: (library), (library), and (binary). has no dependencies, and its is just: has the following dependency and : has the following dependency and : The following error happens running or in crate : Try as I may, I can't manage to make the error happen without putting in every one of those lines and dependencies. EDIT: the bug only requires , not
pre-triage: P-high, removing nomination tag. assigning to self for initial investigation.
(seems to me like the line is not necessary to reproduce the bug?) ((but the nonetheless does remain necessary for reproduction....))
Here is a shell script to compile the files using itself (so we get out of the way) and run the compile of under :
and the backtrace from gives us a pretty good hint as to where we might be infinite-looping: (and so on, for at least 15,000 stack frames...)
(prior to rust 1.35.0, it seems like we might have infinite looped here with no stack overflow. Not 100% sure of that yet; and this test case currently relies on 2018 edition, so its not easy to go back to earlier than 1.31.0)
Also, you can inline the contents of crate a into crate b and preserve the erroneous behavior:
Okay I think I have a solution for this. Hope to post PR today or tomorrow.
Change:
<del> include ../../run-make-fulldeps/tools.mk </del> <ins> # ignore-riscv64 $(call RUN,foo) expects to run the target executable natively #                              so it won't work with remote-test-server # ignore-arm Another build using remote-test-server # ignore-none no-std is not supported # ignore-wasm32 FIXME: don't attempt to compile C++ to WASM # ignore-wasm64 FIXME: don't attempt to compile C++ to WASM # ignore-nvptx64-nvidia-cuda FIXME: can't find crate for `std` # ignore-musl FIXME: this makefile needs teaching how to use a musl toolchain #                    (see dist-i586-gnu-i586-i686-musl Dockerfile) </ins> <del> # FIXME https://github.com/rust-lang/rust/issues/78911 # ignore-32bit wrong/no cross compiler and sometimes we pass wrong gcc args (-m64) </del> <ins> include ../../run-make-fulldeps/tools.mk </ins> all: foo $(call RUN,foo) foo: foo.rs $(call NATIVE_STATICLIB,foo) <del> $(RUSTC) $< -lfoo $(EXTRARSCXXFLAGS) </del> <ins> $(RUSTC) $< -lfoo $(EXTRARSCXXFLAGS) --target $(TARGET) </ins> $(TMPDIR)/libfoo.o: foo.cpp $(call COMPILE_OBJ_CXX,$@,$<)

Discussion:
Some run-make tests require an directive as a workaround for link failures that occur during CI. and or modified tests to include this directive in order to avoid at least this error: . I assume that this shouldn't be necessary, and that there is actually some deficiency in our CI build system that we can fix.
Never mind, it may not be related. Sorry for the noise.
Change:
<ins> // check-pass #![feature(specialization)] pub struct Cloned<I>(I); impl<'a, I, T: 'a> Iterator for Cloned<I> where I: Iterator<Item = &'a T>, T: Clone, { type Item = T; fn next(&mut self) -> Option<T> { unimplemented!() } } impl<'a, I, T: 'a> Iterator for Cloned<I> where I: Iterator<Item = &'a T>, T: Copy, { fn count(self) -> usize { unimplemented!() } } fn main() { let a = [1,2,3,4]; Cloned(a.iter()).count(); } </ins>

Discussion:
While playing around with , I encountered an ICE when attempting to compile the following code with nightly on the playground: Compiler output:
Backtrace: Rust Version:
Cannot reproduce with . The example builds and runs successfully.
Change:
} } <del> fn visit_struct_field(&mut self, sf: &'a StructField) { if sf.is_placeholder { self.visit_macro_invoc(sf.id) } else { let name = sf.ident.map(|ident| ident.name) .unwrap_or_else(|| panic!("don't know the field number in this context")); let def = self.create_def(sf.id, DefPathData::ValueNs(name.as_interned_str()), sf.span); self.with_parent(def, |this| visit::walk_struct_field(this, sf)); } </del> <ins> // This method is called only when we are visiting an individual field // after expanding an attribute on it. fn visit_struct_field(&mut self, field: &'a StructField) { self.collect_field(field, None); </ins> } }

Discussion:
Stable, and nightly-2019-09-09: nightly-2019-09-10: Mentioning because this is likely from .
Yeah, this is some known shortcut taken in , sorry. Didn't expect people to hit it that fast. Will fix ~this weekend.
Thanks. The realistic usage where this appears is if you forget to import a derive macro, which happens commonly.
Un-nominating since Vadim self-assigned.
triage: P-high.
Fixed in