jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0412]: cannot find type `PhantomData` in this scope --> $DIR/issue-77919.rs:9:9 | LL |     _n: PhantomData, |         ^^^^^^^^^^^ not found in this scope | help: consider importing this struct | LL | use std::marker::PhantomData; | error[E0412]: cannot find type `VAL` in this scope --> $DIR/issue-77919.rs:11:63 | LL | impl<N, M> TypeVal<usize> for Multiply<N, M> where N: TypeVal<VAL> {} |          -                                                    ^^^ not found in this scope |          | |          help: you might be missing a type parameter: `, VAL` error[E0046]: not all trait items implemented, missing: `VAL` --> $DIR/issue-77919.rs:11:1 | LL |     const VAL: T; |     ------------- `VAL` from trait ... LL | impl<N, M> TypeVal<usize> for Multiply<N, M> where N: TypeVal<VAL> {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `VAL` in implementation error: any use of this value will cause an error --> $DIR/issue-77919.rs:5:5 | LL |     const VAL: T; |     ^^^^^^^^^^^^^ no MIR body is available for DefId(0:7 ~ issue_77919[317d]::TypeVal::VAL) | = note: `#[deny(const_err)]` on by default error[E0080]: evaluation of constant value failed --> $DIR/issue-77919.rs:2:9 | LL |     [1; <Multiply<Five, Five>>::VAL]; |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ referenced constant has errors error: aborting due to 5 previous errors Some errors have detailed explanations: E0046, E0080, E0412. For more information about an error, try `rustc --explain E0046`. </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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Regression occurred in Rust 1.36.0 per testing in Godbolt.
Regression in nightly-2019-04-24 Range: ... found 9 bors merge commits in the specified range commit[0] 2019-04-22UTC: Auto merge of - varkor:tidy-leading-newline, r=alexcrichton commit[1] 2019-04-22UTC: Auto merge of - estebank:continue-eval, r=oli-obk commit[2] 2019-04-23UTC: Auto merge of - euclio:pulldown-cmark, r=GuillaumeGomez commit[3] 2019-04-23UTC: Auto merge of - davazp:fix-sync-all-macos, r=KodrAus commit[4] 2019-04-23UTC: Auto merge of - varkor:tidy-double-trailing-newline, r=kennytm commit[5] 2019-04-23UTC: Auto merge of - estebank:continue-evaluating, r=oli-obk commit[6] 2019-04-23UTC: Auto merge of - stepnivlk:visit_subpats-removal, r=varkor commit[7] 2019-04-23UTC: Auto merge of - davidtwco:issue-, r=oli-obk commit[8] 2019-04-23UTC: Auto merge of - Centril:rollup-akw4r85, r=Centril , , are likely the culprit.
Assigning as and removing .
Change:
} } <del> /// Returns an iterator visiting all keys in ascending order by the keys. </del> <ins> /// Returns an iterator visiting all keys in ascending order of the keys. </ins> /// The iterator's element type is `uint`. #[stable] pub fn keys<'r>(&'r self) -> Keys<'r, V> {

Discussion:
cc I'm in the process of -ifying the collections, and I've discovered that the takes a instead of the convention of consuming the value. It's also marked stable, even though the type itself is marked unstable. Should this instead be a candidate for the method discussed in the collection reform trait?
Yeah this is just a mistake. Feel free to fix it to match conventions.
Just to be clear, the solution to this is to make consume the value and introduce a function (and iterator). Is this right or am I missing something?
Yep!
Change:
Scalar::Raw { data, .. } => { assert!(mplace.layout.is_zst()); assert_eq!( <del> data, mplace.layout.align.abi.bytes().into(), "this MPlaceTy must come from `try_as_mplace` being used on a zst, so we know what value this integer address must have", </del> <ins> u64::try_from(data).unwrap() % mplace.layout.align.abi.bytes(), 0, "this MPlaceTy must come from a validated constant, thus we can assume the  alignment is correct", </ins> ); ConstValue::Scalar(Scalar::zst()) }

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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Assigning and removing as as part of the prioritization working group procedure.
searched nightlies: from nightly-2020-09-16 to nightly-2020-09-29 regressed nightly: nightly-2020-09-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Cc
Change:
return; } } <ins> // FIXME(const_generics): Currently, any uninferred `const` generics arguments // are handled specially, but instead they should be handled in `annotate_method_call`, // which currently doesn't work because this evaluates to `false` for const arguments. // See https://github.com/rust-lang/rust/pull/77758 for more details. </ins> if self.node_ty_contains_target(expr.hir_id).is_some() { match expr.kind { ExprKind::Closure(..) => self.found_closure = Some(&expr),

Discussion:
At the moment, we simply emit errors like: It would be good to suggest to the user how to fix this, like with uninferred type arguments.
cc
Stu over has picked this issue up.
Change:
} #[stable(feature = "std_debug", since = "1.16.0")] <del> impl<'a, K: Debug, V: Debug> fmt::Debug for Keys<'a, K, V> { </del> <ins> impl<'a, K: Debug, V> fmt::Debug for Keys<'a, K, V> { </ins> fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { f.debug_list() .entries(self.clone())

Discussion:
landed implementations for a number of derived types in collections, but imposes overly strict requirements. For example, for : Given that only the keys are printed, we should only require , not also (unless I'm mistaken?).
Yep, seems overly restrictive.
While we're on it, should only require , and the same change should be applied to and friends.
Change:
| = note: an implementation of `std::ops::Add` might be missing for `A` <del> error[E0369]: cannot substract `A` from `A` </del> <ins> error[E0369]: cannot subtract `A` from `A` </ins> --> $DIR/issue-28837.rs:8:7 | LL |     a - a;

Discussion:
Got this error message when trying to compile a crate using rustc 1.42.0-nightly ( 2020-01-07). The text reads substract instead of subtract.
if you want to contribute a fix, you would just need to modify these three lines:
thanks for your response, I submitted a PR to fix this.
Change:
pub fn target() -> Target { let mut base = super::linux_base::opts(); <ins> base.cpu = "x86-64".to_string(); </ins> base.pre_link_args.push("-m64".to_string()); Target {

Discussion:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"
Change:
let save_ctxt = SaveContext { tcx, tables: &ty::TypeckTables::empty(None), <ins> empty_tables: &ty::TypeckTables::empty(None), </ins> access_levels: &access_levels, span_utils: SpanUtils::new(&tcx.sess), config: find_config(config),

Discussion:
I wasn't sure if it was right to report this here or elsewhere, so here it is for now... Trying to compile with works, but running the from the same toolchain results in the following:
looks like
cc
triage: P-high. Removing nomination label.
Easy way to reproduce. empty project to dependencies RLS Errors: And
although supposedly this has been fixed a couple of days ago, latest nightly rls still crashes on petgraph:
Chances are this has been fixed with Could you please update to the newest nightly now and see if you can reproduce this?
yes this is fixed now, thanks!

RLS cannot build my project, which uses gstreamer. Compiling it normally with rustc works fine. Affected project for reference: I launched RLS manually with
Probably unearthed by
cc
Recompiled everything with , same issue.
works fine.
I’m sure it’s what - it’s an unearthed bug when you pass -Zsave-analysis, hence why it crashes only when using RLS.
I have the same error when using rust nightly and directly or indirectly referencing the crate. The project builds fine but crashes. Steps to reproduce: Create a new project Add to the Run Downgrading to and makes the error go away.
pre-triage: not sure what priority to assign to this. Probably P-high but I want to discuss with team. Leaving I-nominated unprioritized for now.
triage: P-high. Cc (can you take point on this?)
Yup, assigning to myself, shouldn’t be hard to fix
What assistance from others, if any, could help you resolve this issue?
Minimal reproducer (based on petgraph ICE):
Is anyone else available you can offload this bug to?
visiting for triage. Assigning to self to remember to look into this later
So I have a fix that does not ICE but doesn't seem to actually 'fix' the behaviour. The problem is that we can't nest typeck tables for because it doesn't have one because it doesn't have a body; however we hit the assertion when trying to resolve member type when resolving a qualified path using because the DefId paths don't properly match. The fix that I have is not to try to nest when a given NodeId doesn't have associated typecktables but instead use an empty table approach (e.g. used in privacy code). This means we don't hit the assertion but IIUC we can't properly resolve a qualified path this way. I think long-term the solution would be to traverse HIR directly rather than doing so using AST (that's another case where we have a mismatch of nested DefIds for which we can't get typeck tables to properly resolve a ). I'll submit the PR with the fix later today.
Change:
} ExprKind::AssignOp(_, ref left_expression, ref right_expression) => { visitor.visit_expr(right_expression); <del> visitor.visit_expr(left_expression) </del> <ins> visitor.visit_expr(left_expression); </ins> } ExprKind::Field(ref subexpression, ident) => { visitor.visit_expr(subexpression);

Discussion:
The code below causes an internal compiler error. I've provided some more details as comments. rustc 1.37.0-nightly ( 2019-05-31) binary: rustc commit-hash: commit-date: 2019-05-31 host: x86_64-unknown-linux-gnu release: 1.37.0-nightly LLVM version: 8.0 Backtrace:
Does this issue still occur? I couldn't reproduce it from given code on playground.
I just checked with nightly 2019-06-03, and it's still there. It requires the line to occur.
minimized:
Marking as blocking -- not entirely clear how general this is but it looks like something people might run across fairly easily.
cc -- maybe you have some idea what the problem is here?
My guess is that implicitly borrows during the type checking phase, so we don't record as being part of the generator.
This seems to be related to the field calculated . When , a computed count of gets compared against a exprcount of , resulting in being set to . However,I'm seeing this line earlier in the logs: which has a count of , as expected. This would seem to suggest that the count is somehow getting overwritten later on.
On further inspection, the count doesn't appear to be getting overwritten. and are both computing it in the same way, but it seems inconsistent with the MIR that ultimately gets generated. I think that due to the way the HIR post-order traversal works, the overall assignment expression is computed to be 'after' the inner , which is interpreted to mean that it isn't live over the yield point. However, consider the MIR for a similar function: The relevant MIR is; Here, the mutable borrow adjustment occurs before the body of the block. When the block includes a , the is clearly live across the yield point.
Change:
<ins> // build-pass enum Empty {} enum Enum { Empty( Empty ) } fn foobar() -> Option< Enum > { let value: Option< Empty > = None; Some( Enum::Empty( value? ) ) } fn main() { foobar(); } </ins>

Discussion:
I get the following internal compiler error with rustc nightly: To reproduce, just checkout the repo at the following commit: Run:
Can you please provide a minimized example that would fit in the playground without any dependencies? We would also appreciate a backtrace.
Sorry for forgetting the backtrace, here we go: Regarding a minimized example, I would really like to provide you one, but I did not change any code. I just updated the nightly compiler. The latest stable compiles this code without any problems.
Sure; it's just substantially more difficult to fix a bug when the input is large as compared to just a few lines of code you can put in a file (and in the playground!). :) Reports with a minimal snippet tend to get fixed much faster and we sorta need a regression test as well.
cc
Did you try the beta compiler? Does it work there?
Okay, I tried to find the problem and to reproduce it. I failed at reproducing :( However, I found the line If I remove this call to it does not crash. This call is implemented in the following monstrous impl block: I somehow suspect that the where clause could be the reason for it. Sorry for not being able to reduce it anymore! I'm currently testing the beta channel and will report back when I know more.
Beta works for me.
I downgraded to "rustc 1.40.0-nightly ( 2019-10-13)" and that compiles the crate without any problems.
triage: P-high. self-assigning. removing nomination tag.
Minimal example: . It works on stable and on beta; it ICEs on nightly.
Curiously this does not reproduce with instead of . cc
I believe this is an assert at my request - it already existed in miri, but was missing from the original implementation in .
can we remove the assertion for now?
Oops, this slipped into beta ( was on vacation and I forgot about it completely).
(to be fair, it was assigned to me, and I just kept letting it slip on my own priority list as well...)
reassigning to based on feedback from compiler team
This regressed
Change:
} assert_eq!(hasher.hash, 5); } <ins> #[test] fn test_build_hasher_object_safe() { use std::collections::hash_map::{DefaultHasher, RandomState}; let _: &dyn BuildHasher<Hasher = DefaultHasher> = &RandomState::new(); } </ins>

Discussion:
From 1.55 crater run , : a generic method to the trait, making it no longer object safe. This only caused one crate in crater to fail, and the source for that crate seems to have been removed from github. Still, I don't think this is technically allowed breakage. modify labels: +regression-from-stable-to-beta -regression-untriaged +T-libs +I-nominated cc
I think this just needs a on that method, no? Probably was just overlooked during review.
Change:
} fn main() { <del> if cfg!(windows) && cfg!(target_env = "gnu") && cfg!(target_pointer_width = "32") { return } </del> let args: Vec<String> = env::args().collect(); if args.len() >= 2 && args[1] == "fail" { foo();

Discussion:
Backtraces on windows are generated using the function. This will generate incorrect backtraces if any of the frame pointers are omitted due to FPO. This would normally be fine, as debug builds are compiled without FPO enabled. However, even in debug builds, the code will be linked to an optimised build of , so if any frames from libstd are on the top of the stack when the backtrace is generated (which will always be the case for obvious reasons) there's the potential for one or more of those frames to have been optimised out, breaking the backtrace. On , this turns out to always be the case, as triggers FPO. On , it currently works, but I'm unsure if that's just luck, or whether FPO is not used for that target. This was not caught by tests because has been (accidentally?) disabled on all windows targets.
It is due to the Windowx 64-bit calling convention being designed in such a way that FPO can always be done and stack walking always work, unlike 32-bit.
Change:
// just a dummy comment so the list doesn't get onelined ]; <ins> /// Minimum version threshold for libstdc++ required when using prebuilt LLVM /// from CI (with`llvm.download-ci-llvm` option). #[cfg(not(feature = "bootstrap-self-test"))] const LIBSTDCXX_MIN_VERSION_THRESHOLD: usize = 8; </ins> impl Finder { pub fn new() -> Self { Self { cache: HashMap::new(), path: env::var_os("PATH").unwrap_or_default() }

Discussion:
Spawned off of I'm not 100% sure what would be involved in such a check here, but it seems like a good thing to investigate, because the nature of the resulting bootstrap failures is super frustrating. (I'll admit, I don't know if the right thing would be to hard error out of all uses of download-ci-llvm for potentially-incompatible libstdc++, or only to hard error out for defaulting uses... but a warning seems warranted in any such cases.
I guess the problem here is that we're compiling the locally and linking that against the downloaded toolchain. A check like suggested here makes sense to me in the meantime, but I suppose long-term the "right" fix here is to get rid of any C++ code we need to separately compile by upstreaming C bindings into LLVM proper, and then we can just call those on the Rust side without any ABI issues. (FWIW, I was initially confused since we explicitly statically link in the stdcpp in the distributed I guess maybe we could also fix this by skipping linking to a local stdcpp while compiling the Rust wrapper code? Not sure if that works out.)
This is the particular line which leads to failure with download-ci-llvm when there is an ABI mismatch. In my experiment removing it resulted in linking errors on rustcdriver. I agree, this solves the problem completely without applying hacks (in my opinion, there is no simple or clean way of comparing ABI or libstd versions) on bootstrap. Maybe, for now, we should just print a warning when downloading ci llvm?
You mean always print a warning? I don't think that's a good idea, it's noisy and we generally expect that people are happy using download CI LLVM. I don't think a warning is helpful here if we can't scope it down to where it matters (in which case it can probably be an error).
Not always, only once while downloading it.
I think that falls in the same "not particularly helpful" case. Most users will miss the message, and even if they don't it's not clear how they should respond. I at least don't know how to check whether my machine has everything setup right. If we could check then we could limit the warning, in which case I'm broadly in favor of making it perhaps even a hard error.
Change:
use std::collections::BTreeSet; use rustc_data_structures::ptr_key::PtrKey; use rustc_data_structures::sync::Lrc; <ins> use rustc_data_structures::fx::FxIndexMap; </ins> use diagnostics::{Suggestion, ImportSuggestion}; use diagnostics::{find_span_of_binding_until_next_binding, extend_span_to_previous_binding};

Discussion:
The test appears to be intermittently changing its output. Usually, it prints: but sometimes it prints: See for an example of this happening. Here's a log snippet from a compiler build which prints (the current expected output): Note - this indicates that the chosen (which is what actually gets printed) is Output from a compiler which prints : Note - here, the is . There appears to be some non-determinism occuring, but I'm not sure where.
This is blocking - some builders are printing while others are printing , making it impossible to merge.
Change:
<ins> error[E0277]: `[usize; usize::MAX]` is not a future --> $DIR/debug-ice-attempted-to-add-with-overflow.rs:8:37 | LL |     [0usize; 0xffff_ffff_ffff_ffff].await; |                                    -^^^^^ |                                    || |                                    |`[usize; usize::MAX]` is not a future |                                    help: remove the `.await` | = help: the trait `Future` is not implemented for `[usize; usize::MAX]` = note: [usize; usize::MAX] must be a future or must implement `IntoFuture` to be awaited = note: required for `[usize; usize::MAX]` to implement `IntoFuture` error[E0752]: `main` function is not allowed to be `async` --> $DIR/debug-ice-attempted-to-add-with-overflow.rs:6:1 | LL | async fn main() { | ^^^^^^^^^^^^^^^ `main` function is not allowed to be `async` error: aborting due to 2 previous errors Some errors have detailed explanations: E0277, E0752. For more information about an error, try `rustc --explain E0277`. </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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I have no idea why this exists, nor does removing it change test output. Someone should find out what it's for, and also add tests around this code ideally.
claim
Reason add 1 to 0 is to match the "pluralize" macro. In the macro, if x is not 1 (more than 1), then append "s" (indicating as plural). If x is 1, then append nothing. Thus satisfy the "pluralize" macro.
claim
Ok looks like this can be closed because the solution was merged in
claim
Hello, I see someone else already assigned, but this issue is still "open" and has the "help wanted" tags. I'm new to contributing to Rust, so if you're willing to help, I'd be happy to help. Thanks!
Hi David, Apekros has already posted a PR for this one: which has not been merged yet however.