jiebi/CodeConvo huggingface dataset:
Change:
inner: IterMut<'a, K, V>, } <ins> /// An owning iterator over the keys of a `HashMap`. /// /// This `struct` is created by the [`into_keys`] method on [`HashMap`]. /// See its documentation for more. /// /// [`into_keys`]: HashMap::into_keys #[unstable(feature = "map_into_keys_values", issue = "75294")] pub struct IntoKeys<K, V> { inner: IntoIter<K, V>, } /// An owning iterator over the values of a `HashMap`. /// /// This `struct` is created by the [`into_values`] method on [`HashMap`]. /// See its documentation for more. /// /// [`into_values`]: HashMap::into_values #[unstable(feature = "map_into_keys_values", issue = "75294")] pub struct IntoValues<K, V> { inner: IntoIter<K, V>, } </ins> /// A builder for computing where in a HashMap a key-value pair would be stored. /// /// See the [`HashMap::raw_entry_mut`] docs for usage examples.

Discussion:
Associative maps ( and ) in Rust are currently missing two methods to get owning iterators to their keys or values. We have to get key-value reference pairs, to get key-value mutable reference pairs and to get owned key-value pairs. I'd expect and to offer a similar trio of methods (with an exception for of course). is there, but the variants are missing for seemingly no good reason. As an example implementation (but perhaps we can do better):
I would accept a PR to introduce unstable intokeys() and intovalues().
Hi, I’m interested in working on this but I have a question regarding the implementation. I guess we can implement this in two ways. First one is implementing like the example in the first comment, like returning . And the second option is to return a struct of its own (like a mixture of and / structs) instead of returning . We can name them IntoKeys and IntoValues and they can be responsible of implementing the trait. I feel like performance wise they are same, since map and custom struct both will be evaluated lazily when we iterate over. But there might be a rule to always return a proper type in the rust std code that I don't know. So I think I’m okay implementing either way but wanted to ask just in case. What do you think?
For the public API I would prefer this implemented using dedicated IntoKeys and IntoValues iterator types. They can be implemented internally as wrappers around Map<IntoIter<K, Vif that simplifies things.
Thanks for the answer Created a PR for this and you as a reviewer. Would you mind taking a look at it when you have time?
Change:
on_ambiguity: impl FnOnce(), ) -> ControlFlow<T, ()> { let mut idx = 0; <ins> let mut in_parent_alias_type = false; </ins> loop { let (kind, alias_ty) = match *self_ty.kind() { ty::Alias(kind @ (ty::Projection | ty::Opaque), alias_ty) => (kind, alias_ty),

Discussion:
I tried this code: I expected to see this happen: It compiles quickly. Instead, this happened: It takes 10s to complete. Bisected to cc
Why did you title this "is broken"? It just takes longer to compile, or is it broken some other way? I'll look into the upcoming week.
Sorry, it just takes longer to compile.
WG-prioritization assigning priority (). label -I-prioritize +P-medium -regression-untriaged
On my machine (Apple M2 Pro), this test currently takes about 30 seconds. But if I enable , the compiler appears to consume 100% CPU forever. I'm not sure whether it's actually stuck, or just taking an incredibly long time, but I've never seen it finish with debug assertions enabled.
If I apply , the test finishes in about 45 seconds with debug assertions enabled, and about 3 seconds with them disabled.
Change:
let src = config.src.clone(); let out = config.out.clone(); <ins> #[cfg(unix)] // keep this consistent with the equivalent check in x.py: // https://github.com/rust-lang/rust/blob/a8a33cf27166d3eabaffc58ed3799e054af3b0c6/src/bootstrap/bootstrap.py#L796-L797 </ins> let is_sudo = match env::var_os("SUDO_USER") { <del> Some(sudo_user) => match env::var_os("USER") { Some(user) => user != sudo_user, None => false, }, </del> <ins> Some(_sudo_user) => { let uid = unsafe { libc::getuid() }; uid == 0 } </ins> None => false, }; <ins> #[cfg(not(unix))] let is_sudo = false; </ins> let ignore_git = config.ignore_git; let rust_info = channel::GitInfo::new(ignore_git, &src);

Discussion:
Trying to build Rust 1.63.0 it fails with the error below:
Hm, so I can't immediately reproduce -- can you say more about what sources you're using to build? is the tarball I used to make an attempt at reproducing. You might also want to check if you've enabled the use of vendored sources ( should contain vendor = true under [build]).
We are using $ md5sum /package/pkg/rustc-1.63.0-0/build/rustc-1.63.0- /package/pkg/rustc-1.63.0-0/build/rustc-1.63.0- We did not have that in our build script. It worked without in the past. Could you refer me to further details, why it’s needed?
That tarball should be content equivalent to .xz, just with gzip compression. I don't see why we would've broken a workflow that worked in the past. Can you link me to the build script you're using? --frozen is passed if we detect that you're running either with . Rustbuild checks for sudo , while our Python script has a slightly different check . Maybe your environment changed in such a way that the Python check isn't true while the rustbuild check is? That would explain the error here. (Setting vendor = true in will override the detection logic here and just enable using the vendored sources from the tarball).
The files are in , and it’s merge/pull request $ git clone $ cd pkg-scripts $ git checkout add-rustc-1.63.0-0-with-cbindgen-0.24.3 $ sudo rustc-1.63.0- # … is what we use. should work in non-MarIuX environment (our distribution). Adapt in the script to your liking.
(Edited last comment.)
It looks like you were previously on 1.61, right? landed in 1.62, which introduced the difference[^1] between handling in and the Rust component for whether we're running inside sudo (as you do). I suspect that difference made us start using vendoring (though not sure), or stop, but either way, it's likely the cause of your problem.

I'm going to go ahead and mark this as E-easy -- we should likely move the Rust code to use the same getuid() == 0 check. I believe we can do that with and appropriately cfg that if needed (based on what CI complains about). [^1]: that I pointed out in
Yes, we did. Thank you for the analysis. If you want us to test anything, please tell us.
Once merges (and we release a new nightly ~24 hours after that) it'd be great to retest with a nightly src tarball in your environment to confirm this is fixed, but also fine to just wait until the next stable release including it and file a new bug if not. That'll be 1.64, releasing September 22nd. (I marked the PR as beta-backport).
Change:
<ins> // edition:2021 // revisions: current next //[next] compile-flags: -Ztrait-solver=next // check-pass #![feature(type_alias_impl_trait)] struct Foo; impl Trait for Foo {} pub trait Trait {} pub type TAIT<T> = impl Trait; async fn foo<T>() -> TAIT<T> { Foo } fn main() {} </ins>

Discussion:
I tried this code: It failed with a confusing error message. (error: concrete type differs from previous defining opaque type use, at the same location) I'm trying to minimize , and found the problem. compiles, but fails. Although not 100% sure, I think it's caused by the same problem as (regression caused by )
cc
I can work on this, and then I can test if it fixes the other issue too.
Change:
} } <del> // These are still macro-generated because the integer literals resolve to different types. macro_rules! step_identical_methods { </del> <ins> // Separate impls for signed ranges because the distance within a signed range can be larger // than the signed::MAX value. Therefore `as` casting to the signed type would be incorrect. macro_rules! step_signed_methods { ($unsigned: ty) => { #[inline] unsafe fn forward_unchecked(start: Self, n: usize) -> Self { // SAFETY: the caller has to guarantee that `start + n` doesn't overflow. unsafe { start.checked_add_unsigned(n as $unsigned).unwrap_unchecked() } } #[inline] unsafe fn backward_unchecked(start: Self, n: usize) -> Self { // SAFETY: the caller has to guarantee that `start - n` doesn't overflow. unsafe { start.checked_sub_unsigned(n as $unsigned).unwrap_unchecked() } } }; } macro_rules! step_unsigned_methods { </ins> () => { #[inline] unsafe fn forward_unchecked(start: Self, n: usize) -> Self {

Discussion:
I tried this code: I expected to see this happen: No UB. Instead, this happened: UB, confirmed by Miri. is called, which does , or . The implementation of is correct here, and should be safe to call. The implementation that does a wrapping cast from to before doing the unchecked math is the incorrect code here. Signed integers should switch to just using wrapping or unsigned math, whichever gets better codegen out of LLVM. We do have and methods now, but no . <!-- 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. --:
Note that this is reachable on stable since the default impl of uses and not all adapters forward both.
did you find this with Miri or just use Miri to confirm the bug? (I'm asking because I may want to add this to our "bugs found by Miri" list :)
Only confirmed/diagnosed with Miri, spotted manually when looking at the code.
Change:
fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; <del> run.path("src/tools/linkchecker").default_condition(builder.config.docs) </del> <ins> let run = run.path("src/tools/linkchecker"); let hosts = &builder.hosts; let targets = &builder.targets; // if we have different hosts and targets, some things may be built for // the host (e.g. rustc) and others for the target (e.g. std). The // documentation built for each will contain broken links to // docs built for the other platform (e.g. rustc linking to cargo) if (hosts != targets) && !hosts.is_empty() && !targets.is_empty() { panic!( "Linkcheck currently does not support builds with different hosts and targets. You can skip linkcheck with --exclude src/tools/linkchecker" ); } run.default_condition(builder.config.docs) </ins> } fn make_run(run: RunConfig<'_>) {

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:
cx.struct_span_lint(OVERFLOWING_LITERALS, e.span, |lint| { lint.build(&format!("literal out of range for `{}`", t.name_str())) .note(&format!( <del> "the literal `{}` does not fit into the type `{}` and will be converted to `std::{}::INFINITY`", </del> <ins> "the literal `{}` does not fit into the type `{}` and will be converted to `{}::INFINITY`", </ins> cx.sess() .source_map() .span_to_snippet(lit.span)

Discussion:
This program: Produces this output: Note the references to ; these symbols have been superseded by associated consts at (). the error message to suggest the new symbols if any of the other old symbols are contained in any error messages. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
See also .
I am working on this. claim
: I've gone and grepped through for , , etc. and found no accidental uses there. I then grepped for each of the individual symbols listed in RFC 2700 (, , etc.) and didn't notice anything out of place. I also grepped for (as seen in this issue) and found only a hint message for things like etc which only triggers when an item isn't found at all, which won't trigger for any of the new consts. Probably safe to close this once merges.
You are right. I was thinking of cases like this one but this can likely be closed with the merge of that PR. I was operating with an abundance of caution.
Yeah, that's the aforementioned case that only shows up in the event of an error, so (AFAICT) that path won't be taken for the new constants since they resolve successfully.
Change:
set(&mut config.initial_rustc, build.rustc.map(PathBuf::from)); set(&mut config.initial_cargo, build.cargo.map(PathBuf::from)); <ins> config.llvm_skip_rebuild = llvm_skip_rebuild.unwrap_or(false); </ins> let default = false; config.llvm_assertions = llvm_assertions.unwrap_or(default);

Discussion:
The compiler LLVM is rebuilt whenever the built version of LLVM doesn't have the right hash. (Previously it was rebuilt based on a special marker file, which was easier to work around.) However, most of the time, having the latest LLVM version is not necessary, but makes rebuilding rustc after rebasing take significantly longer, which is a pain. It would be good to be able to disable this as an option in for convenience. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
To fix this, you'll want to add another option: you should be able to look at the logic for something like .
It would be good if this could be changed in the config file so you don't have to pass in the option all the time.
if it's a config file option, then there should be an option to rebuild it if necessary. I.e. it shouldn't be necessarily to temporarily change the to rebuild.
sure that seems good, although they can be implemented separately.
The line you would need to change is near this one: (line 735 of ) It would probably be much easier to add a check against a key in the config, than to add a new flag.
claim
Error: Parsing assign command in failed: claim ... Please let know if you're having trouble with this bot.
, my bad! claim EDIT: oh dear, I'm making it worse
are you still working on this? I wouldn't mind picking it up if not. (Sorry - not really sure what the etiquette is re: dormant tickets!)
Just saw that PR () lapsed. I'm gonna claim this, if that's okay. Will work on something based on the existing comments there. claim
Thank you for picking this up! Getting things fixed is the important thing, and I'm sure I'll find something else to fix in the near future when I have more time
Change:
<ins> // Verify that we do not ICE when attempting to interpret casts between fn types. // skip-filecheck static FOO: fn() = || assert_ne!(42, 43); static BAR: fn(i32, i32) = |a, b| assert_ne!(a, b); fn main() { FOO(); let bar: unsafe fn(i32, i32) = BAR; let f: fn() = || {}; f(); f(); f(); let g: fn(i32) = |i| assert_eq!(i, 2); g(2); g(2); g(2); } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zmir-opt-level=5 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: ()'', 'thread 'rustc' panicked at 'assertion failed: ()'' 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<!-- query stack: [optimizedmir] optimizing MIR for [collectandpartitionmonoitems] collectandpartitionmono_items --
cc
Change:
/// HashMap where the value is (). As with the `HashMap` type, a `HashSet` /// requires that the elements implement the `Eq` and `Hash` traits. /// <ins> /// It is a logic error for an item to be modified in such a way that the /// item's hash, as determined by the `Hash` trait, or its equality, as /// determined by the `Eq` trait, changes while it is in the set. This is /// normally only possible through `Cell`, `RefCell`, global state, I/O, or /// unsafe code. /// </ins> /// # Examples /// /// ```

Discussion:
Collections that perform lookups based on a given property (e.g. a hash or an ordering) can be put into an inconsistent state when the property changes while its corresponding item is in the collection. This is normally not a problem, because such collections (at least those in ) do not provide mutable access to the type from which the property is derived (keys in the case of maps, items in the case of sets), but types with interior mutability can induce this behavior in safe code: Output: This is obvious from the definition of interior mutability, but it's definitely a footgun. If the use of such keys cannot be prevented with the type system, the collections should at least document that the property must remain constant for the duration of the item's presence in the collection. For example, Java's contains the following note:
This is a dupe of , which was for reasons in the thread itself. I believe the gist of the conversion was that yes, this can happen. Our implementations should ensure that this does not cause memory unsafety, but otherwise these sorts of "odd assertions" are ok to happen as this should be quite a rare occurrence anyway.
I still think the collection documentation needs to identify this problem. On Friday, March 13, 2015, Alex Crichton wrote:
Hm good point! I've an appropriate tag.
I'm working on a patch to document this.
Change:
(ast::LitKind::Int(n, _), ty::Uint(_)) | (ast::LitKind::Int(n, _), ty::Int(_)) => { trunc(if neg { (*n as i128).overflowing_neg().0 as u128 } else { *n })? } <del> (ast::LitKind::Float(n, _), ty::Float(fty)) => parse_float(*n, *fty, neg), </del> <ins> (ast::LitKind::Float(n, _), ty::Float(fty)) => { parse_float(*n, *fty, neg).ok_or(LitToConstError::Reported)? } </ins> (ast::LitKind::Bool(b), ty::Bool) => ConstValue::Scalar(Scalar::from_bool(*b)), (ast::LitKind::Char(c), ty::Char) => ConstValue::Scalar(Scalar::from_char(*c)), (ast::LitKind::Err(_), _) => return Err(LitToConstError::Reported),

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting a malformed float error, so low priority. Note that slight modifications of the input fix the panic. For example using instead of results in no panic. Also there is no panic if compling only the string . Affected versions: I tried nightly 2021-11-30 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Might be related? Formatting of "1e-15" behavior seems to have changed on nightly for f64 and f32.
It may have a common cause, but you should open a separate issue because the pull request that fixes this doesn't fix your problem.
Change:
<ins> error[E0689]: can't call method `pow` on ambiguous numeric type `{float}` --> $DIR/issue-51874.rs:12:19 | LL |     let a = (1.0).pow(1.0); //~ ERROR can't call method `pow` on ambiguous numeric type |                   ^^^ help: you must specify a concrete type for this numeric value, like `f32` | LL |     let a = (1.0_f32).pow(1.0); //~ ERROR can't call method `pow` on ambiguous numeric type |              ^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0689`. </ins>

Discussion:
Please note the
The literal's span should point inside the parenthesis. Probably needs a change to in .
I'm interested in working on this.
feel free to reach out for any help you might need! I believe that you should verify if changing the span being used in the AST for literals changes the suggestion output. If it doesn't, it means that the problem is not at the parser level, but when lowering to HIR. If that is the case, we need to dig deeper, but I'll be here to help you with that.
Change:
pub fn staging_dep_graph_path(sess: &Session) -> PathBuf { in_incr_comp_dir_sess(sess, STAGING_DEP_GRAPH_FILENAME) } <del> pub fn dep_graph_path_from(incr_comp_session_dir: &Path) -> PathBuf { in_incr_comp_dir(incr_comp_session_dir, DEP_GRAPH_FILENAME) } </del> pub fn work_products_path(sess: &Session) -> PathBuf { in_incr_comp_dir_sess(sess, WORK_PRODUCTS_FILENAME)

Discussion:
This function is only used once, with the current session's directory. Is there a reason to keep it, or should it be replaced by ? Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label +A-incr-comp +C-cleanup
feel free to make a PR and r? me on it.
claim
Change:
<ins> error[E0412]: cannot find type `Missing` in this scope --> $DIR/rpitit-shadowed-by-missing-adt.rs:8:35 | LL |     fn w() -> impl Deref<Target = Missing<impl Sized>>; |                                   ^^^^^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0412`. </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
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:
use std::sync::atomic::{AtomicBool, Ordering}; use std::sync::OnceLock; use std::time::{Instant, SystemTime}; <del> use time::format_description::well_known::Rfc3339; </del> use time::OffsetDateTime; #[allow(unused_macros)]

Discussion:
While investigating the ICE in , I saw that every attempt at writing the ICE details to a file (first implemented in ) would fail on my Windows machine with error messages of this kind: The timestamp format used for the file name separates time components with colons, and Windows is generally finicky about having colons in file names since it is already employed as the drive unit delimiter. Could there be a change in the file name format for better compatibility, at least when running rustc on a Windows host? : </p</details
cc
Yes, we can change the format.
Change:
self.static_mutability(def_id) == Some(hir::Mutability::Mutable) } <ins> /// Get the type of the pointer to the static that we use in MIR. pub fn static_ptr_ty(&self, def_id: DefId) -> Ty<'tcx> { // Make sure that any constants in the static's type are evaluated. let static_ty = self.normalize_erasing_regions( ty::ParamEnv::empty(), self.type_of(def_id), ); if self.is_mutable_static(def_id) { self.mk_mut_ptr(static_ty) } else if self.is_foreign_item(def_id) { self.mk_imm_ptr(static_ty) } else { self.mk_imm_ref(self.lifetimes.re_erased, static_ty) } } </ins> /// Expands the given impl trait type, stopping if the type is recursive. pub fn try_expand_impl_trait_type( self,

Discussion:
I have some code which asynchronously computes an integer, and selects an item from a static slice in the same expression. This used to work (it does on stable), but after a nightly update the compiler ICEs when computing generator layout. The bug stops reproducing if I change the static to a local variable, or extract the index into a separate variable. rustc 1.41.0-nightly ( 2019-11-23) binary: rustc commit-hash: commit-date: 2019-11-23 host: x86_64-unknown-linux-gnu release: 1.41.0-nightly LLVM version: 9.0
De-nominating from compiler team as we have a fix pending.
triage: P-high.