jiebi/CodeConvo huggingface dataset:
Change:
); } } <ins> } else if let Some(static_def_id) = constant.check_static_ptr(tcx) { let unnormalized_ty = tcx.type_of(static_def_id); let locations = location.to_locations(); let normalized_ty = self.cx.normalize(unnormalized_ty, locations); let literal_ty = constant.literal.ty.builtin_deref(true).unwrap().ty; if let Err(terr) = self.cx.eq_types( normalized_ty, literal_ty, locations, ConstraintCategory::Boring, ) { span_mirbug!(self, constant, "bad static type {:?} ({:?})", constant, terr); } </ins> } <del> if let ty::FnDef(def_id, substs) = constant.literal.ty.kind { let tcx = self.tcx(); </del> <ins> if let ty::FnDef(def_id, substs) = constant.literal.ty.kind { </ins> let instantiated_predicates = tcx.predicates_of(def_id).instantiate(tcx, substs); self.cx.normalize_and_prove_instantiated_predicates( instantiated_predicates,

Discussion:
<!-- 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 : I expected to see this: Instead, happens undefined behavior. Program successfully compiles in the Rust but fails to compile in (thats what I want).
Regressed in , likely cc
Visited in the compiler team triage meeting. It would be good to look into closing this ASAP. do you think you'll have time to investigate? If not, I'd want to find someone else.
We've assigned this speculatively to -- if you think you won't be able to investigate promptly, though, feel free to unassign and ping t-compiler for reassignment,
I expected the behavior to match that of this example (which still errors): I wonder if the gets erased somehow. Maybe an "user type annotation" is required on the from a , to give it a lifetime'd type?
Change:
match self.inner.next() { Some(Event::FootnoteReference(ref reference)) => { let entry = self.get_entry(&reference); <del> let reference = format!("<sup id="supref{0}"><a href="#ref{0}">{0} </del> <ins> let reference = format!("<sup id="fnref{0}"><a href="#fn{0}">{0} </ins> </a></sup>", (*entry).1); return Some(Event::Html(reference.into()));

Discussion:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes
Change:
Rvalue::Use(ref mut operand) => { self.erase_regions_operand(operand) } <del> Rvalue::Repeat(ref mut operand, ref mut constant) => { </del> <ins> Rvalue::Repeat(ref mut operand, ref mut value) => { </ins> self.erase_regions_operand(operand); <del> self.erase_regions_constant(constant); </del> <ins> value.ty = self.tcx.erase_regions(&value.ty); </ins> } Rvalue::Ref(ref mut region, _, ref mut lvalue) => { *region = ty::ReStatic;

Discussion:
See and relevant FIXME in
As a side-note, would solve this problem quite neatly, if we were to adopt and implement it. :)
Change:
<ins> // This is a regression test for <https://github.com/rust-lang/rust/issues/118195>. // It ensures that the "Fields" heading is not generated if no field is displayed. #![crate_name = "foo"] // @has 'foo/enum.Foo.html' // @has - '//*[@id="variant.A"]' 'A' // @count - '//*[@id="variant.A.fields"]' 0 // @has - '//*[@id="variant.B"]' 'B' // @count - '//*[@id="variant.B.fields"]' 0 // @snapshot variants - '//*[@id="main-content"]/*[@class="variants"]' pub enum Foo { /// A variant with no fields A {}, /// A variant with hidden fields B { #[doc(hidden)] a: u8 }, } </ins>

Discussion:
While working on , I noticed that struct variants with no (visible) fields look kinda awkward. ! The Fields heading takes a lot of space without adding particularly much to the content. The easiest solution would be to just remove the heading, but that would show no indication that there exist private fields. The same issue exists in top-level structs as well, but there it is mitigated by having the definition in the code block just above, while for enums there can be a sizeable distance between the two. Any thoughts? Am I just overthinking the whole thing?
No this is a very good point. If there are no fields, we shouldn't add the "Fields" heading. Sending a fix.
Change:
} ty::FnDef(..) | ty::Coroutine(..) | ty::Closure(..) | ty::CoroutineClosure(..) => { <del> bug!("Unexpected coroutine/closure type in variance computation"); </del> <ins> bug!("Unexpected unnameable type in variance computation: {ty}"); </ins> } ty::Ref(region, ty, mutbl) => {

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: Unexpected coroutine/closure type in variance computation', 'error: internal compiler error: Unexpected coroutine/closure type in variance computation' File: --auto-reduced (treereduce-rust): original: 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: [cratevariances] computing the variances for items in this crate [variancesof] computing the variances of [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
smaller
ice since it seems
i can look into this claim
Change:
<ins> error: homogeneous_aggregate: Ok(Homogeneous(Reg { kind: Float, size: Size(4 bytes) })) --> $DIR/homogeneous-aggr-transparent.rs:25:1 | LL | pub type Test0 = Tuple; | ^^^^^^^^^^^^^^ error: homogeneous_aggregate: Ok(Homogeneous(Reg { kind: Float, size: Size(4 bytes) })) --> $DIR/homogeneous-aggr-transparent.rs:29:1 | LL | pub type Test1 = Wrapper1<Tuple>; | ^^^^^^^^^^^^^^ error: homogeneous_aggregate: Ok(Homogeneous(Reg { kind: Float, size: Size(4 bytes) })) --> $DIR/homogeneous-aggr-transparent.rs:33:1 | LL | pub type Test2 = Wrapper2<Tuple>; | ^^^^^^^^^^^^^^ error: homogeneous_aggregate: Ok(Homogeneous(Reg { kind: Float, size: Size(4 bytes) })) --> $DIR/homogeneous-aggr-transparent.rs:37:1 | LL | pub type Test3 = Wrapper3<Tuple>; | ^^^^^^^^^^^^^^ error: homogeneous_aggregate: Ok(Homogeneous(Reg { kind: Float, size: Size(4 bytes) })) --> $DIR/homogeneous-aggr-transparent.rs:41:1 | LL | pub type Test4 = WrapperUnion<Tuple>; | ^^^^^^^^^^^^^^ error: aborting due to 5 previous errors </ins>

Discussion:
On aarch64-unknown-linux-gnu (a tier 1 target), consider this testcase: passes its argument as uses IOW, uses float registers and uses int registers. This violates our promise that types are ABI-compatible. I think this might indicate a bug in the function? At least I don't see anything in the aarch64 adjustment that would be obviously wrong.
This also affects arm32 targets like arm-unknown-linux-gnueabihf.
Yes, that is definitely the issue -- that is heterogeneous.
Should be fixed by
Change:
let fn_ty = func.ty(body, tcx); <del> let (mut callee, substs) = match *fn_ty.kind() { </del> <ins> let (mut callee, mut substs) = match *fn_ty.kind() { </ins> ty::FnDef(def_id, substs) => (def_id, substs), ty::FnPtr(_) => {

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 glacier/fixed/-1.rs <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This is caused by , when we try to resolve the instance for a trait fn we use receiver substs from the , which don't match with the generic params the associated fn expects. This happens when we change the of the callee. What was the intent of that change?
I didn't see the call to after that. I think I basically wanted to replicate the behavior of , when I didn't know that it is already being done. A trivial fix is to just leave that match arm empty.
I tried that, I also tried to just use the identity substs, in which case the resolution succeeds. But in both cases we get another ICE later during monorphization (which I'm not familiar with). This is the backtrace: What does correspond to? Where is the instance for that created and why isn't it local? Could this be related to the changes in your PR? cc
I have no idea what that ICE means. I haven't touched code in that backtrace.
That ICE resulted from some debugging code I had included, sorry for the confusion.
Change:
<ins> error[E0308]: mismatched types --> $DIR/variance-associated-types2.rs:13:42 | LL |     let _: Box<dyn Foo<Bar = &'a u32>> = make(); |                                          ^^^^^^ lifetime mismatch | = note: expected trait object `dyn Foo<Bar = &'a u32>` found trait object `dyn Foo<Bar = &'static u32>` note: the lifetime `'a` as defined on the function body at 12:9... --> $DIR/variance-associated-types2.rs:12:9 | LL | fn take<'a>(_: &'a u32) { |         ^^ = note: ...does not necessarily outlive the static lifetime error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
IIUC currently a trait object is always covariant in its associated types, regardless of their positions. This makes it possible to pass a non-static reference to a function expecting a static reference:
With rustc 1.0.0 ..= 1.16.0, the following error was emitted:
-- this looks plausibly similar to , but I don't know enough to be certain.
Oh wow how are these not invariant? Cc
Assigning as and removing .
Just in case, in my last action I've removed by accident and it back :).
Wait, these are supposed to be invariant. This is definitely a bug. It would be great to figure out just which nightly regressed this, maybe somebody can run cargo bisect? cleanup
Er, I guess I meant this? 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
searched toolchains nightly-2016-06-01 through nightly-2020-01-01 regression in nightly-2017-03-12 ... Previous error message: I used a slightly modified variant (just removed the IIRC): <details<summaryCode used</summary</details
Most likely candidate seems to be , cc
Thanks! Super useful.
After discussing a bit with this sounds more like than .
modify labels:-E-needs-bisection
Crater run from the fix (thanks to for the analysis). I was thinking about that and I realize that it's plausible that we could do variance inference on associated types and use that to inform the variance for types. It is sensible, for example, that a is covariant with respect to (that is the trait used in one of the affected examples). I'm a bit nervous about this though. For one thing, the core operations exposed by a type are clearly just its methods, but people can also project out from types (though that projection is generally considered invariant over the input types). But for another, it seems to give rise to some asymmetry and complexity around traits and variance that we have thus far avoided (and which I might prefer to continue to avoid).
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. type Value = String; fn main() { let f = |&Value::String(_)| (); //~ ERROR no associated item named let vec: Vec<Value> = Vec::new(); vec.last().map(f); } </ins>

Discussion:
I got panic with this code (): Backtrace: My rust version:
This code seems to be minimal example type Value = String; fn main() { let f = ""; Some("".into()).map(f); }
Change:
//  Utility Functions //=----------------------------------------------------------------------------- <ins> fn contains_nodebug_attribute(attributes: &[ast::Attribute]) -> bool { attributes.iter().any(|attr| { let meta_item: &ast::MetaItem = &*attr.node.value; match meta_item.node { ast::MetaWord(ref value) => value.get() == "no_debug", _ => false } }) } </ins> /// Return codemap::Loc corresponding to the beginning of the span fn span_start(cx: &CrateContext, span: Span) -> codemap::Loc { cx.sess().codemap().lookup_char_pos(span.lo)

Discussion:
Right now debuginfo can only be turned on or off globally. Sometimes it would be good to be able to exclude only specific functions from debuginfo, especially when they trigger a bug in rustc's or LLVM's debuginfo handling (e.g. ). This way, one would be able to still mostly use debuginfo in the presence of (localized) debuginfo issues.
Change:
#[cfg(unix)] use crate::os::unix::fs::symlink as symlink_junction; #[cfg(windows)] <del> use crate::os::windows::fs::{symlink_dir, symlink_file}; </del> <ins> use crate::os::windows::fs::{symlink_dir, symlink_file, OpenOptionsExt}; </ins> #[cfg(windows)] use crate::sys::fs::symlink_junction; #[cfg(target_os = "macos")]

Discussion:
Reported on discord, using will fail on Windows if the file is hidden. This also affects methods like or that open the file the same way. The reason for this is that we use , which has : So to make it work the caller needs to match the requested attributes to the existing attributes at the time of opening. It was suggested we could instead use and then manually truncate the file using to zero.
Manually truncating would require also clearing the alternate data streams too, right? And it would presumably stop erroring if another process still has the file open and instead corrupt the file fron the view of the other process.
No? The proposed solution would work the same was as in the case where the file already exists. Which we use for .
Right, got confused with .
Change:
return; } <ins> // We place free regions first because we are special casing // SubSupConflict(ReFree, ReFree) when reporting error, and so // the user will more likely get a specific suggestion. fn free_regions_first(a: &RegionAndOrigin, b: &RegionAndOrigin) -> Ordering { match (a.region, b.region) { (ReFree(..), ReFree(..)) => Equal, (ReFree(..), _) => Less, (_, ReFree(..)) => Greater, (_, _) => Equal, } } lower_bounds.sort_by(|a, b| { free_regions_first(a, b) }); upper_bounds.sort_by(|a, b| { free_regions_first(a, b) }); </ins> for lower_bound in lower_bounds.iter() { for upper_bound in upper_bounds.iter() { if !self.is_subregion_of(lower_bound.region,

Discussion:
For the input file below, the two distinct invocations of (but with identical arguments) are non-deterministically deciding whether or not to prompt with the "consider using an explicit lifetime parameter" hint. Input file (): Transcript: (See also for a problem with the suggestion actually provided by when it chooses to actually provide one.)
I tested it a bit, and the issue seems to be is fed slightly different information each time. In the first case we have a and in the second . In the constraint graph for some node we are trying to infer, there are multiple incoming edges and outgoing edges to and from . From my understanding the compiler only picks one node from these incoming edges and one node from these outgoing edges, and it doesn't pick the same pair each time (what I don't understand is why I didn't see the and variations).
I'm getting a non-deterministic error message using the latest nightlies: It's non-deterministic on my Fedora 20 machine but not my OSX machine.
Change:
<ins> // Copyright 2014 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. use std::io::FileType; pub fn main() { let _ = FileType::TypeFile.clone(); } </ins>

Discussion:
Hi guys! Is there any reasons, why () can't be cloned? It is the only non-clonable part of , which makes the entire struct non-clonable either.
Looks like an oversight. CC
Hey! If this is confirmed as oversight, can I add trait to FileType and address this issue? Or should this be addressed as part of
Go for it! isn't something that'll be fixed in one commit, it's an ongoing effort.
Change:
let crate_types = sess.crate_types.borrow(); let num_crate_types = crate_types.len(); let is_proc_macro_crate = crate_types.contains(&config::CrateTypeProcMacro); <ins> let is_test_crate = sess.opts.test; </ins> syntax_ext::proc_macro_registrar::modify(&sess.parse_sess, &mut resolver, krate, is_proc_macro_crate, <ins> is_test_crate, </ins> num_crate_types, sess.diagnostic(), &sess.features.borrow())

Discussion:
I setup a crate using the example from There are no tests setup: no tests folder, no #[test] attributes. succeeds fails with: #[procmacroderive]proc-macro Naturally I expected this error not to occur. Run on the latest nightly via rustup: rustc 1.14.0-nightly ( 2016-10-27) binary: rustc commit-hash: commit-date: 2016-10-27 host: x86_64-unknown-linux-gnu release: 1.14.0-nightly LLVM version: 3.9
You can probably work around this by using (although I haven't tested that).
Thanks for the report! I'm not sure what the best way to solve this would be. We could either tell the compiler that doesn't work for these crate types, or we could tell Cargo to not test proc-macro libraries. Both should have the end goal though of having work by default.
Would a simple fix for this be to add to ? Or should - where it currently panics - quietly bail out if this is a test crate?
I'd personally prefer for to keep doing the same feature gating it's doing today, so in that sense I don't think it should take the same bail-out route that rustdoc takes. Adding some logic to though sounds good to me.
I think it was wrong that this ticket was closed with since it states
Actually fixing this appears simpler than I expected. I'm guessing a should be enough. This will ensure all the feature gating is still done, but no expansion is performed. Did you have any further thoughts?
of it works it works for me!
this is failing again. It works correctly on nightly-2017-01-17 rustc 1.16.0-nightly ( 2017-01-17) but fails on nightly-2017-01-18 rustc 1.16.0-nightly ( 2017-01-17).
This could be related to recently enabling doc-testing of proc-macro crates in cargo This rustc change should fix that If you look at the cargo output, does the error happen when running the normal tests, or after trying to run doc-tests? Edit: I've tested this in the latest nightly from rustup, and this is definitely what is happening. Hopefully it will be fixed soon.

thanks for staying on top of this! I've approved and p=1'd it to hopefully get it in soon. sorry for the breakage!
Change:
// Return value is only `Some` if the level is `Error` or `DelayedBug`. fn emit_diagnostic(&mut self, mut diagnostic: DiagInner) -> Option<ErrorGuaranteed> { <ins> match diagnostic.level { Expect(expect_id) | ForceWarning(Some(expect_id)) => { // The `LintExpectationId` can be stable or unstable depending on when it was // created. Diagnostics created before the definition of `HirId`s are unstable and // can not yet be stored. Instead, they are buffered until the `LintExpectationId` // is replaced by a stable one by the `LintLevelsBuilder`. if let LintExpectationId::Unstable { .. } = expect_id { // We don't call TRACK_DIAGNOSTIC because we wait for the // unstable ID to be updated, whereupon the diagnostic will be // passed into this method again. self.unstable_expect_diagnostics.push(diagnostic); return None; } // Continue through to the `Expect`/`ForceWarning` case below. } _ => {} } </ins> if diagnostic.has_future_breakage() { // Future breakages aren't emitted if they're `Level::Allow`, // but they still need to be constructed and stashed below,

Discussion:
<!-- [31mICE[0m: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: matches!(, Error Allow)'' 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: [earlylintchecks] perform lints prior to macro expansion [hircrate] getting the crate HIR -- label +F-stmtexpr_attributes
bisects to :thinking: cc edit: ah the assertion was there...
Change:
pub fn trans_block<'a>(bcx: &'a Block<'a>, b: &ast::Block, <del> dest: expr::Dest) </del> <ins> mut dest: expr::Dest) </ins> -> &'a Block<'a> { let _icx = push_ctxt("trans_block"); let fcx = bcx.fcx;

Discussion:
Was trying to find another bug, found this bug! That code will fail with
I'll take it
Different testcases: EDIT: Found more testcases
Interesting. I'm looking into it. Not sure what is causing this, though.
Another testcase: (The and are both necessary.)
Even simpler example: Debug Log EDIT: Making the block return doesn't raise this issue.
My final testcase:
Could this be related to the no-argument version of lambda block expressions that were used in syntax? Looking in , there's a comment to this form of lambda expressions used with . As far as why doesn't raise the issue, maybe that's parsed as a block expression instead?
I don't see how it could be related. The error here has to do with a (or just zero-sized? I'm not sure) result of a block being stored somewhere. I'm not even sure the assert needs to be that strict.
Yet another test case to consider:
thanks! I'll get back to debug this in a bit
Change:
} } <ins> /// Processes registered region obliations and resolves regions, reporting /// any errors if any were raised. Prefer using this function over manually /// calling `resolve_regions_and_report_errors`. </ins> pub fn check_region_obligations_and_report_errors( &self, generic_param_scope: LocalDefId,

Discussion:
into causes an internal compiler panic This causes an internal compiler error: This seems related to , except this is using
:
This is not specific to . The following produces the same kind of error.
modify labels: +regression-from-stable-to-stable The ICE happens on stable regardless of having the feature gate or not (the ICE does not requires a nightly compiler to reproduce)
Change:
<ins> error[E0161]: cannot move a value of type str: the size of str cannot be statically determined --> $DIR/issue-67947.rs:2:13 | LL |     A: [(); { *"" }.len()], |             ^^^^^^^ error[E0507]: cannot move out of a shared reference --> $DIR/issue-67947.rs:2:15 | LL |     A: [(); { *"" }.len()], |               ^^^ move occurs because value has type `str`, which does not implement the `Copy` trait error: aborting due to 2 previous errors Some errors have detailed explanations: E0161, E0507. For more information about an error, try `rustc --explain E0161`. </ins>

Discussion:
The following ICE's on stable, beta and nightly: <details<summaryBacktrace:</summary</detailsPossibly related to , except with a different ICE message.
The bug here should be delayed:
triage: P-medium, removing I-nominated label.