jiebi/CodeConvo huggingface dataset:
Code change:
use rustc_span::{BytePos, Span, Symbol}; use rustc_trait_selection::infer::InferCtxtExt; use rustc_trait_selection::traits::ObligationCtxt; <ins> use std::iter; </ins> use crate::borrow_set::TwoPhaseActivation; use crate::borrowck_errors;

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: or similar. The note and/or help are both subject to changes, this is just a basic idea. We could also conceivably rewrite the error message to expand on what the note says, like so: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
It's hard to get 'c' in line 3 during the context where the compiler errors out the second mutable borrow message, because the mutable borrow happens between
I don't think it's critical to mention in the diagnostic. We shouldn't let the difficulty of doing that stop us from trying to improve the message. label +D-newcomer-roadblock
I'd love to try to fix this, but sadly I'm not familiar with the internals of rustc. If someone could point me towards the section where this error is, I could give it a try.
Hi ! Whenever I try to dive into fixing a problem with rustc, I usually start with a search through the codebase. In this case, I'd search for strings that come from the error message: , , or : <img width="528" alt="image" src="https://user-"And that leads me to here: So then I'd use rust-analyzer to try to find all the usages of that method.
Code change:
use rustc_span::{BytePos, Span, Symbol}; use rustc_trait_selection::infer::InferCtxtExt; use rustc_trait_selection::traits::ObligationCtxt; <ins> use std::iter; </ins> use crate::borrow_set::TwoPhaseActivation; use crate::borrowck_errors;

Related discussion:
text: In this case, turns out there's only one: And there we see that there is already some conditional suggestion being made; it calls . And it seems there's a family of those . So I think it would make sense to try to write your own or something like that. You'll need to figure out how to sort of "back track" from the MIR back to the HIR or the AST so you can figure out whether you're inside a loop. I would study the code in to try to figure out how to do that. And don't forget to write a handful of regression tests in somewhere, maybe in : https://rustc-dev- It might also be possible to perform this check at a higher level, say, in . If you can figure out that you're in a for loop, and that the user is trying to call on the iterator, then you could raise the error then.
Code change:
.primitive_type() .and_then(|t| self.cache.primitive_locations.get(&t).cloned()); <del> if let Some(did) = did { dids.insert(did); } </del> <ins> dids.extend(did); </ins> } } if let Some(generics) = i.trait_.as_ref().and_then(|t| t.generics()) { for bound in generics { <del> if let Some(did) = bound.def_id(self.cache) { dids.insert(did); } </del> <ins> dids.extend(bound.def_id(self.cache)); </ins> } } let impl_item = Impl { impl_item: item }; <del> if impl_item.trait_did().map_or(true, |d| self.cache.traits.contains_key(&d)) { </del> <ins> let impl_did = impl_item.def_id(); let trait_did = impl_item.trait_did(); if trait_did.map_or(true, |d| self.cache.traits.contains_key(&d)) { </ins> for did in dids { <del> if self.impl_ids.entry(did).or_default().insert(impl_item.def_id()) { self.cache .impls .entry(did) .or_insert_with(Vec::new) .push(impl_item.clone()); </del> <ins> if self.impl_ids.entry(did).or_default().insert(impl_did) { self.cache.impls.entry(did).or_default().push(impl_item.clone()); </ins> } } } else { <del> let trait_did = impl_item.trait_did().expect("no trait did"); </del> <ins> let trait_did = trait_did.expect("no trait did"); </ins> self.cache.orphan_trait_impls.push((trait_did, dids, impl_item)); } None

Related discussion:
text: Generated rustdoc JSON for every one of dozens of crates I've looked at seems to contain unexpected inlined items that look like an block and its contents. I expected to see this happen: rustdoc JSON file contains only the items defined or re-exported by the corresponding crate. Instead, this happened: the rustdoc JSON file contains items like this: In this example, is and here are the names of the items contained in that impl (also part of the rustdoc JSON): Similarly, you can find items from : Invocation for generating rustdoc JSON: : You can find a variety of pre-generated rustdoc JSON files with this issue here: Briefly discussed in Zulip: https://rust- I'll have to work around this behavior to shield , which uses the same codebase as the playground link above. I can hold off on updating the playground for, say, another week, but at some point I'll need to upgrade it to include my workaround which means those items will cease being shown. label +T-rustdoc +A-rustdoc-json
Possibly duplicate of
Might be! Definitely at least some overlap, not entirely sure if duplicate. Do you mind if I ship the workaround for this in cargo-semver-checks and the playground, which will hide these items from our lints and from queries in the playground?
Yeah, it's easy enough to reproduce in raw json, I'm not worried about the repro breaking.
Code change:
// Now create the real type parameters. for i in 0..ast_generics.ty_params.len() { <del> let def = get_or_create_type_parameter_def(ccx, ast_generics, space, i as u32); </del> <ins> let def = get_or_create_type_parameter_def(ccx, ast_generics, space, i as u32, allow_defaults); </ins> debug!("ty_generics: def for type param: {:?}, {:?}", def, space); result.types.push(space, def); }

Related discussion:
text: If I understand correctly, type parameter defaults have no effect in the block . Just like in PR , this should have a warning and then an error. Example cc
Argh, I guess I failed to cover those?
Nominating for triage.
triage: P-high
Code change:
<ins> error[E0004]: non-exhaustive patterns: `Tag(Exif, _)` not covered --> $DIR/issue-50900.rs:15:11 | LL | pub struct Tag(pub Context, pub u16); | ------------------------------------- `Tag` defined here ... LL |     match Tag::ExifIFDPointer { |           ^^^^^^^^^^^^^^^^^^^ pattern `Tag(Exif, _)` not covered | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms error: aborting due to previous error For more information about this error, try `rustc --explain E0004`. </ins>

Related discussion:
text: I hope this is not already known, but my searching has not turned up anything. Compiling a rust binary with the dependency panices in nightly. How to reproduce: a new rust binary. to dependencies in This gives the following output It compiles on stable and beta. Edit: Just running in gives the same result.
Tried a few different nightlies. And it looks like it broke sometime between and
I have managed to get a much smaller example. Compiling this on nightly gives the above panic:
Looks like it's fixed in the newest nightly ()
Bisecting between ... gives as the regression PR.
Code change:
<ins> #![feature(const_generics)] #![allow(incomplete_features)] fn func<A, const F: fn(inner: A)>(outer: A) { //~^ ERROR: using function pointers as const generic parameters is forbidden F(outer); } fn main() {} </ins>

Related discussion:
text: I've tried reducing this but wasn't really able to so far. I might try again some other time. The code below currently ICEs on Nightly (). When trying to reproduce locally for the backtrace, I had an older Nightly first () where this actually didn't crash the compiler, so it's apparently a regression. <details<summary<strongBacktrace</strong</summary<p</p</details
This is my first time using cargo-bisect-rustc and it's fantastic. It identified the regression as... searched nightlies: from nightly-2020-02-13 to nightly-2020-05-14 regressed nightly: nightly-2020-03-20 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
is a rollup commit. The only PR which was part of that and (to me) looks like it could have caused this issue is .
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Code change:
<ins> #![feature(const_generics)] #![allow(incomplete_features)] fn func<A, const F: fn(inner: A)>(outer: A) { //~^ ERROR: using function pointers as const generic parameters is forbidden F(outer); } fn main() {} </ins>

Related discussion:
text: produces: <details</detailsIt should not be possible to access the type parameter in the type of the const parameter. cc Thanks to for .
Hi, I am new to rust compiler development and have decided to try to fix this issue to get started. If I understand the const-generics RFC correctly, type parameters can not be used in a const generic parameter because it cannot be ensured that the actual types have the "structural match" property. However, checking reveals that fn pointers (as well as raw pointers and empty arrays) always support structural matching, regardless of the types used within. My question is: is there another reason why const generic parameters are not allowed to use type parameters? If so, I think an additional check has to be to .
Actually, I think I may have interpreted. It looks like this example is intended to work to me. cc just to clarify.
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Code change:
<ins> #![feature(const_generics)] #![allow(incomplete_features)] fn func<A, const F: fn(inner: A)>(outer: A) { //~^ ERROR: using function pointers as const generic parameters is forbidden F(outer); } fn main() {} </ins>

Related discussion:
text: <!-- 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
Probably related to
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Code change:
<ins> #![feature(const_generics)] #![allow(incomplete_features)] fn func<A, const F: fn(inner: A)>(outer: A) { //~^ ERROR: using function pointers as const generic parameters is forbidden F(outer); } fn main() {} </ins>

Related discussion:
text: <!-- 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
Depends on const generics in type dependent paths afaict. See for more info. EDIT: Also depends on const generics with generic types. Merging does not close this issue
Triage: the feature was removed by and the ICE no longer occurs with the latest nightly.
Adding the following as a test might still be useful, even if it only errors with "using function pointers as const parameters is forbidden":
Code change:
[[package]] name = "rls" <del> version = "1.39.0" </del> <ins> version = "1.40.0" </ins> dependencies = [ "cargo", "cargo_metadata 0.8.0", "clippy_lints", "crossbeam-channel", "difference", <del> "env_logger 0.6.2", </del> <ins> "env_logger 0.7.0", </ins> "failure", "futures", "heck",

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls 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 compiler team prioritization.
Code change:
<ins> error[E0080]: evaluation of constant value failed --> $DIR/issue-81899.rs:10:5 | LL | const _CONST: &[u8] = &f(&[], |_| {}); |                        -------------- inside `_CONST` at $DIR/issue-81899.rs:4:24 ... LL |     panic!() |     ^^^^^^^^ |     | |     the evaluated program panicked at 'explicit panic', $DIR/issue-81899.rs:10:5 |     inside `f::<[closure@$DIR/issue-81899.rs:4:31: 4:37]>` at $SRC_DIR/std/src/panic.rs:LL:COL | = note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. </ins>

Related discussion:
text: The following code causes compiler panics due to the first line without which the issue isn't reproducible. Calling the function outside of a constant context emits the right compiler errors. <!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details
FWIW, replacing the function body with still gives an ICE:
Minimized slightly further, without const generics: <details<summarybacktrace</summary</detailsThe ICE occurs back to . In , it errors with By making small changes such as making the closure no longer take paramters or removing the reference at It errors, instead of an ICE, on stable and nightly with
searched nightlies: from nightly-2020-08-16 to nightly-2021-02-03 regressed nightly: nightly-2020-12-28 searched commits: from to regressed commit: edit: for this code sample <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
cc
Just to clarify, AFAICT, this issue is not due to , the stabilization just allowed code with const generics to run into this. MCVE ICEs before and shows that this is a borrowck bug not related to const generics
Assigning as discussed as part of the and removing .
I'm not sure if this is identical problem or not. The error message is: and my code is: I need both parts or the COPY tuple for the error to trigger and I'm unsure why. And also, if I put in its own const the bug is not triggered.
Triage: No longer ICE with the latest nightly, I guess fixed it? Marking as .
Code change:
}; let encl_def_id = parent_item.unwrap_or(first_item.def_id); <ins> // If parent of encl_def_id is an enum, use the parent ID intead. let encl_def_id = get_parent_if_enum_variant(tcx, encl_def_id); </ins> let ignored_derived_impls = if let Some(ign_traits) = self.ignored_derived_traits.get(&encl_def_id) { let trait_list = ign_traits

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: build cleanly Instead, this happened: Running the program shows the field is used: <!-- 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. --Rust version 1.77.0 (tested in playground) </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Derived code is intentionally ignored for dead code analysis - if you try just You'll get a note explaining this. The note doesn't seem to be attached for warnings, just
Ah, so it's intentional. Interesting. I assume the solution is to mark it with then.
claim
release-assignment so can claim it
Error: Parsing assign command in failed: ...'assignment' ' so Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim
Note that while getting a warning if is just derived but never explicitly used may be understandable (as discussed in other issues), you will get a warning if you do use it explicitly (see ) which, in my opinion, should not be the case.
As mentioned above, the fix for this issue is adding a note about how derived traits are intentionally ignored, not to stop ignoring them.
Code change:
- [You can now pass the `--features` option multiple times to enable multiple features.][cargo/7084] <ins> Rustdoc ------- - [Documentation on `pub use` statements is prepended to the documentation of the re-exported item][63048] </ins> Misc ---- - [`rustc` will now warn about some incorrect uses of

Related discussion:
text: At some point between Rust 1.34.0 and 1.39.0, the ability to add documentation to reexported items was , but I can't find it mentioned in either or the rust- blog posts. Maybe this should be mentioned in the RELEASE notes for the version that that feature? I have a crate that I use to test stuff, and used to document this: !
This was changed in 1.38 (coincidentally also the release rust-std spiked from a 61.2 MB to 173.3 MB download). are you interested in making a PR?
Sure, what are the PRs that made this possible?
Oh I have no idea :laughing: I found it by bisecting.
Looks like is it
Code change:
let ptr_ty = ptr.ty; // Create an *internal* temp for the pointer, so that unsafety // checking won't complain about the raw pointer assignment. <del> let ptr_temp = this.local_decls.push(LocalDecl::with_source_info( ptr_ty, source_info, ).internal()); </del> <ins> let ptr_temp = this .local_decls .push(LocalDecl::with_source_info(ptr_ty, source_info).internal()); </ins> let ptr_temp = Place::from(ptr_temp); let block = unpack!(this.into(ptr_temp, block, ptr)); this.into(this.hir.tcx().mk_place_deref(ptr_temp), block, val)

Related discussion:
text: <!-- 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. --The code fails to pass <!-- 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. --Repo is at <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Oh that is interesting: is that expected? The other way around would make sense (assigning a into anything, really), but with a on the left, that seems odd? Or maybe the message just gets the sides wrong.
Yeah, that MIR looks really broken: Cc
This is probably due to this line: , and shouldn't have this, since they have type , not .
This is a super old issue going back all the way to the initial MIR implementation and I’m somewhat confident is documented somewhere, though I cannot find an issue for this. IIRC these invalid assignments only happen in unreachable basic blocks, so however wrong it looks in isolation, it is dead code and I think it never was a priority to fix either generation or the MIR validation we had back then for exactly that reason. Looks like is a new take on validation? Perhaps the easy fix would be to not validate unreachable blocks.
Code change:
fn run(self, builder: &Builder<'_>) { let stage = self.stage; let target = self.target; <ins> let crates = if self.crates.is_empty() { builder .in_tree_crates("sysroot", Some(target)) .iter() .map(|c| c.name.to_string()) .collect() } else { self.crates }; </ins> let out = match self.format { DocumentationFormat::Html => builder.doc_out(target), DocumentationFormat::Json => builder.json_doc_out(target),

Related discussion:
text: I have pinned down the regression to a specific commit, thanks to recommending me . searched nightlies: from nightly-2024-07-28 to nightly-2024-07-30 regressed nightly: nightly-2024-07-30 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.9</summaryHost triple: aarch64-apple-darwin Reproduce with: : </details
Based on the commits in that rollup, I feel like might be the culprit, but it isn't obvious to me why that might be the case (cc
Thanks for the ping, will fix this.
Code change:
<ins> // Copyright 2017 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. pub struct Test; </ins>

Related discussion:
text: I was going through some refactoring and the compiler exploded. No unsafe. The last bits of code I was playing with can be found , before I tried to refactor the example, the tests were building and passing. The macro that might be to blame is . I parked a branch with the code that made it blew up, you can find it here works, blows up. a happy compiler, worst case an unhappy one a dead compiler : Backtrace:
Minimal example:
Thanks that was a quick fix. Do you have a workaround until the fix makes it to master?
The ICE occurs when you have an item referenced in an impl signature is imported from an statement occurs within an impl. To work around the ICE, you can move the call to to a different free function.
Got it, it works , thanks!