jiebi/CodeConvo huggingface dataset:
Change:
// FIXME: Due to #50507 this overwrites the different values // This should be changed to use HashMapExt::insert_same // when that is fixed <del> self.tcx().evaluation_cache.insert(param_env.and(trait_pred), dep_node, result); </del> <ins> self.tcx().evaluation_cache.insert((param_env, trait_pred), dep_node, result); </ins> return; } } debug!(?trait_pred, ?result, "insert_evaluation_cache"); <del> self.infcx.evaluation_cache.insert(param_env.and(trait_pred), dep_node, result); </del> <ins> self.infcx.evaluation_cache.insert((param_env, trait_pred), dep_node, result); </ins> } /// For various reasons, it's possible for a subobligation

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. --code from <!-- 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. --: This crashes nightly, beta and stable <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like this is happens during codegen which is why this didn't show up in the test (note the ´check-pass`) ...?
Hmm... this should be normalized somewhere above codegen I think? Curious to investigate though. claim
I suspect that this is caused by a bug in how we handle higher-ranked region variables (possibly during trait selection caching).
Change:
} } <del> pub fn fill_well_known(&mut self) { </del> <ins> pub fn fill_well_known(&mut self, current_target: &Target) { </ins> self.fill_well_known_names(); <del> self.fill_well_known_values(); </del> <ins> self.fill_well_known_values(current_target); </ins> } }

Discussion:
doesn't seem to know that custom targets can extend the set of values. The following creates a custom spec with a . No warning Got the warning: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
<ins> use std::{fs, io::*}; use std::collections::HashMap; type Handle = BufWriter<fs::File>; struct Thing(HashMap<String, Handle>); impl Thing { pub fn die_horribly(&mut self) { for v in self.0.values() { v.flush(); //~^ ERROR cannot borrow } } } 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. --: The internal compiler error does not occur in stable (): The fix for compilation is to use instead of and this also prevents the panic in the nightly version of rustc. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
It would be nice to reproduce this without the async-std dependency.
Slightly smaller:
I bisected far enough to find it regressed between the 9th and 10th, then ran out of disk space :facepalm:
Smaller example without
Here you go. The async part doesn't seem important and the issue still occurs with the versions of and and removed from dependencies: It could probably be reduced in size further but I'm not much of a Rust expert. I suspect anything which triggers that particular compiler error would do the trick.
searched nightlies: from nightly-2021-02-10 to nightly-2021-02-11 regressed nightly: nightly-2021-02-11 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Probably cc In particular looks suspect.
Are functions registered as items in the hir? edit: nvm just saw that someone posted a non-async example
Change:
for i in from..from + 3 { dst[i] = src[i - from]; } <ins> // `RangeTo` `for` loop - don't trigger lint for i in 0.. { dst[i] = src[i]; } </ins> } #[warn(clippy::needless_range_loop, clippy::manual_memcpy)]

Discussion:
I ran into an issue in where was getting expanded into instead of , which resulted in a compile error. We should add some tests that make sure we can still compile code after macros have been expanded.
To clarify: if I understand you correctly, you're saying that the expansion of error!("...") was being rendered by pprust as log(1,"..."), not that the expansion was actually incorrect. Is that correct? First off, that would obviously be a bug in the pretty-printer, which should be fixed. The larger issue of making sure that pretty-printed code compiles I would nominate for well-covered.
Yep, that was the problem, it's fixed now though. The larger issue still stands.
just a bug, removing milestone/nomination.
Fixed by !
Yay!

When using and together, the compiler complains that is an unused import even when a call to something like exists. Removing gets rid of the warning and the crate compiles. However, the crate will fail to link (for example with ) unless the is there. It seems like the warning is a bug unless the intent is to have also bring in foo itself. Here's a small crate that shows the example. This was originally found in rust-core-foundation.
Looking at the code, that's a genuinely unused import when not compiling with . I ran into this when removing unused imports in the compiler, and you can prefix the import with so that the import is only resolved when testing. Other options I've seen are to have a which is 'd off, or just put the in the function itself.
You're right. In this case I moved the inside the test function.

The macro is required, as is that exact order of the bounds, and the use of the repeated bound in the . (It's not specific to though.) output:
Works now, I'll check in a test case
Test case checked in in . Closing

The following code... ...results in the following error: Both and are loans of , so it should be safe to update to new loan of as updating doesn't cause to be freed.
This works now; I'll check in the test case.
Test case checked in in . Closing

So, after much wrangling with MinGW to get Rust to compile on my Windows partition, I'm trying to get Rust-SDL to work. When compiling it, and then running the demo application, I get the following, somewhat esoteric message: The procedure entry point ZN4bool14extensions9meth80572eq154e94be02e19a92306E could not be located in the dynamic link library core-- Is this a configuration issue? A bug? Me being silly?
I'm suspecting this is a dup of
Well, that puts my mind to rest! Thanks

<prefn main() { #error("%?", x);*/ } </preyields
Change:
<ins> trait Deserialize { fn deserialize(&self); } struct ArchivedVec<T>(T); impl<T> Deserialize for ArchivedVec<T> { fn deserialize(s: _) {} //~^ ERROR: `_` is not allowed within types on item signatures //~| ERROR: has a `&self` declaration in the trait, but not in the impl } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'error: internal compiler error: unexpected region encountered in variance inference: ReLateParam(DefId(0:22 ~ 4CE26EEF2326F71D6A2A2B20D320CA8739959CBFE29E1EDC8A012C82A71A1C39[9323]::{impl}::deserialize), BrNamed(DefId(0:27 ~ 4CE26EEF2326F71D6A2A2B20D320CA8739959CBFE29E1EDC8A012C82A71A1C39[9323]::Deserialize::deserialize::'), '))', 'error: internal compiler error: unexpected region encountered in variance inference: ReLateParam(DefId(0:22 ~ 4CE26EEF2326F71D6A2A2B20D320CA8739959CBFE29E1EDC8A012C82A71A1C39[9323]::{impl}::deserialize), BrNamed(DefId(0:27 ~ 4CE26EEF2326F71D6A2A2B20D320CA8739959CBFE29E1EDC8A012C82A71A1C39[9323]::Deserialize::deserialize::'), '))' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [cratevariances] computing the variances for items in this crate [variancesof] computing the variances of [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
cc
Minimized:
Change:
.collect(); Ok(Some(files)) } <del> /// Print a warning if the branch returned from `updated_master_branch` is old /// /// For certain configurations of git repository, this remote will not be /// updated when running `git pull`. /// /// This can result in formatting thousands of files instead of a dozen, /// so we should warn the user something is wrong. pub fn warn_old_master_branch(config: &GitConfig<'_>, git_dir: &Path) { if crate::ci::CiEnv::is_ci() { // this warning is useless in CI, // and CI probably won't have the right branches anyway. return; } // this will be overwritten by the actual name, if possible let mut updated_master = "the upstream master branch".to_string(); match warn_old_master_branch_(config, git_dir, &mut updated_master) { Ok(branch_is_old) => { if !branch_is_old { return; } // otherwise fall through and print the rest of the warning } Err(err) => { eprintln!("warning: unable to check if {updated_master} is old due to error: {err}") } } eprintln!( "warning: {updated_master} is used to determine if files have been modifiedn warning: if it is not updated, this may cause files to be needlessly reformatted" ); } pub fn warn_old_master_branch_( config: &GitConfig<'_>, git_dir: &Path, updated_master: &mut String, ) -> Result<bool, Box<dyn std::error::Error>> { use std::time::Duration; *updated_master = updated_master_branch(config, Some(git_dir))?; let branch_path = git_dir.join(".git/refs/remotes").join(&updated_master); const WARN_AFTER: Duration = Duration::from_secs(60 * 60 * 24 * 10); let meta = match std::fs::metadata(&branch_path) { Ok(meta) => meta, Err(err) => { let gcd = git_common_dir(&git_dir)?; if branch_path.starts_with(&gcd) { return Err(Box::new(err)); } std::fs::metadata(Path::new(&gcd).join("refs/remotes").join(&updated_master))? } }; if meta.modified()?.elapsed()? > WARN_AFTER { eprintln!("warning: {updated_master} has not been updated in 10 days"); Ok(true) } else { Ok(false) } } fn git_common_dir(dir: &Path) -> Result<String, String> { output_result(Command::new("git").arg("-C").arg(dir).arg("rev-parse").arg("--git-common-dir")) .map(|x| x.trim().to_string()) } </del>

Discussion:
I am in this state (only 1 modified file): But I just tried to format and got this: Something is quite wrong here. Formatting of only changed files must be correct, otherwise some files in the tree will get spurious formatting changes in PRs. Perhaps is related? I have a vague memory of seeing this misbehavior occasionally in the past though I'm only now remembering to file an issue.
Don't we check formatting of all files in CI anyway?
Most likely. On CI, yes.
Interesting. I swear I've seen spurious formatting changes in PRs. Might be some other effect.
Should be closed by (GH didn't pick up the comment)
Change:
<ins> // skip-filecheck //@ test-mir-pass: ElaborateBoxDerefs #![feature(custom_mir, core_intrinsics)] extern crate core; use core::intrinsics::mir::*; // EMIT_MIR elaborate_box_deref_in_debuginfo.pointee.ElaborateBoxDerefs.diff #[custom_mir(dialect = "built")] fn pointee(opt: Box<i32>) { mir!( debug foo => *opt; { Return() } ) } 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsthis was at the end of the error <pi have put a comment in the code where the problematic line is, the problem could be caused by async trait object method in ResourceLoader::startloading<bri am using asynctrait crate<brhere is the library code that the problematic code uses<brthe ResourceLoader trait is at the end </prustc-ice-2024-08-02T150352-!
Change:
progress = true; let ExpansionData { depth, id: expn_id, .. } = invoc.expansion_data; self.cx.current_expansion = invoc.expansion_data.clone(); <del> self.cx.current_expansion.id = scope; </del> // FIXME(jseyfried): Refactor out the following logic let (expanded_fragment, new_invocations) = if let Some(ext) = ext {

Discussion:
This code ([playpen]) compiles on stable but not on nightly and beta: [playpen]: Standard Error Edit: Removed macro Originally posted by in
modify labels: A-macros A-resolve C-bug T-compiler
I updated the snippet to remove the module.
This is a regression from (cc Slightly more minimized reproduction will look like this: performs eager expansion on its arguments and hygienic context of produced by such expansion looks like it was produced by the opaque for some reason, so it's resolved at ' definition site. It maybe either some issue with hygiene infra interacting with eager expansion, but it also may be caused by incorrect spans produced by .
(I'm currently looking into the details.) UPD: I have a fix locally, will submit tomorrow.
Fixed in

() Errors: If either the recursion () or the is removed (), this compiles exactly as expected. Additionally, if I explicitly name my crate, it works as expected, but would be vulnerable to crate renames in user code (can't reproduce in playground because it doesn't build a library).
If you try and build Rustup, you get a similar failure, but without recursion or . Seems that just using another macro and is enough in some circumstances
cc for the hygiene macro in
This code () compiles on stable but not on nightly and beta:
Please, file a separate issue for the regression, I'll prioritize it over pre-existing issues (which the original issue seems to be).
Thanks, I filed it in
Fixed in
Thanks for your work on this!
Change:
let mut parts = stripped.split('#'); let link = parts.next().unwrap(); <del> if link.trim().is_empty() { </del> <ins> let link = link.trim(); if link.is_empty() { </ins> // This is an anchor to an element of the current page, nothing to do in here! return None; }

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. --: <details<summarycargo bisect-rustc points </summarysearched nightlies: from nightly-2023-01-30 to nightly-2023-02-13 regressed nightly: nightly-2023-02-12 searched commit range: regressed commit: </details label +regression-from-stable-to-nightly +T-rustdoc
cc as author of
Duplicate of
I have a similar problem. Steps to reproduce:
Same issue also reproduces when is documented directly, not as a dependency.
The link in looks like this , not the single backtick and also whitespace. Looks like a mismatch in preprocessing the stuff inside between rustc and rustdoc.
link , extra whitespace.
Oh, yes, this reproduces:
There's still something else going on since AFAICT there are no links in case of
link , extra newlines (?) after the doc strings are merged.
Oh, I was looking at the wrong macro, sorry. :man_facepalming:
I'll try to fix all this stuff tomorrow.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Fixed in
Change:
use mir::visit::MirVisitable; use rustc_apfloat::ieee::{Double, Single}; use rustc_apfloat::Float; <ins> use rustc_data_structures::fx::FxHashSet; </ins> use rustc_data_structures::graph::dominators::{dominators, Dominators}; use rustc_data_structures::graph::{self, GraphPredecessors, GraphSuccessors}; use rustc_data_structures::indexed_vec::{Idx, IndexVec};

Discussion:
review comments:
triage: P-medium. (We should look into this, but even if its wrong, I'm not going to push to a backport its hypothetical bug fix.)

review comments: For the record, here's the relevant part of the test in question ():
This should be NLL-complete, not NLL-sound, right?
Yeah, it should. My bad.
triage: P-high, not not Release milestone. This issue is bad enough for fix quickly, but there's no reason to beta-backport (as I explained on the PR itself here )
Change:
<ins> // Regression test for #74429, where we didn't think that a type parameter // outlived `ReEmpty`. // check-pass use std::marker::PhantomData; fn apply<T, F: FnOnce(T)>(_: T, _: F) {} #[derive(Clone, Copy)] struct Invariant<T> { t: T, p: PhantomData<fn(T) -> T>, } fn verify_reempty<T>(x: T) { // r is inferred to have type `Invariant<&ReEmpty(U0) T>` let r = Invariant { t: &x, p: PhantomData }; // Creates a new universe, all variables from now on are in `U1`, say. let _: fn(&()) = |_| {}; // Closure parameter is of type `&ReEmpty(U1) T`, so the closure has an implied // bound of `T: ReEmpty(U1)` apply(&x, |_| { // Requires `typeof(r)` is well-formed, i.e. `T: ReEmpty(U0)`. If we // only have the implied bound from the closure parameter to use this // requires `ReEmpty(U1): ReEmpty(U0)`, which isn't true so we reported // an error. // // This doesn't happen any more because we ensure that `T: ReEmpty(U0)` // is an implicit bound for all type parameters. drop(r); }); } fn main() {} </ins>

Discussion:
I tried this code: I expected to see this happen: On Rust 1.44.0, this compiles. Instead, this happened: :
For reproduction, the following is used.
This is a regression from stable to nightly.
Let’s bisect this and try to find 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
The code succeeds to compile on 1.44.1 and fails on 1.45, so this is actually a stable-to-stable regression.
Assigning as and removing .
So far I've reduced it to this, which depends only on (without the feature):
: searched nightlies: from nightly-2020-04-20 to nightly-2020-06-02 regressed nightly: nightly-2020-05-25 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: </detailsregressed in
The reproduction does not produce error in . However, I find this throws error on this nightly, as well as on 1.45.0. Here is an even shorter one: The line seems critical. Without this, there will be no reproduction with both snippets. This is also reproducible on the nightly .
cc
The PR that made my reduced code (without ) start successfully compiling again is , in case it helps show what's going on. <details<summaryFull bisect-rustc</summarysearched nightlies: from nightly-2020-05-25 to nightly-2020-07-17 regressed nightly: nightly-2020-06-24 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </summary
Single-crate repro:
I can volunteer myself for looking into the issue. I have a question about the region inference.

Is there a way to visualize, or trace the region inference? Guidance and mentoring instructions are very welcome. :smile:
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. #![feature(closure_to_fn_coercion)] fn main() { let bar: fn(&mut u32) = |_| {}; //~ ERROR mismatched types //~| expected concrete lifetime, found bound lifetime parameter fn foo(x: Box<Fn(&i32)>) {} let bar = Box::new(|x: &i32| {}) as Box<Fn(_)>; foo(bar); //~ ERROR mismatched types //~| expected concrete lifetime, found bound lifetime parameter } </ins>

Discussion:
This code: Produces this internal compiler error: Interestingly, changing to or causes the code compile fine (modulo unused variable warnings). : Backtrace:
This is a regression in 1.17.0-beta. Earlier versions give:
Duplicate of .

Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.
Change:
<ins> error[E0308]: mismatched types --> $DIR/expected-boxed-future-isnt-pinned.rs:11:5 | LL | fn foo<F: Future<Output=i32> + Send + 'static>(x: F) -> BoxFuture<'static, i32> { |        - this type parameter                            ----------------------- expected `std::pin::Pin<std::boxed::Box<(dyn std::future::Future<Output = i32> + std::marker::Send + 'static)>>` because of return type LL |     // We could instead use an `async` block, but this way we have no std spans. LL |     x |     ^ |     | |     expected struct `std::pin::Pin`, found type parameter `F` |     help: you need to pin and box this expression: `Box::pin(x)` | = note:      expected struct `std::pin::Pin<std::boxed::Box<(dyn std::future::Future<Output = i32> + std::marker::Send + 'static)>>` found type parameter `F` = help: type parameters must be constrained to match other types = note: for more information, visit https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
gives The in particular is confusing. This can be a pretty intimidating error message for someone new to async/await, when all they forgot was . I'm not sure if we can fix this without stabilizing so we can sprinkle some magic compiler dust on its error messages. Maybe there's something we can do, though. Maybe some intelligent use of type aliases in our error messages? cc
This can be handled without needing to stabilize the struct. It should act the same way that the primitive type cast suggestions do.
Some observations: There is no struct, it's a type-alias We could suggest invoking but that is a method defined only in the futures crate, which feels a bit awkward to me; I'd rather it were part of libstd We can* suggest as well ()
marking as OnDeck, since BoxFuture gets used quite often
I have a PR that suggests the right code for this: <img width="1269" alt="Screen Shot 2020-02-11 at 5 09 37 PM" src="https://user-"But if first you try : <img width="1271" alt="Screen Shot 2020-02-11 at 5 10 12 PM" src="https://user-"or : <img width="1303" alt="Screen Shot 2020-02-11 at 5 11 11 PM" src="https://user-"we will send you in a wild goose chase: <img width="946" alt="Screen Shot 2020-02-11 at 5 10 53 PM" src="https://user-"
Filed for the uncovered cases.