jiebi/CodeConvo huggingface dataset:
Change:
warning: attempting to modify a `const` item <del> --> $DIR/lint-const-item-mutation.rs:15:5 </del> <ins> --> $DIR/lint-const-item-mutation.rs:17:5 </ins> | LL |     ARRAY[0] = 5; |     ^^^^^^^^^^^^

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. --I have quite a lot of MMIO in an embedded project, defined and used like this: (see a ) When I , I'm getting a whole host of warnings of the type: I expect no warnings, because I'm not assigning to a , I'm assigning to a dereferenced , aka a mutable u32. I couldn't figure out a playground example that would show the value actually mutating, but by hitting hardware registers I can prove that the value does get mutated, and it makes sense that it would: The pointer is , but it's pointing to a able . Dereferencing shouldn't care whether the pointer variable is . <!-- 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. --: No backtrace for this bug; it's a warning.
There's a... fine, I guess, workaround of in my case, since all the MMIO code is bundled into a module away from the rest.
cc
This will be fixed by
Awesome, thanks so much!
Change:
#[cfg(notest)] #[lang="annihilate"] pub unsafe fn annihilate() { <del> use rt::local_free; </del> <ins> use unstable::lang::local_free; </ins> use io::WriterUtil; use io; use libc;

Discussion:
This is a public module of things that are exported by core but should not be considered part of the stable library interface. Some don't like the name, and indeed it's name is the opposite of it's form. What should it be renamed to?
Internal, implspecific, dontusethis, unstable, changeable, corehacks?
back?
I like "unstable"; can imagine the future bug report about it changing unexpectedly...
'unstable' sounds good to me to.
Change:
--> $DIR/issue-41679-tilde-bitwise-negation-attempt.rs:2:13 | LL |     let x = ~1; <del> |             ^ help: use `!` to perform bitwise negation </del> <ins> |             ^ help: use `!` to perform bitwise not </ins> error: aborting due to previous error

Discussion:
I find the error message confusing and possibly incorrect when attempting to use as a unary operator: In current Rust stable and nightly, I get: The "help" is misleading because it is suggesting using to "perform bitwise negation." But this is not really what ~ performs. which perform different things. I think this message would be best changed to "perform bitwise NOT" or "perform bitwise one's complement"
is referred to as “bitwise not”, “binary complement” and “bitwise negation” among many other names, so the current diagnostic is valid. Not sure where the confusion might arise here, because “bitwise” implies that the operation is… well… bitwise.
would be my preferred phrasing...
Change:
debug_assert!(is_aligned_and_not_null(src), "attempt to copy from unaligned or null pointer"); debug_assert!(is_aligned_and_not_null(dst), "attempt to copy to unaligned or null pointer"); <ins> #[cfg(not(miri))] </ins> debug_assert!(!overlaps(src, dst, count), "attempt to copy to overlapping memory"); copy_nonoverlapping(src, dst, count) }

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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.
Change:
.. })) ) = bind_to.is_user_variable { <del> let pat_snippet = self.infcx.tcx.sess.source_map() .span_to_snippet(pat_span) .unwrap(); if pat_snippet.starts_with('&') { let pat_snippet = pat_snippet[1..].trim_start(); let suggestion; let to_remove; if pat_snippet.starts_with("mut") && pat_snippet["mut".len()..].starts_with(Pattern_White_Space) { suggestion = pat_snippet["mut".len()..].trim_start(); to_remove = "&mut"; } else { suggestion = pat_snippet; to_remove = "&"; </del> <ins> if let Ok(pat_snippet) = self.infcx.tcx.sess.source_map().span_to_snippet(pat_span) { if pat_snippet.starts_with('&') { let pat_snippet = pat_snippet[1..].trim_start(); let suggestion; let to_remove; if pat_snippet.starts_with("mut") && pat_snippet["mut".len()..].starts_with(Pattern_White_Space) { suggestion = pat_snippet["mut".len()..].trim_start(); to_remove = "&mut"; } else { suggestion = pat_snippet; to_remove = "&"; } suggestions.push(( pat_span, to_remove, suggestion.to_owned(), )); </ins> } <del> suggestions.push(( pat_span, to_remove, suggestion.to_owned(), )); </del> } } }

Discussion:
When trying to compile the tests for my I get this error: <details<summary</summary</detailsMy understanding is that the compiler was trying to tell me about a borrow checker error; but I have no idea where to start minimizing this error(sorry).
I have managed to get it down to two files: It doesn't work with a in the , it has to be a different file. is then needed to trigger the ICE.
modify labels: I-ICE A-macros C-Bug T-compiler
cc
Seems to be related to 2018 edition? If I use the nightly-2018-10-01 and execute it doesn't ICE, but with it does ICE. well...
Most likely related to the fact that NLL is active in Rust 2018 then.
Bisecting: Somewhere in
Confirmed. gave me the ICE on 2015 as well (forgot that in the good ol' days nll was not a thing) Also confirmed, that edition 2015 does ICE with on and not on (like edition 2018 did above).
Also ICE with
Change:
use rustc_hir::def_id::{DefId, LocalDefId}; use rustc_hir::intravisit::{walk_generics, Visitor as _}; use rustc_hir::{GenericArg, GenericArgs, OpaqueTyOrigin}; <del> use rustc_infer::infer::{InferCtxt, TyCtxtInferExt}; </del> <ins> use rustc_infer::infer::{InferCtxt, InferOk, TyCtxtInferExt}; </ins> use rustc_infer::traits::ObligationCause; use rustc_middle::middle::stability::AllowUnstable; <del> use rustc_middle::ty::fold::FnMutDelegate; </del> use rustc_middle::ty::subst::{self, GenericArgKind, InternalSubsts, SubstsRef}; use rustc_middle::ty::GenericParamDefKind; use rustc_middle::ty::{self, Const, IsSuggestable, Ty, TyCtxt, TypeVisitableExt};

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hm, maybe not really a new (this month) regression but I also can't find any obvious duplicates right now...
searched toolchains nightly-2022-11-28 through nightly-2023-05-09 Regression in nightly-2022-12-05 Regression in cc
label F-inherentassociatedtypes
I'm pretty sure this can be fixed by erasing all regions no matter their de Bruijn index via instead of . This would "regress" but eh, I guess that's fine for now.
claim
Change:
<ins> // Begin of ARM32 shim // The raw content of this file should be processed by `generate-windows-sys` // to be merged with the generated binding. It is not supposed to be used as // a normal Rust module. cfg_if::cfg_if! { if #[cfg(target_arch = "arm")] { #[repr(C)] pub struct WSADATA { pub wVersion: u16, pub wHighVersion: u16, pub szDescription: [u8; 257], pub szSystemStatus: [u8; 129], pub iMaxSockets: u16, pub iMaxUdpDg: u16, pub lpVendorInfo: PSTR, } pub enum CONTEXT {} } } // End of ARM32 shim </ins>

Discussion:
In the WinAPI definitions have been replaced by windows-bindgen generated bindings. However, the project does not generate metadata for ARM32-specific items, hence the generated bindings lack a few types like and on this platform. It effectively breaks for Rust.
Unfortunately, 32-bit ARM is not being supported by Microsoft going forward. What we could do is insert our own definitions in , copied from before the changes.
Besides the issue with ARM, all UWP targets actually have problems with linkage as well. Previously the APIs forbidden on UWP are gated behind fine-grained conditional compilation flags, but it is no longer the case with generated ones. I got this when building the UWP app that links again a Rust staticlib. !
Iirc, the functions were never gated. But we loaded them lazily (and panicked if they didn't load). This did allow UWP targets to compile. No idea if they actually ran. I'm not sure who's responsible for these targets.
I think you are correct. I can reproduce the link errors with toolchain . Let me file another issue after I pinpoint the underlying problem.
Oh wait, as staticlib? You currently need to make sure to link all the libraries it depends on. You can get them using .
This will fail Windows App Cert Kit tests. !
In that case I'm surprised that lazy loading worked.
WG-prioritization assigning priority (). label -I-prioritize +P-low
Change:
let types_a = substs_a.types.get_slice(subst::TypeSpace); let types_b = substs_b.types.get_slice(subst::TypeSpace); <del> let pairs = types_a.iter().zip(types_b.iter()); </del> <ins> let mut pairs = types_a.iter().zip(types_b.iter()); </ins> pairs.all(|(&a, &b)| same_type(a, b)) }

Discussion:
One of the methods takes , the other takes , which is strange, since they are almost exactly the same code. I'm guessing that should take , like does.
cc
isn't this because consumes the iterator completely and only up to the first occurrence?
both iterators behave the same way, stops at the first value, stops at the first value.
Thanks for the report, This was a mistake, and both should take precisely to clarify the consumption semantics. This should be a trivial fix.
(Should be flagged 1.0-beta P-backcompat-libs)
0 beta, P-backcompat-libs.
Change:
<ins> fn main() {} const FOO: [u8; 3] = { //~ ERROR this code is interpreted as a block expression 1, 2, 3 }; const BAR: [&str; 3] = {"one", "two", "three"}; //~^ ERROR this code is interpreted as a block expression fn foo() { {1, 2, 3}; //~^ ERROR this code is interpreted as a block expression } fn bar() { 1, 2, 3 //~ ERROR expected one of } </ins>

Discussion:
I ended up spending way too much time debugging the following error, since I was trying to port some C code to rust. Give the error: The error message is very vague and hard to determine the actual error here. Seeing as though some programming languages like Java and C use for arrays, I think it'd make sense for the compiler to suggest using if the user is trying to create an array. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I suppose adding manual diagnostic somewhere around will get the job done. claim
Change:
temp_dir: PathBuf, image_dir: PathBuf, overlay_dir: PathBuf, <ins> bulk_dirs: Vec<PathBuf>, </ins> include_target_in_component_name: bool, is_preview: bool,

Discussion:
CC On today's git () seems to get stuck if you are building docs. In : will get stuck at: The underlying command is: Adding this to the config seems to work around the hang: Thanks!
How long did you let the command run before killing it? I remember installing the docs taking a long time last time I did it.
I left it for half an hour or so IIRC. I'll run it for longer and see if it goes away. How long do you think it should take to install on a modern SSD?
I don't remember exactly how long it takes, but it doesn't depend on the speed of the disk. is just really inefficient. You can see if it's actually hanging by checking the contents of this command while it's installing:
The log file is empty, but I can see new files appearing on the disk (using and ) so progress must be occurring. Slowly.
It's been about 40 minutes now. It seems to be adding files to is that right?
So it's just very slow.
I took a look into this. The main issue is that the generated is very inefficient; it takes about 5 minutes to copy 2500 files (there are more than 2500, but I got bored and cancelled it). what do you think about rewriting this inner loop in Rust so it's not launching so many external processes?
This issue is compounded on macOS, where it seems to be even more inefficient to launch lots of processes from a shell. Sorry I don't have timings, but it takes tens of minutes at least for this step [edit: over an hour]; long enough that I would expect most users who are trying to build our software from source in macOS (it's Zcash, which installs a pinned version of Rust in order to build) are likely to think it's hanging and give up.
I think the problem may largely be that the generated for rust-docs component (at least) is a file: list instead of using the directory: command; directory commands should be much more efficient. This change may be a recent(ish) regression; I suspect that fixing that is likely the right solution here.
Oops I forgot to link back here: we discussed this briefly and it was difficult to do in a cross-platform way.
We solved our problem for Zcash by just not installing rust-docs (passing to ).

This reduced our total build time on macOS ! Obviously it doesn't solve the underlying issue.
FYI, addresses this (not the underlying cause of the inefficiency but the majority of its extent).
I bisected the underlying issue to “bootstrap: convert rust-docs to use Tarball” (). Before this commit, rust-docs installs in half a second, and is 1 line: After this commit, rust-docs installs in some twenty minutes, and is lines:
Proposed fix in . (We should also do the optimization in rust-lang/rust-installer of course.)
Change:
<ins> fn main() { 0: u8<e<5>=e> //~^ ERROR: cannot find type `e` in this scope [E0412] //~| ERROR: associated type bindings are not allowed here [E0229] //~| ERROR: mismatched types [E0308] } </ins>

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting another error, so low priority. Affected versions: I tried nightly 2021-11-25 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 --
I will give this a try claim
Change:
<ins> warning: `[PrivateType]` public documentation for `public_item` links to a private item --> $DIR/issue-74134.rs:19:10 | LL |     /// [`PrivateType`] |          ^^^^^^^^^^^^^ this item is private | = note: `#[warn(intra_doc_link_resolution_failure)]` on by default warning: 1 warning emitted </ins>

Discussion:
With merged (current nightly, e.g. ) , the following code now produces a warning: This triggers : But rustdoc never actually generates any links to , because it wasn't run with . In my opinion it shouldn't emit warning in this case, because documenting the internals can be very useful to contributors or even future me when is used. There has already been some discussion at the end of , which is where I asked first about whether this change was intentional.
modify labels: T-rustdoc A-intra-doc-links
Assuming the consensus is that rustdoc shouldn't warn in this case, would an additional check against the 's visibility be correct? Like: That certainly gets rid of the warning in my case, but I'm unsure about the other variants of and all the other kinds of things can refer to.
That looks reasonable to me. Could you make a PR with that change and a few test cases?
Wouldn't the check like I changed it then only catch cases like this: But that already triggers anyway:
the link is entirely separate from the type of the field. You could have in which case there would be no error but the warning should still be generated.
Ah, yes of course, thanks for pointing that out :) I'll open a PR then.
Change:
) .fold_with(&mut collector); <del> debug_assert_ne!( collector.types.len(), 0, "expect >1 RPITITs in call to `collect_return_position_impl_trait_in_trait_tys`" ); </del> <ins> if !unnormalized_trait_sig.output().references_error() { debug_assert_ne!( collector.types.len(), 0, "expect >1 RPITITs in call to `collect_return_position_impl_trait_in_trait_tys`" ); } </ins> let trait_sig = ocx.normalize(&norm_cause, param_env, unnormalized_trait_sig); trait_sig.error_reported()?;

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
Probably just need to suppress this assertion if the signature of the trait references . This could use a good explanation for why we ICE, though.
Ohh I've just pushed a fix and now read your comment. Your idea is better.
Change:
} } <ins> impl<T, A> Drop for Box<T, A> { fn drop(&mut self) { unsafe { libc::free(self.0.0.as_ptr() as *mut c_void); } } } </ins> #[lang = "exchange_malloc"] unsafe fn allocate(size: usize, _align: usize) -> *mut u8 { <del> let p = libc::malloc(size as libc::size_t) as *mut u8; </del> <ins> let p = libc::malloc(size) as *mut u8; </ins> // Check if `malloc` failed: <del> if p as usize == 0 { </del> <ins> if p.is_null() { </ins> intrinsics::abort(); } p } <del> impl<T> Drop for Box<T> { fn drop(&mut self) { libc::free(self.0.0.0 as *mut libc::c_void) } } </del> #[start] fn main(_argc: isize, _argv: *const *const u8) -> isize { let _x = Box::new(1);

Discussion:
or The examples don't compile and the list of items is outdated. Should the list at the bottom of the page still be updated? The amount of language items has grown and there's already a list . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim label: +A-lang-item
I think linking to the source code is better than trying to keep the list up to date, yes. We might still want to document the language items that are required for a binary, since those are "user facing" in a way the others aren't.
Ideally we could find a way to run rustdoc on the examples (as doctests) so they don't get outdated.
The guidance could be to the nomicon because there's already .
Change:
crate fn schedule_drop_for_binding(&mut self, var: HirId, span: Span, for_guard: ForGuard) { let local_id = self.var_local_id(var, for_guard); <del> let region_scope = self.region_scope_tree.var_scope(var.local_id); self.schedule_drop(span, region_scope, local_id, DropKind::Value); </del> <ins> if let Some(region_scope) = self.region_scope_tree.var_scope(var.local_id) { self.schedule_drop(span, region_scope, local_id, DropKind::Value); } </ins> } /// Visit all of the primary bindings in a patterns, that is, visit the

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I was just looking at the parsing code for const generic exprs.. claim
actually, so this isn't related to incorrectly parsing , since we're parsing in expr position to allow if-let chains.. -- this is due to const eval lowering to MIR and the fact that const generic parameters have no enclosing scope. Adding around the generic args works, but I don't know where exactly to hack in a scope for these params. release-assignment label A-const-eval A-mir
Maybe fixing this also fixes :slightlysmilingface:
This gives an error without ICE in 1.55
It was unclear to me - I think meant that changing to gives a compile error instead of an ICE. So the proper fix here is probably to add somewhere instead of panicking.
Then this should be easy. claim
Change:
<del> use super::combine::{CombineFields, RelationDir, const_unification_error}; </del> <ins> use super::combine::{CombineFields, RelationDir}; </ins> use super::Subtype; use crate::hir::def_id::DefId; <del> use crate::ty::{self, Ty, TyCtxt, InferConst}; </del> <ins> use crate::ty::{self, Ty, TyCtxt}; </ins> use crate::ty::TyVar; use crate::ty::subst::SubstsRef; use crate::ty::relate::{self, Relate, RelateResult, TypeRelation}; <del> use crate::mir::interpret::ConstValue; use crate::infer::unify_key::replace_if_possible; </del> /// Ensures `a` is made equal to `b`. Returns `a` on success. pub struct Equate<'combine, 'infcx, 'tcx> {

Discussion:
<short summary of the bugI tried this code: I expected to see this happen: It should build. Instead, this happened: rustc crashed with: Possible workaround: replace with . playground: rustc version: 1.39.0-nightly 2019-09-15
cc
Also ICEs without explicit feature gate enabled :/
Change:
PatKind::Lit(ref value) => self.lower_lit(value), PatKind::Range(ref lo_expr, ref hi_expr, end) => { <del> match (self.lower_lit(lo_expr), self.lower_lit(hi_expr)) { (PatternKind::Constant { value: lo }, PatternKind::Constant { value: hi }) => { </del> <ins> match ( // Look for `PatternKind::Constant` patterns inside of any // `PatternKind::AscribeUserType` patterns. Type ascriptions can be safely // ignored for the purposes of lowering a range correctly - these are checked // elsewhere for well-formedness. self.lower_lit(lo_expr).with_user_type_ascription_subpattern(), self.lower_lit(hi_expr).with_user_type_ascription_subpattern(), ) { (PatternKind::Constant { value: lo }, PatternKind::Constant { value: hi }) => { </ins> use std::cmp::Ordering; let cmp = compare_const_vals( self.tcx,

Discussion:
This code demonstrates the problem (): With stable-1.32.0 it prints . With beta-1.33.0 it wrongly prints . Beta also produces these wrong warnings: It seems that Rustc decides, that the first arm covers the whole range of a and optimizes out the other arms before they even reach MIR. The code is very similar to this . But the testcase does not test that the other arms can be reached. I was able to bisect the regression to . (This issue seems similar to , but the reduced testcase there does not use any associated consts)
Not the same as
triage: P-high, A-NLL, NLL-complete, assigning to self.
cc
I have confirmed that the bug appears to be specifically injected by commit (I've skimmed over that commit several times and still can't see the problem, but I'm going to try again now. Maybe the actual issue is that we are miscompiling downstream, but that pattern is not sufficiently exercised elsewhere in the compiler today...)
Well this is making my spidey-sense tingle: but even when that returns false, it seems like that would only imply that we fall through to presumably more general purpose code here: (still looking. Going to add a bit of instrumentation to these parts of the compiler.)
I don't mean to step on any toes, but I looked into this a little as an earlier PR of mine introduced it. I've got a fix up at but if that's not the approach we want to take then I can leave this to you.