jiebi/CodeConvo huggingface dataset:
Change:
inner: IterMut<'a, K, V>, } <ins> /// An owning iterator over the keys of a `BTreeMap`. /// /// This `struct` is created by the [`into_keys`] method on [`BTreeMap`]. /// See its documentation for more. /// /// [`into_keys`]: BTreeMap::into_keys #[unstable(feature = "map_into_keys_values", issue = "75294")] #[derive(Debug)] pub struct IntoKeys<K, V> { inner: IntoIter<K, V>, } /// An owning iterator over the values of a `BTreeMap`. /// /// This `struct` is created by the [`into_values`] method on [`BTreeMap`]. /// See its documentation for more. /// /// [`into_values`]: BTreeMap::into_values #[unstable(feature = "map_into_keys_values", issue = "75294")] #[derive(Debug)] pub struct IntoValues<K, V> { inner: IntoIter<K, V>, } </ins> /// An iterator over a sub-range of entries in a `BTreeMap`. /// /// This `struct` is created by the [`range`] method on [`BTreeMap`]. See its

Discussion:
Associative maps ( and ) in Rust are currently missing two methods to get owning iterators to their keys or values. We have to get key-value reference pairs, to get key-value mutable reference pairs and to get owned key-value pairs. I'd expect and to offer a similar trio of methods (with an exception for of course). is there, but the variants are missing for seemingly no good reason. As an example implementation (but perhaps we can do better):
I would accept a PR to introduce unstable intokeys() and intovalues().
Hi, I’m interested in working on this but I have a question regarding the implementation. I guess we can implement this in two ways. First one is implementing like the example in the first comment, like returning . And the second option is to return a struct of its own (like a mixture of and / structs) instead of returning . We can name them IntoKeys and IntoValues and they can be responsible of implementing the trait. I feel like performance wise they are same, since map and custom struct both will be evaluated lazily when we iterate over. But there might be a rule to always return a proper type in the rust std code that I don't know. So I think I’m okay implementing either way but wanted to ask just in case. What do you think?
For the public API I would prefer this implemented using dedicated IntoKeys and IntoValues iterator types. They can be implemented internally as wrappers around Map<IntoIter<K, Vif that simplifies things.
Thanks for the answer Created a PR for this and you as a reviewer. Would you mind taking a look at it when you have time?
Change:
<ins> error: expected one of `,`, `@`, `]`, or `|`, found `..` --> $DIR/issue-72373.rs:5:19 | LL |         [h, ref ts..] => foo(c, n - h) + foo(ts, n), |                   ^^ expected one of `,`, `@`, `]`, or `|` | help: if you meant to bind the contents of the rest of the array pattern into `ts`, use `@` | LL |         [h, ref ts @ ..] => foo(c, n - h) + foo(ts, n), |                    ^ error: aborting due to previous error </ins>

Discussion:
Gives: I think a better error message should suggest the usage of . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This gets us to:
Format and help message revised to:
Merged. Thanks for the report!
Change:
= help: add #![feature(generic_associated_types)] to the crate attributes to enable error[E0658]: generic associated types are unstable (see issue #44265) <del> --> $DIR/feature-gate-generic_associated_types.rs:23:5 </del> <ins> --> $DIR/feature-gate-generic_associated_types.rs:24:5 </ins> | LL |     type Pointer<usize> = Box<usize>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Discussion:
Compiling this code results in no output by . But exits with 101 and does not produce any artifacts. () The error happens with: , , and -
If I set breakpoints on - It hits the first two but not the third, seemingly pointing to returning an .
The silent exit is a regression. From godbolt, #### 1.23.0 exit code = 101 #### 1.24.0–1.25.0 exit code = 101 #### 1.26.0–1.28.0(beta) No message, exit code = 101 #### 1.29.0(nightly) No message, exit code = 1
cc -- it'd be good to find out why we stopped providing any output at all here
I'm worried it might be one of my parser changes to provide better diagnostics... I would probably check for any odd looking .
It's not the parsing itself, it's that in 1.24 the feature was introduced:
do you think you see what the problem is?
Calling P-high but we don't yet have an obvious assignee. Still, seems bad that there is no diagnostic output at all! Not a good look.
The core issue is reported in However, the example here also demonstrates that clauses aren't being feature gated properly.
I've made to address the surface problem, which is that you can trigger this on stable, without declaring the feature. I thought it was better to fix that part of the problem straight away.
Narrowing it down a little more: is at this point when the clauses are defined, so something's going wrong before that point.
Change:
CodeBlockKind::Fenced(syntax) => { let syntax = syntax.as_ref(); let lang_string = if syntax.is_empty() { <del> LangString::all_false() </del> <ins> Default::default() </ins> } else { LangString::parse(&*syntax, ErrorCodes::Yes, false, Some(extra_info)) };

Discussion:
is not actually allfalse - will return . It would be nice to rename it to at some point (and maybe add while we're at it). cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I'll either get to it before next week is over or when is merged, whichever comes first
Change:
Ok(Some(self.mk_item(span, ident, ItemKind::MacroDef(def), vis.clone(), attrs.to_vec()))) } <del> fn parse_stmt_without_recovery(&mut self, macro_legacy_warnings: bool) -> PResult<'a, Option<Stmt>> { </del> <ins> fn parse_stmt_without_recovery( &mut self, macro_legacy_warnings: bool, ) -> PResult<'a, Option<Stmt>> { </ins> maybe_whole!(self, NtStmt, |x| Some(x)); let attrs = self.parse_outer_attributes()?;

Discussion:
I'm seeing the following error on the channel, but not on or : Found with the help of .
triage: P-medium. Leaving nominated so that team double-checks that priority assignment.
This is triggered here It should be possible to use the span snippet instead. I believe it was introduced in
Change:
/// "Downcast" to a variant of an enum or a coroutine. /// /// The included Symbol is the name of the variant, used for printing MIR. <ins> /// /// This operation itself is never UB, all it does is change the type of the place. </ins> Downcast(Option<Symbol>, VariantIdx), /// Like an explicit cast from an opaque type to a concrete type, but without

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
seem like options that when paired together would cause issues... At first glance, I'm actually not sure why this is filed as a bug.
I agree. Nobody should be testing , I don't know why those passes are even in the codebase. But this is a bug. I've found this in real code with a much smaller set of flags: And this bisects to Bisected by hand, there's no nightly with that PR yet. Don't know where Matthias got that toolchain.
Afaict likes to do ICE testing against master
We just hit this on Fuchsia as well. I think we should revert the PR until we fix this issue and reland it.
Another one with
Also here's a list of files from the rustc repo that all seem to trigger the problem in one way or another
Looks like there is one more issue in GVN ():
There is no basis for the assumption that interpreter will never downcast to an uninhabited variant:
nice example! That assert was as an experiment to see if we ever hit that codepath, and it seems like the answer is yes. It should thus be removed, with a suitable const-eval test case.
I wonder if that code shouldn't have a read somewhere though... it is conceptually a match after all. Still, the assertion should go: That adds test, but not the others.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
} } if let Some(cur_line) = sf.get_line(cur_lo.line - 1) { <del> let end = std::cmp::min(cur_line.len(), cur_lo.col.to_usize()); </del> <ins> let end = match cur_line.char_indices().nth(cur_lo.col.to_usize()) { Some((i, _)) => i, None => cur_line.len(), }; </ins> buf.push_str(&cur_line[..end]); } }

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on and but not on .
Visited from compiler team triage meeting. Categorized as P-medium.
searched nightlies: from nightly-2020-01-01 to nightly-2020-02-10 regressed nightly: nightly-2020-01-22 searched commits: from to regressed commit: source code: <details<summaryICE backtrace</summary<p</p</detailsReproduce bisect report:
Interesting -- the regression report suggests this was caused by , cc
The problem is here: is a character index. It needs to be translated into a byte index before it can be used to slice . I've submitted a
Change:
<del> // Checks that all the targets returned by `rustc --print target-list` are valid // target specifications </del> <ins> // Checks that all the targets returned by `rustc --print target-list` are valid target // specifications. // ignore-tidy-linelength //@ needs-llvm-components: aarch64 arm avr bpf csky hexagon loongarch m68k mips msp430 nvptx powerpc riscv sparc systemz webassembly x86 // FIXME(jieyouxu): there has to be a better way to do this, without the needs-llvm-components it // will fail on LLVM built without all of the components listed above. </ins> use run_make_support::bare_rustc; <del> // FIXME(127877): certain experimental targets fail with creating a 'LLVM TargetMachine' // in CI, so we skip them </del> <ins> // FIXME(#127877): certain experimental targets fail with creating a 'LLVM TargetMachine' in CI, so // we skip them. </ins> const EXPERIMENTAL_TARGETS: &[&str] = &["avr", "m68k", "csky", "xtensa"]; fn main() {

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:
// ignore-tidy-linelength // ignore-lldb // ignore-android: FIXME(#24958) <ins> // ignore-arm: FIXME(#24958) // ignore-aarch64: FIXME(#24958) </ins> // compile-flags:-g

Discussion:
Triggers an LLVM assertion when targeting Android:
Something that works on any host (i.e. you needn’t compile libstd for android to repro):
As the error says, isn't a supported calling convention for the ARM target in LLVM. Not really much we can do from the rustc side unless we want to error early based on cc/target combinations. In any case, it should not crash.
I'm hitting this when I tried to run tests for 1.10.0 on arm64 (aarch64-unknown-linux-gnu). The build succeeds otherwise. I'm just adding and to for the time being.
Neither example crashes today. Closing, since I don't see any good opportunity for a test here (it'd have to be something like and that's probably not worth it). With (original example): Updated example:
Change:
<ins> fn t7p<A, B, C>(f: impl Fn(B) -> C, g: impl Fn(A) -> B) -> impl Fn(A) -> C { move |a: A| -> C { f(g(a)) } } fn t8n<A, B, C>(f: impl Fn(A) -> B, g: impl Fn(A) -> C) -> impl Fn(A) -> (B, C) where A: Copy, { move |a: A| -> (B, C) { let b = a; let fa = f(a); let ga = g(b); (fa, ga) } } fn main() { let f = |(_, _)| {}; let g = |(a, _)| a; let t7 = |env| |a| |b| t7p(f, g)(((env, a), b)); let t8 = t8n(t7, t7p(f, g)); //~^ ERROR: expected a `Fn<(_,)>` closure, found `impl Fn<(((_, _), _),)> } </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<pthe backtrace itself is all </p</details
It's strange, I tried these code in main and it complains about (Compile Error but not ICE) I think the trait is depends on and dyn could resolve this.
Assigning and removing nomination. This was . This one also sounds a bit similar to and which is very old. Would be nice to find if there are duplicates too.
Pinging cleanup to find duplicates ... 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
Triage: It's no longer ICE with the latest nightly, I think it's fixed by .

Discovered a compiler panic, thought it might relate to , but was told to post a new issue. In minimizing, it seems the generic types are required to trigger the panic, I was unable to reproduce when inlining t7p or t8n. This code panics on 1.33 - 1.35, but does not panic on 1.32 (): On 1.32: On 1.35 nightly: --Bryan
triage: P-high. Removing nominated tag since there's little to discuss beyond its P-highness. (The fact its unassigned will be discussed regardless of nomination state.)
Bisection points to i.e. as the culprit. The backtrace in that commit looks very similar to the one reported here, and the parent commit () gives the same compiler error.
I spent some time looking at this a few weeks ago but did not manage to find anything conclusive. At this point I'm going to be taking a break for a few months, so I am unassigning myself from this issue.
triage: assigning self.
triage: downgrading to P-medium; this does not warrant revisiting every week.
I was able to minify it a bit further:
Triage: It's no longer ICE with the latest nightly.

The following example ICEs yields (Same is true on stable.)
That's because the ObjectCandidate code is not normalizing the upcast trait refs. Should we wait for Chalk for the fix?
Hitting this error, any updates?
Triage: no longer ICEs.
It's still an ICE, note that we should build/run the snippet to check it ().
Triage: It's no longer ICE with the latest nightly, I think it's fixed by .
Change:
} } } <ins> struct HasNumericInferVisitor; impl<'tcx> ty::TypeVisitor<'tcx> for HasNumericInferVisitor { type BreakTy = (); fn visit_ty(&mut self, ty: Ty<'tcx>) -> ControlFlow<Self::BreakTy> { if matches!(ty.kind(), ty::Infer(ty::FloatVar(_) | ty::IntVar(_))) { ControlFlow::Break(()) } else { ControlFlow::CONTINUE } } } </ins>

Discussion:
When I run this code (via ): I get the output I expected (i.e., a single line of output that says "My number is 42"). However, if I run this code (via the same with no other changes): I get two compiler errors. The first error indicates that is not in scope - this makes sense, I have not defined anywhere. However, the second error indicates (provided below) does not make sense: It appears that, when there are no other compiler issues, the compiler can infer a type for just fine. However, as soon as any other compiler issue appears, it loses the ability to infer type. That doesn't make sense to me - the ability to infer type should be unrelated to any other compiler errors present. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I partially fixed this for and in , but not in general. I am dissatisfied with this error message. I'll look into fixing it. claim
Change:
<ins> // Copyright 2018 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. // compile-flags: --edition 2018 // The local `use` suggestion should start with `crate::` (but the // standard-library suggestions should not, obviously). mod plumbing { pub struct Drain; } fn main() { let _d = Drain {}; //~^ ERROR cannot find struct, variant or union type `Drain` in this scope } </ins>

Discussion:
Consider the following program. When compiled with with the 6 July nightly, we get this error message: But if we take the suggestion literally (and continue using the 2018 edition), is : A pull request is forthcoming.
Change:
InlineAsmSized, /// `[expr; N]` requires `type_of(expr): Copy`. RepeatElementCopy { <del> /// If element is a `const fn` we display a help message suggesting to move the /// function call to a new `const` item while saying that `T` doesn't implement `Copy`. is_const_fn: bool, </del> <ins> /// If element is a `const fn` or const ctor we display a help message suggesting /// to move it to a new `const` item while saying that `T` doesn't implement `Copy`. is_constable: IsConstable, elt_type: Ty<'tcx>, elt_span: Span, /// Span of the statement/item in which the repeat expression occurs. We can use this to /// place a `const` declaration before it elt_stmt_span: Span, </ins> }, /// Types of fields (other than the last, except for packed structs) in a struct must be sized.

Discussion:
I'm basing this suggestion on two things. One, that if you follow it, the code compiles: and two, that the diagnostic help you get when you try to use a in the repeat position suggests something very similar, see "other cases." It would require the compiler to know that a value that is attempted to be repeated is able though, which I don't know whether it can, but I figured I'd suggest this, and you can reject it if it isn't possible to do. Alternatively, the help text could say something like "if the value can be made , consider creating [...]" I was inspired to make this issue based on the output you get when you try to use a as an array initializer. For instance, the code produces the output No response
hey why im getting this error message all over my github repository ! whenever i commit some changes, The first changes i able to create pull request but after some other changes im not able to do that why im getting these error ! Please help
I don't think your comment is related to this issue? If this is a problem you've encountered while trying to fix this issue, please reach out on instead.
Change:
"library/stdarch", "src/tools/cargo", "src/tools/clippy", <ins> "src/tools/libcxx-version", </ins> "src/tools/miri", "src/tools/rust-analyzer", "src/tools/rustc-perf",

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:
<ins> //@ check-fail // Fixes #119830 #![feature(effects)] #![feature(min_specialization)] #![feature(const_trait_impl)] trait Specialize {} trait Foo {} impl<T> const Foo for T {} //~^ error: const `impl` for trait `Foo` which is not marked with `#[const_trait]` //~| error: the const parameter `host` is not constrained by the impl trait, self type, or predicates [E0207] impl<T> const Foo for T where T: const Specialize {} //~^ error: const `impl` for trait `Foo` which is not marked with `#[const_trait]` //~| error: `const` can only be applied to `#[const_trait]` traits //~| error: the const parameter `host` is not constrained by the impl trait, self type, or predicates [E0207] //~| error: specialization impl does not specialize any associated items //~| error: could not resolve generic parameters on overridden impl fn main() { } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: is not fully resolved', 'error: internal compiler error: is not fully resolved' File: --Another regression of snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [checkmodimpl_wf] checking that impls are well-formed in top-level module [analysis] running analysis passes on this crate --
This is caused by the fact that  does not check for const effect vars when visiting . It should be relatively simple to match on in the folder.
Working on this one.