jiebi/CodeConvo huggingface dataset:
Change:
} }; <del> let mut suggest_deref_binop = |lhs_deref_ty: Ty<'tcx>| { if self .lookup_op_method( lhs_deref_ty, Some((rhs_expr, rhs_ty)), Op::Binary(op, is_assign), expected, ) .is_ok() { let msg = format!( "`{}{}` can be used on `{}` if you dereference the left-hand side", op.node.as_str(), match is_assign { IsAssign::Yes => "=", IsAssign::No => "", }, lhs_deref_ty, ); err.span_suggestion_verbose( lhs_expr.span.shrink_to_lo(), msg, "*", rustc_errors::Applicability::MachineApplicable, ); } }; </del> <ins> let suggest_deref_binop = |err: &mut DiagnosticBuilder<'_, _>, lhs_deref_ty: Ty<'tcx>| { if self .lookup_op_method( lhs_deref_ty, Some((rhs_expr, rhs_ty)), Op::Binary(op, is_assign), expected, ) .is_ok() { let msg = format!( "`{}{}` can be used on `{}` if you dereference the left-hand side", op.node.as_str(), match is_assign { IsAssign::Yes => "=", IsAssign::No => "", }, lhs_deref_ty, ); err.span_suggestion_verbose( lhs_expr.span.shrink_to_lo(), msg, "*", rustc_errors::Applicability::MachineApplicable, ); } }; let suggest_different_borrow = |err: &mut DiagnosticBuilder<'_, _>, lhs_adjusted_ty, lhs_new_mutbl: Option<ast::Mutability>, rhs_adjusted_ty, rhs_new_mutbl: Option<ast::Mutability>| { if self .lookup_op_method( lhs_adjusted_ty, Some((rhs_expr, rhs_adjusted_ty)), Op::Binary(op, is_assign), expected, ) .is_ok() { let op_str = op.node.as_str(); err.note(format!("an implementation for `{lhs_adjusted_ty} {op_str} {rhs_adjusted_ty}` exists")); if let Some(lhs_new_mutbl) = lhs_new_mutbl && let Some(rhs_new_mutbl) = rhs_new_mutbl && lhs_new_mutbl.is_not() && rhs_new_mutbl.is_not() { err.multipart_suggestion_verbose( "consider reborrowing both sides", vec![ (lhs_expr.span.shrink_to_lo(), "&*".to_string()), (rhs_expr.span.shrink_to_lo(), "&*".to_string()) ], rustc_errors::Applicability::MachineApplicable, ); } else { let mut suggest_new_borrow = |new_mutbl: ast::Mutability, sp: Span| { // Can reborrow (&mut -> &) if new_mutbl.is_not() { err.span_suggestion_verbose( sp.shrink_to_lo(), "consider reborrowing this side", "&*", rustc_errors::Applicability::MachineApplicable, ); // Works on &mut but have & } else { err.span_help( sp, "consider making this expression a mutable borrow", ); } }; if let Some(lhs_new_mutbl) = lhs_new_mutbl { suggest_new_borrow(lhs_new_mutbl, lhs_expr.span); } if let Some(rhs_new_mutbl) = rhs_new_mutbl { suggest_new_borrow(rhs_new_mutbl, rhs_expr.span); } } } }; </ins> let is_compatible_after_call = |lhs_ty, rhs_ty| { self.lookup_op_method(

Discussion:
Finally getting around to filing this issue at encouragement in this (rather embarrassing) . CC and I've tried to capture things in ; to summarize: It seems like this should generally be a valid suggestion, and we have to create a diagnostic for this; current error output doesn't help the user to discover the "right" solution at all. No response No response
Hi Erich, thanks for tagging me :) Took me a couple of minutes to refresh my memory :sweatsmile: but glad to see there is something positive coming from that thread :) Should the suggested help-message not read: Since we're not just adding a but rather a ?
I think your point is valid. Edited!
Whoot whoot!
Change:
<ins> #![allow(incomplete_features)] #![feature(generic_const_exprs)] struct ConstAssert<const COND: bool>; trait True {} impl True for ConstAssert<true> {} struct Range<T: PartialOrd, const MIN: T, const MAX: T>(T) //~^ ERROR the type of const parameters must not depend on other generic parameters //~| ERROR the type of const parameters must not depend on other generic parameters where ConstAssert<{ MIN <= MAX }>: True; fn main() {} </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. --: Also tested on the playground: . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details modify labels: +A-const-generics +F-genericconstexprs +requires-nightly
Change:
<del> // Copyright 2012 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: mismatched types enum color { red = 1u, blue = 2, } fn main() {} </del>

Discussion:
Currently, the following fails to compile, with errors about expecting int instead of uint: Is there any reason why this should be disallowed?
Linking to issue
Fixed by
Change:
<del> // ARM Cortex-M are a class of processors supported by the rust compiler. However, // they cannot support any atomic features, such as Arc. This test simply prints // the configuration details of one Cortex target, and checks that the compiler // does not falsely list atomic support. // See https://github.com/rust-lang/rust/pull/36874 </del> <ins> // ARM Cortex-M are a class of processors supported by the rust compiler. However, they cannot // support any atomic features, such as Arc. This test simply prints the configuration details of // one Cortex target, and checks that the compiler does not falsely list atomic support. // See <https://github.com/rust-lang/rust/pull/36874>. // ignore-tidy-linelength //@ needs-llvm-components: arm // Note: without the needs-llvm-components it will fail on LLVM built without all of the components // listed above. If any new targets are added, please double-check their respective llvm components // are specified above. </ins> use run_make_support::rustc;

Discussion:
Tests doing codegen for specific targets need directives. These are the tests that are currently missing the directives and failing if LLVM is built without various aarch64/arm/thumb components or wasm. [ ] testsrun-makeprint-target-list [ ] testsrun-makeprint-to-output [ ] testsrun-makeprint-cfg [ ] testsrun-maketarget-without-atomic-cas Originally posted by in
E.g. for this looks a bit awkward, maybe we can dump , where is shamelessly stolen from tidy: Between this directive and , it is not exactly very clear what's happening.

In noticed was failing for (and other experimental llvm components) on the CI builder with (specifically ) it was already noticed that seemed to fail for . Is this expected? Or what is the expected test behavior when is ran (on the CI builder)? Or is it expected that we should skip trying to run this check for the and other experimental llvm component targets? Update: this is also true for experimental llvm components , , and , not too sure what the correct behavior is. Currently these targets are skipped by 's check.
Is there any COMPILETESTNEEDSALLLLVMCOMPONENTS set by us for this jobs?. It seems like the same issue. I will check it later.
Well, I'm not familiar with rmake. However, the right logic should be like: If is not set and do not have the , then we could skip it. is set at , and it is only used at now.
Ah thank you, that sounds about right.
Change:
clean::Type::Path { ref path } | clean::BorrowedRef { type_: box clean::Type::Path { ref path }, .. } => { dids.insert(path.def_id()); <ins> if let Some(generics) = path.generics() && let ty::Adt(adt, _) = self.tcx.type_of(path.def_id()).kind() && adt.is_fundamental() { for ty in generics { if let Some(did) = ty.def_id(&self.cache) { dids.insert(did); } } } </ins> } clean::DynTrait(ref bounds, _) | clean::BorrowedRef { type_: box clean::DynTrait(ref bounds, _), .. } => {

Discussion:
You'd expect the impl for the boxed type to show up, but it doesn't. I seem to recall rustdoc displays impls anytime the type is contained in the generics, though, so it's odd that it's not happening. Originally reported by (with ) .
also reported a case involving a impl that didn't show up on the trait's page. IIRC this issue is somewhat known already though.
I can't find a case where the impl is if the type is in the generics. Do you have an example maybe?
On Vec's page: !
That one's happening because of this thing. Notice that the generics on the trait count, but the generics on don't. We definitely need to fix this, specifically, for types, because that's how you wind up with impls that aren't actually documented anywhere.
Change:
// check-pass <ins> // compile-flags: --crate-type lib #![warn(unconditional_panic)] </ins> pub struct Fixed64(i64); <del> pub fn div(f: Fixed64) { f.0 / 0; </del> <ins> // HACK: this test passes only because this is a const fn that is written to metadata pub const fn div(f: Fixed64) { f.0 / 0; //~ WARN will panic at runtime </ins> } <del> fn main() {} </del>

Discussion:
UPDATE: MCVE can be found . Nightly compilation error due to rustc bug I tried this code: I expected to see this happen: explanation Successful compilation. Instead, this happened: tells to report a bug, see backtrace. : Reproduce with (1st update) <details<summaryBacktrace</summary<p</p</details
cc
Also occured with
I'm getting this when I try to repro: On a side note, are there any cargo feature flags I can pass to cut down on how much stuff is being compiled? Compiling 900 crates to get a repo is quite a lot
Also occured with just now.
mmh try with commit hash ? (for )
updated script:
Yeah, sorry for that. One of the difficulties of working with a big framework like Substrate. I'll see if I can narrow it down more.
That did it! Thank you
Some with the same issue (a different chain also using Substrate) found out that apparently works.
Seems is the cause, marking as .
Here's a smaller repro (at least in terms of how much code is built: 33 crates instead of a few hundred):
just confirmed that it does not occur with
I have a minimal repro:
Wild guess: erases the local before we are able to emit the diagnostic message.
I seem to be getting a similar error again on a more current nightly (). Should I open a new issue or do we just reopen this one?
This is still broken. I'm pretty confused because running the test you in on the shows that it ICEs. Is the test not actually working for some reason? Edit: Does that test need in order to actually check the body of those functions since they are uncalled from ?
Assigning as and removing I-prioritize.
Hi and have either of you had a chance to upgrade to a recently nightly? I just wanted to confirm this is fixed for you.
I've updated to rust version 1.47.0-nightly ( 2020-07-22), and tried compiling the crate which was triggering this ICE (). I no longer encounter an ICE, the crate compiles successfully.
I can confirm is not throwing ICE :+1:
Great, thank you!
Change:
pub fn fail_bounds_check(file: *u8, line: uint, index: uint, len: uint) -> ! { let msg = format!("index out of bounds: the len is {} but the index is {}", len as uint, index as uint); <del> msg.with_c_str(|buf| fail_(buf as *u8, file, line)) </del> <ins> let file_str = match unsafe { CString::new(file as *c_char, false) }.as_str() { // This transmute is safe because `file` is always stored in rodata. Some(s) => unsafe { cast::transmute::<&str, &'static str>(s) }, None    => "file wasn't UTF-8 safe" }; ::rt::begin_unwind(msg, file_str, line) </ins> } #[lang="malloc"]

Discussion:
creates an error string dynamically, then passes it as an unsafe pointer to , which then casts the string to , then to , then throws it to another task. Nominating.
Change:
pub struct Std { pub stage: u32, pub target: TargetSelection, <ins> pub format: DocumentationFormat, </ins> } impl Step for Std {

Discussion:
running only builds the html doc, but builds the json doc. I expected the json flag to act as the documentation says (): using the master branch of this repo commit running with a library profile.
I can't reproduce this. The files show up for me in .
Seems to reproduce, I could totally have overlooked a step tho
oh no it's even simpler than that lol it's calling the wrong function that should be JsonStd, not Std
Should I make the PR or are you gonna do it ?
If you could make a PR that would be great :)
Made the PR but since just changing the ensure wasn't enough there's a thing I'm unsure about (tested it, worked, but could be cleaner)
Change:
<ins> #![feature(const_let)] static mut STDERR_BUFFER_SPACE: u8 = 0; pub static mut STDERR_BUFFER: () = unsafe { *(&mut STDERR_BUFFER_SPACE) = 42; }; //~^ ERROR references in statics may only refer to immutable values //~| ERROR static contains unimplemented expression type fn main() {} </ins>

Discussion:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.
Change:
Callee { bcx: bcx, data: Fn(llfn) } } traits::VtableObject(ref data) => { <del> let llfn = trans_object_shim(bcx.ccx(), data.object_ty, trait_id, n_method); </del> <ins> let (llfn, _) = trans_object_shim(bcx.ccx(), data.object_ty, trait_id, n_method); </ins> Callee { bcx: bcx, data: Fn(llfn) } } traits::VtableBuiltin(..) |

Discussion:
Discovered this ICE in the rollup that I'm preparing:
In Grust, I tried to change to: The crate compiles without an issue, but compiling another crate where this is used results in an ICE that looks to be this one.
Looks like I missed a case in
Nominating for 1.0 beta.
Are there any known workarounds for this problem? I ran into this in a hard way trying to update to the newest nightlies.
not sure, I'll try to get a PR up today
a new type wrapper around the object would probably work, ping me on irc () for more details
I just wanna run iron example on MAC 10.10 with rust-nightly, the same error occurs, I don't know if it's of the same case: error: internal compiler error: static call to invalid vtable: VtableObject(VtableObject(object_ty=error::Error + 'static))
This is also blocking Iron, which itself compiles well, but using the crate fails:
Fix in , sorry for the delay.
thanks for the work! I pulled your PR and built with it, and my code compiles again. Hooray!
Change:
use rustc_hir::def_id::DefId; use rustc_middle::mir::{ self, <del> interpret::{uabs, ConstValue, GlobalId, InterpResult, Scalar}, </del> <ins> interpret::{ConstValue, GlobalId, InterpResult, Scalar}, </ins> BinOp, }; use rustc_middle::ty;

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for on signed integral types. The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- First implemented in <!-- Include a list of all the PRs that were involved in implementing the feature. --
Are there any outstanding issues with this feature gate? It has a trivial implementation that is unquestionably correct, and it seemed quite clear in the RFC that it was desired.
One significant issue I see is currently the implementation for returns instead of . Edit: I found the reason. The is instead of as . This was not a problem so far because didn't appear in any function signature until now. So changing the call site for all pointer sizes should be enough.
Hmm…the behavior for different widths (16, 32, or 64). However, usize and u16/32/64 are not the same type. I'll make a modification locally and open a PR shortly.
Yes, exactly. Good job with the PR!
Why of returns instead of ? IMHO, it is not valid.
This is fixed on nightly (that you need anyway to use this for now)
Nice, thank you!
Change:
bx.store_with_flags(val, dest.llval, dest.align, flags); } OperandValue::Pair(a, b) => { <del> for (i, &x) in [a, b].iter().enumerate() { let llptr = bx.struct_gep(dest.llval, i as u64); let val = base::from_immediate(bx, x); bx.store_with_flags(val, llptr, dest.align, flags); } </del> <ins> let (a_scalar, b_scalar) = match dest.layout.abi { layout::Abi::ScalarPair(ref a, ref b) => (a, b), _ => bug!("store_with_flags: invalid ScalarPair layout: {:#?}", dest.layout) }; let b_offset = a_scalar.value.size(bx).align_to(b_scalar.value.align(bx).abi); let llptr = bx.struct_gep(dest.llval, 0); let val = base::from_immediate(bx, a); let align = dest.align; bx.store_with_flags(val, llptr, align, flags); let llptr = bx.struct_gep(dest.llval, 1); let val = base::from_immediate(bx, b); let align = dest.align.restrict_for_offset(b_offset); bx.store_with_flags(val, llptr, align, flags); </ins> } } }

Discussion:
reduced from num_cpus: built with yields cc `
What’s the target? Ah, never mind, I missed that its .
More minimal: Issue does not occur on stable (or 1.30.0 nightly), but occurs on rustc beta.
Marking T-libs as that is likely to be an issue within implementation of , but I didn’t investigate further.
Excerpt: Clearly both of those adjacent i32 aren't going to be 8-byte aligned ^^ It seems that we're storing to an key with wrong alignment for some reason.
Don't need to look particularly far, this code generates It looks like some code is assuming that both elements in a scalar pair have the same alignment as the whole pair.
Probably the easiest way to get to the root cause is to bisect.
This code is very likely the culprit: It takes the 0 and 1 GEPs, but uses the same alignment, without offset adjustment.
Ouch, that's bad. To obtain the alignment for both fields, we need to do: Note that we can't use because the components do not match fields (the latter come from the user type definitions, whereas the former are extracted as an optimization).
Change:
<ins> // Regression test for #70934 struct S; fn foo() { &([S][0],); //~^ ERROR cannot move out of type `[S; 1]` } fn main() {} </ins>

Discussion:
I get an ICE when I try to build : I tried stable, beta and nightly. All ended with an ICE.
Important detail: Only happens on the branch, not
(bisecting)
It happens with master branch as well if I do before building. Without it, it fails due to nalgebra issue before it even gets to evolvim-lib.
Ah, I see
regression in nightly-2019-08-17
great :). Unsure if you're bisecting this further, anyway pinging cleanup crew in case you are not doing it further and also to see if someone is able to get an mcve. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
There don't seem to be any prebuilt artifacts for that commit range, so I've stopped there.
Assigning meanwhile we don't have an mcve as .
() Errors: modify labels to -E-needs-mcve
The reduced example regresses at nightly-2019-09-29 (..). Edit2: For me, evolvim (develop branch) regresses on that nightly, too. <br<br<details<summary<del<ttgit log</tt<iafter bisection</i</del</summary</detailsEdit3: Damn it, recompiling didn’t make realize that the code had to be recompiled and I didn’t really notice that it had just skipped compilation entirely all the time.
Even smaller: () Errors: <details</details
regression in commit (part of ) cc modify labels: -E-needs-bisection
Error: Label ICEBreaker-Cleanup-Crew can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Label ICEBreaker-Cleanup-Crew can only be set by Rust team members Please let know if you're having trouble with this bot.
Now that we have an -- thanks -- let's prioritize again
prioritize -- just testing the command
Error: This issue has already been requested for prioritization. Please let know if you're having trouble with this bot.

prioritize -- just testing the command
Looks like this compiles but it shouldn't: Dumping the MIR for this you get: Presumably, what should happen here is: The occurs here: cc
This issue is already prioritized as removing label.
I guess we need to track down where [S; 1] is emitted and make that code also look at the MIR of promoteds. We can't avoid that code from getting promoted without getting into an unfun game of whack-a-mole in the promotion code.
The error is constructed here: which is called here: and here:
hmmm... not sure what borrowck does to promoteds. I mean we basically declared all lifetimes to be static, but the same is true for the body of constants which we do run borrowck on. So... let's try to just run borrowck on promoteds and see how it goes.
alternatively we just run the logic on promoteds instead of full borrowck, as the latter may have a significant perf impact.
Change:
_ => {} } } <ins> /// Non-static lifetimes are prohibited in anonymous constants under `min_const_generics` so /// this function will emit an error if `min_const_generics` is enabled, the body identified by /// `body_id` is an anonymous constant and `lifetime_ref` is non-static. crate fn maybe_emit_forbidden_non_static_lifetime_error( &self, body_id: hir::BodyId, lifetime_ref: &'tcx hir::Lifetime, ) { let is_anon_const = matches!( self.tcx.def_kind(self.tcx.hir().body_owner_def_id(body_id)), hir::def::DefKind::AnonConst ); let is_allowed_lifetime = matches!( lifetime_ref.name, hir::LifetimeName::Implicit | hir::LifetimeName::Static | hir::LifetimeName::Underscore ); if self.tcx.features().min_const_generics && is_anon_const && !is_allowed_lifetime { feature_err( &self.tcx.sess.parse_sess, sym::const_generics, lifetime_ref.span, "a non-static lifetime is not allowed in a `const`", ) .emit(); } } </ins> }

Discussion:
Nightly on playground <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
we should forbid lifetimes in anonymous constants to avoid this issue.

results in
Could this be a duplicate of ?
:+1: This probably has the same fix. I do think that the issues are different enough to keep this one open though