jiebi/CodeConvo huggingface dataset:
Change:
} set(&mut config.ninja, llvm.ninja); llvm_assertions = llvm.assertions; <ins> llvm_skip_rebuild = llvm.skip_rebuild; </ins> set(&mut config.llvm_optimize, llvm.optimize); set(&mut config.llvm_thin_lto, llvm.thin_lto); set(&mut config.llvm_release_debuginfo, llvm.release_debuginfo);

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:
) else { continue; }; <ins> // Make sure we select the same method that we started with... if Some(method.def_id) != self.typeck_results.borrow().type_dependent_def_id(parent_expr.hir_id) { continue; } </ins> let ideal_rcvr_ty = rcvr_ty.fold_with(&mut fudger); let ideal_method = self

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. --Hello, I am sorry, but I wasn't able to reproduce the bug outside my company's project (proprietary and which I don't have the permission to share), so I can't really help here. Code like this resides in proc-macro transformed function ( from leptos) and inside recursivelly calling macro. Here is how approximately it looks: <!-- 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. --Fails on both nightly and stable, backtrace if from nightly. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsHope this helps and thank for your work.
Relabeling issues which don't have a runnable reproduction (as opposed to not having a minimized one) to the new label S-needs-repro. label +S-needs-repro -E-needs-mcve
I think I encountered the same bug. A minimal example is below. I think the problem is a lookup, which includes the unimplemented trait without checking the length of the argument list before accessing. : Also fails on nightly. <details<summary<strongnightly ructc-</strong</summary<p</p</details
Maybe inside rollup ? cc
I ran into this ICE and minimized my case to the following reproducer. Its slightly different way to get to the same case as 's code above. Still happens from stable 1.77.2 to nightly 2024-04-19. When doing a bisection I get nightly-2023-05-16.
Change:
} html::push_html(&mut ret, content.into_iter()); write!(ret, <del> "&nbsp;<a href="#supref{}" rev="footnote">↩</a>", </del> <ins> "&nbsp;<a href="#fnref{}" rev="footnote">↩</a>", </ins> id).unwrap(); if is_paragraph { ret.push_str("</p>");

Discussion:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes
Change:
use std::iter; <del> // CHECK: @helper([[USIZE:i[0-9]+]] %_1) #[no_mangle] pub fn helper(_: usize) { } </del> // CHECK-LABEL: @repeat_take_collect #[no_mangle] pub fn repeat_take_collect() -> Vec<u8> { <del> // CHECK: call void @llvm.memset.p0i8.[[USIZE]](i8* {{(nonnull )?}}align 1{{.*}} %{{[0-9]+}}, i8 42, [[USIZE]] 100000, i1 false) </del> <ins> // CHECK: call void @llvm.memset.p0i8.i{{[0-9]+}}(i8* {{(nonnull )?}}align 1{{.*}} %{{[0-9]+}}, i8 42, i{{[0-9]+}} 100000, i1 false) </ins> iter::repeat(42).take(100000).collect() }

Discussion:
In , we document more precisely the rules for the various methods that can be used to access memory through raw pointers. In particular, we clarify that the pointer must be non-NULL and aligned even when the access has size 0. This issue is about helping people find bugs in libstd by adding a to all these methods testing that condition, similar to what I did . I suggest to add a helper method to raw pointers to test this, and also use that for and . This may uncover issues in libstd, uncovering misuses of these methods. Those should then be fixed.
I might be interested in working on that. Could you help me with a starting point for that?
You might want to start with It could get a check similar to To avoid code duplication, consider adding a (private) helper method in for this purpose, and using it in both the old places () and . Other candidates besides are and . We could also go further, but maybe we should involve the libs team there... so let's get started with these 3.
Sorry for the delay, it took me a while to free up some time. Quick questions: I found in However, one is just a delegation to the intrinsic, and the other one is for , which is just a call to the previous one. Should I hunt the intrinsic in the C code, or provide a rust wrapper that will check the assumptions and call the intrinsic? I couldn't find a in The only ones I could find were for , , and in . Am I missing something?
Ah, intrinsics are still written in Rust, but as code generation functions. Well, I guess adding debug assertions everywhere in the intrinsics would be counter-productive, so we're going for the wrapper? Although, I'm not sure how to cleanly hijack the interface: I have to keep using the same function name for the callers, so that I don't have to change their code, but unless I don't understand how it works, I also need to have the same signature including the function name for the code generation. How should I proceed?
Ah good point, I forgot about these reexports. I think the right way forward is to replace by a wrapper function that just calls the intrinsic. The docs should be moved from to . That move should be a total NOP.

The, in the 2nd step, you can add the in the delegating wrapper you just . Sorry, I meant the one in . It already has a , but that does not test as much as it could (i.e., it accepts NULL).
Congrats, your patch landed. :) So with the preparation out of the way, let me know if you need any help with adding the debug assertions.
Thanks! I should be okay, I just need to find the time :) I'll ping you when it's ready for review.
Cc
Change:
<del> Subproject commit 7ef40979157b4117faa52bbe79ec144ebd45b0e3 </del> <ins> Subproject commit e276676f0c0fc16f41e46cc56cb7a9362dc717b0 </ins>

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.
Miri-side fix:
Could we resolve this by updating Miri?
Right now, no, because and I am not sure what.
Oh, I missed
Breakage is likely caused by
Submitted fix:
The fixes landed?
It did, yes. There are some PRs under review on the rustc side that would break Miri again, but if you want you can update Miri so we'll get one or two nightlies with newer versions. Btw, for using Miri on CI or so, I recommend a snippet such as: This way you'll get a working Miri even if the latest nightly does not have one.
(In case you open a PR, please Cc/r? me. I won't see it otherwise.)
Change:
let mut check_overflow = attrs.iter() .any(|item| item.check_name("rustc_inherit_overflow_checks")); <del> // Respect -Z force-overflow-checks=on and -C debug-assertions. check_overflow |= infcx.tcx .sess .opts .debugging_opts .force_overflow_checks .unwrap_or(infcx.tcx.sess.opts.debug_assertions); </del> <ins> // Respect -C overflow-checks. check_overflow |= infcx.tcx.sess.overflow_checks(); </ins> // Constants and const fn's always need overflow checks. check_overflow |= constness == hir::Constness::Const;

Discussion:
Tracking issue for
FWIW this should be a relatively easy bug to knock out! The option is and we'd just want to add a new flag to the (we'll delete the flag once everyone's migrated). There's a few uses throughout the codebase which I believe will need an update:    After that we'd just need to add a test which validates this behavior, likely a addition with a annotation at the top. Likewise the Cargo support should be relatively easy:
I'd like to tackle this!
OK, so this is pretty straightforward. Couple questions after actually implementing this: The RFC says the option is , but comments on the RFC suggest that people expect this to be , so one could have (I guess) . Which variant should be supported? It seems better to make the value in the single source of truth to be used throughout the compiler by setting it based on the value of or ; this makes the uses easier to read and also makes any future removal of straightforward. How should interact with ? Should we just consider any explicit setting of to "win" and only consult if the option was not explicitly provided? I guess that would mean that we'd almost have to implement the variant above?
I think it's fine to just reuse the existing  which accepts a "standard variety" of boolean options. Makes sense to me to have a single source of truth! Right now I don't think we have a lot of precedent for modifying after creation so this may not be easy. Perhaps a helper method on though? That's what a . Yeah let's just have trump . The precise semantics likely don't matter too much anyway as we'll quickly phase out the version anyway.
Change:
[[package]] name = "hashbrown" <del> version = "0.3.0" </del> <ins> version = "0.4.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "compiler_builtins 0.1.15 (registry+https://github.com/rust-lang/crates.io-index)",

Discussion:
In 1.35, 's requires , but in 1.36-beta it requires . Both are auto-derived, so it must be a change in their internals. Obviously, is quite different than the old implementation. ! ! Ditto for . I'm not sure if there's any real impact in this, but it should be considered, and perhaps audit for other similar changes. cc as discussed on IRC.
This is fixed in hashbrown 0.4.0.
Shouldn't be fixed as well?
Since is actually based on , it derives the same constraints.
Ah, gotcha. Thanks! Sorry for the false alarm :).
I think it would be a good idea to add a run-pass to check that these auto-trait impls don't change again.
might make sense to add them as tests to most collections. , , etc. don't have tests for these either. I've made this error in some of my collections (changing some internal implementation detail and breaking users that rely on auto traits working "like before").
Change:
($fmt:expr, $($args:tt)*) => {{ /* compiler built-in */ }}; } <del> /// Same as `format_args`, but adds a newline in the end. </del> <ins> /// Same as [`format_args`], but adds a newline in the end. </ins> #[unstable( feature = "format_args_nl", issue = "none",

Discussion:
Initial title: formatargsnl! should link to formatargs! where they mention it currently contains: It would be nicer as: … although I also find which made it . It looks like that was undone at some point? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It seems that is removed in
claim
Was it intentional, though? The PR description says But that does not apply to which has: CC
After some discussion in that PR, it was deemed that a macro being did not warrant, on its own, marking the macro as . Hence why a bunch of such macros were unhidden by that PR, but maybe shouldn't have been part of those? I really don't have a strong opinion here myself, so lemme wash my hands , but: on the one hand, I do lean towards not hiding, in general, some of these macros since it may reduce a bit too much their the other hand, I'll grant that there is a difference, alas quite subtle / currently hard-to-express, between -and-expected-to-eventually-be-stabilized, and perma-; for the latter it seems more legitimate to mark them as . Given the description of the unstability of , it seems like it's the latter?
“On its own” is important here. is used for two categories of APIs: Those that are not stable yet, but have a tracking issue and might become stable at some point The "perma-unstable" APIs, that ideally should be private to a crate but need to be public typically to let some other standard library crate use them. I think that depending on its category each item with should either point to a tracking issue, or be . Here “only for internal language use” seems to point to the latter.
Yeah, I share the feeling: AFAIC, feel free to go and make it again then
One potential argument against hiding the macro from the docs is that it shows up in the compiler errors originating from the use of format strings (i.e. "note: this error originates in the macro "). Having it surfaced to the user this way but hidden from the docs might not be great.

This is being stabilized in , so I think the answer is pretty clearly "no" now (but the discussion here is interesting for other perma-unstable macros).
Change:
Ok(OpTy { op, layout: place.layout }) } <del> // Evaluate a place with the goal of reading from it.  This lets us sometimes // avoid allocations. </del> <ins> /// Evaluate a place with the goal of reading from it.  This lets us sometimes /// avoid allocations. </ins> pub fn eval_place_to_op( &self, place: mir::Place<'tcx>,

Discussion:
Hello, It feels like this shouldn't be an issue but I don't really know where to post it otherwise.. says that there is a more efficient solution when the place is access for read called , but the latter does not exist anywhere. I'm guessing it should be referring to , but I am not entirely sure. Also as a side question, I'd be curious to know why it is slower to access a place for write than it is for read. I'm going to spend a bit of time reading that part of the code, if I ever find other tiny things like that, where should I report it ? It feels like this could be a small discussion in a chat followed by a tiny PR rather than an issue. Thank you ! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If you have a question while making a PR, on good resource is Zulip: https://rust- Depending how easy a PR it is and whether you're reasonably confident in your deduction, you could also just make a PR changing it and the reviewer will confirm that the update is accurate.
Your analysis looks correct to me. I'm working up a PR to fix these docs. claim
Issues like this are welcome, as are small PRs. :)
Change:
install_sh(&build, "docs", "rust-docs", stage, host, &prefix, &docdir, &libdir, &mandir, &empty_dir); } <ins> for target in build.config.target.iter() { install_sh(&build, "std", "rust-std", stage, target, &prefix, &docdir, &libdir, &mandir, &empty_dir); } </ins> if build.config.rust_save_analysis { install_sh(&build, "analysis", "rust-analysis", stage, host, &prefix, &docdir, &libdir, &mandir, &empty_dir); } <del> install_sh(&build, "std", "rust-std", stage, host, &prefix, &docdir, &libdir, &mandir, &empty_dir); </del> install_sh(&build, "rustc", "rustc", stage, host, &prefix, &docdir, &libdir, &mandir, &empty_dir); t!(fs::remove_dir_all(&empty_dir));

Discussion:
Hi. I am testing out rust 1.15.0 beta and I came across a problem installing from source: Debian GNU/Linux 8 x8664 (1.15.0-beta.5) and directories in . Only the directory is present. I am new to rust (just a couple of days) so forgive me if I've overlooked something. I'm pretty sure I installed 1.14.0 similarly and was installed OK. That was using the old makefiles-based build system.
IIRC this hasn't ever worked, but would be a great bug to fix with rustbuild!
I've made a fix to this issue, you just need to apply this patch: This will check the structure for the targets provided on the stage, it will then remove any target that is equal to the host (since the host will already be installed) and call the install function on it resulting in the installation of all the for all the targets. I don't know if this is the best approach or if there is some case that will fail and I'm not aware. But, if it is a ok patch, can we apply it to the next version of rust since it seems that this is a major problem for a lot of users (at least for me it is since I'm trying to make the rust ebuild for gentoo support multiple targets and this bug is just what is preventing me). Thanks
looks like a great start to me, you're more than welcome to send a PR! I think that we'llalso want to update for the new dependencies, but other than that look great to me.
I believe this is fixed now that landed, closing. Please let me know if I'm wrong though!
Change:
let projection_bounds: SmallVec<[_; 4]> = trait_data .projection_bounds() .map(|bound| { <del> let ExistentialProjection { item_def_id, term, .. } = bound.skip_binder(); </del> <ins> let ExistentialProjection { item_def_id, term, .. } = tcx.erase_late_bound_regions(bound); </ins> // FIXME(associated_const_equality): allow for consts here (item_def_id, term.ty().unwrap()) })

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. -- rust- <!-- 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 --
works fine, but crashes with ICE.
This is probably a duplicate of .
My guess is this is caused by . Specifically cc
(That might not be the cause though)
No, you're probably right I'll either erase regions during candidate assembly or use something infcx-local to probe if something is Copy. claim
Compiling with debug assertions on should be able to pinpoint exactly where things go wrong.
Bisecting this lead to though cc
Actually, I do agree that this is probably not due to . I can still fix this though, unless you're gonna take a look at it?
feel free to take a look. might be relevant here too (although it does look like a different problem).
Welp sorry
For either of the two Michaels looking at this: big thanks to for the from . ()
Here's a minimization I left on a duplicate issue: Note that without this does not ICE.
Marking as P-critical, since this seems to be getting hit by several people.
Also changing title and pinning to try to help curb some duplicates.
any solution!, I am still facing same error when i try to build
No, the PR that fixes this is blocked on a CI issue, which will not likely be resolved until tomorrow at this rate. You may find a temporary fix by downloading an old nightly revision with (e.g.) and setting that as your default for the time being, but please make sure to set it back later. Or, if your project does not use any nightly-only features, I recommend using or releases for now.
Thanks!
Same error!

thread 'rustc' panicked at 'assertion failed: !value.hasescapingboundvars()', /rustc/compilerrustcmiddlesrcty note: rustc 1.61.0-nightly ( 2022-03-16) running on x86_64-pc-windows-msvc note: compiler flags: --crate-type lib -C embed-bitcode=no -C debuginfo=2
Pinning this at least for a day or so, since the nightly with the fix hasn't even been released.
Change:
}, } } <ins> // If we see a const here, that's because it evaluates to a type with zero size. We // should be able to just discard it, since const expressions are guaranteed not to // have side effects. This seems to be reached through tuple struct constructors being // passed zero-size constants. if let hir::ExprPath(..) = expr.node { match bcx.def(expr.id) { Def::Const(_) | Def::AssociatedConst(_) => { assert!(type_is_zero_size(bcx.ccx(), bcx.tcx().node_id_to_type(expr.id))); return bcx; } _ => {} } } </ins> // Even if we don't have a value to emit, and the expression // doesn't have any side-effects, we still have to translate the // body of any closures.

Discussion:
The following code produces an internal compiler error when compiled with rustc 1.8.0-nightly (2016-01-27) through the Rust playground: Here's a sample of the error output from the playground: The error occurs regardless of the type of the array's elements. The error seems to be related to the type of array constructor used, since the following code compiles just fine: The error does not occur when associated constants are not involved: Now with backtrace!
Change:
#![feature(unsafe_no_drop_flag, filling_drop)] #![feature(unsize)] #![feature(core_slice_ext)] <ins> #![feature(core_str_ext)] </ins> #![cfg_attr(test, feature(test, alloc, rustc_private, box_raw))] #![cfg_attr(all(not(feature = "external_funcs"), not(feature = "external_crate")),

Discussion:
Just like , Clone is also wanted for , but that can be much simpler: There is no panic issue, and it can use a simple ptr::copy of the data. Follow up after
Change:
"identifier `{}` is bound more than once in the same pattern", identifier) } <del> ResolutionError::StaticVariableReference => { struct_span_err!(resolver.session, span, E0417, "static variables cannot be referenced in a pattern, use a  `const` instead") </del> <ins> ResolutionError::StaticVariableReference(did, name) => { let mut err = struct_span_err!(resolver.session, span, E0417, "static variables cannot be referenced in a  pattern, use a `const` instead"); if let Some(sp) = resolver.ast_map.span_if_local(did) { err.span_note(sp, "static variable defined here"); } if let Some(name) = name { if let Some(binding) = resolver.current_module .resolve_name_in_lexical_scope(name, ValueNS) { if binding.is_import() { err.span_note(binding.span, "static variable imported here"); } } } err </ins> } ResolutionError::NotAnEnumVariantStructOrConst(name) => { struct_span_err!(resolver.session,

Discussion:
Rustc version: rustc 1.0.0-nightly ( 2015-03-22) (built 2015-03-23)
Hmm, I am not sure if this is a bug or not. I can see it both ways.
As I understand, this error is related to the situation like this