jiebi/CodeConvo huggingface dataset:
Change:
Ok(ty::Visibility::Restricted(DefId::local(CRATE_DEF_INDEX))) } ast::VisibilityKind::Inherited => { <del> Ok(ty::Visibility::Restricted(parent_scope.module.normal_ancestor_id)) </del> <ins> if matches!(self.parent_scope.module.kind, ModuleKind::Def(DefKind::Enum, _, _)) { // Any inherited visibility resolved directly inside an enum // (e.g. variants or fields) inherits from the visibility of the enum. let parent_enum = self.parent_scope.module.def_id().unwrap().expect_local(); Ok(self.r.visibilities[&parent_enum]) } else { // If it's not in an enum, its visibility is restricted to the `mod` item // that it's defined in. Ok(ty::Visibility::Restricted(self.parent_scope.module.normal_ancestor_id)) } </ins> } ast::VisibilityKind::Restricted { ref path, id, .. } => { // For visibilities we are not ready to provide correct implementation of "uniform

Discussion:
Test example (): Only in the top level should say "cannot construct ... due to inaccessible fields", the other 3 errors should be "missing field ... in initializer", but it seems like it's treating the field as private (even though it inherits from the ). The "cannot construct ... due to inaccessible fields" error seems to be new in 1.48, as part of , and unmodified since. It's using which seems correct, but it's possible fields are incapable of giving the right result, if they don't track the 's own privacy (and they only know they inherit it, whatever it is). cc
I would also suspect
I ran into this too, but I couldn't make a repro. Thanks eddyb!
P-high: I've run into this a bunch of times and I imagine others have too. It's really annoying and confusing, likely even more so for newcomers!
searched nightlies: from nightly-2020-08-01 to nightly-2020-10-15 regressed nightly: nightly-2020-09-11 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Seems very likely that this is due to , as eddyb said. EDIT: Though, as jyn514 suggested, the underlying bug could be , which was then surfaced in .
Update: I've been reading the source code and print-debugging and I think the issue was not introduced in either of those two PRs, but rather that they surfaced a pre-existing issue.
Well, it took a while, but I think I fixed it!
Does this necessitate a 1.48.1 release or shall I wait for 1.49?
it will be in 1.50 unless backported:
Ok. Thank you for the quick reply.
Change:
<ins> // Test that async fn works when nested inside of // impls with lifetime parameters. // // check-pass // edition:2018 #![feature(async_await)] struct Foo<'a>(&'a ()); impl<'a> Foo<'a> { fn test() { async fn test() {} } } fn main() { } </ins>

Discussion:
The following breaks on nightly (see ) With: CC: dtolnay/async-trait
Reduced:
Forgot to mention in case this helps, giving the inner fn a matching lifetime avoids this issue for some reason:
The reason this is happening is that the desugared version of applies all in-scope lifetimes to the returned existential type, which in this case is creating , which is invalid. I'm not sure exactly what the best fix is for this, though, since elided lifetimes in the impl signature are intentionally unnameable. The closest idea I have would be to create some special new lifetime that is but can refer to lifetimes originating from the impl header. cc who may have opinions.
Hmm wouldn't you expect the nested to not inherit anything from its enclosing scopes? Seems like a bug to me that it does? Am I confused about something?
The function in the middle is actually a bit of a source of confusion here, although it does indicate that there's a second bug since we shouldn't be inheriting generics since the nested isn't part of the . The bug I was focusing on is better illustrated by this example: which produces this error: This is because the code is transformed into and in that case does not refer back to the usage from the header.
I see. Indeed, I would expect that, internally, we'd have some way to refer back to the from the impl header. I believe this should be possible, no? In particular, the in impls expands (internally) to for some integer N, which I believe is basically treated like any other named lifetime.
Yep, I would've expected so as well-- I'm not sure why that isn't working, I'd have to take a look.
I was looking and I think the bug lies here: Probably needs to be a instead, or we need to use something else for this purpose.
A closer reading suggests I was mistaken. The lifetimes from the impl should show up in -- includes only the explicitly declared lifetimes written by the user on the impl. I'm not quite sure what the problem is yet.
OK, no, I was correct. When processing impl items, we convert the lifetimes into entries. EDIT: Er, I'm still not entirely sure. Reading more. =)
OK, I have a fix for the method issue, but not the nested async fn item issue.

I forked off for the method issue
I didn't prep a fix for this one yet. It seems obvious that some internal state is not being reset when we enter a new item.
but if you have a chance to investigate, would be appreciated
Presumably the problem is that doesn't "reset" the vector -- it only seems to extend it...
Indeed, in-band lifetimes are broken in the same way. This fails to compile ():
Working on a possible fix
Yep, have a fix.
Inband lifetimes looks similar to fwiw
thanks
Change:
display } <ins> /// Find the position of a field named `ident` in `base_def`, accounting for unnammed fields. /// Return whether such a field has been found. The path to it is stored in `nested_fields`. /// `ident` must have been adjusted beforehand. fn find_adt_field( &self, base_def: ty::AdtDef<'tcx>, ident: Ident, nested_fields: &mut SmallVec<[(FieldIdx, &'tcx ty::FieldDef); 1]>, ) -> bool { // No way to find a field in an enum. if base_def.is_enum() { return false; } for (field_idx, field) in base_def.non_enum_variant().fields.iter_enumerated() { if field.is_unnamed() { // We have an unnamed field, recurse into the nested ADT to find `ident`. // If we find it there, return immediately, and `nested_fields` will contain the // correct path. nested_fields.push((field_idx, field)); let field_ty = self.tcx.type_of(field.did).instantiate_identity(); let adt_def = field_ty.ty_adt_def().expect("expect Adt for unnamed field"); if self.find_adt_field(adt_def, ident, &mut *nested_fields) { return true; } nested_fields.pop(); } else if field.ident(self.tcx).normalize_to_macros_2_0() == ident { // We found the field we wanted. nested_fields.push((field_idx, field)); return true; } } false } </ins> // Check field access expressions fn check_field( &self,

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'forcing query with already existing '', 'thread 'rustc' panicked at 'forcing query with already existing '' 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 [findfield] find the index of maybe nested field in [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to :thinking:
WG-prioritization assigning priority (). cc: + for label -I-prioritize +P-medium
I'm going to fix it in (still WIP), where the query will be removed.
Testing out on this issue:
I seems like does not have proper or impls, possibly due to the differing . Are you familiar with that part of spans?
Change:
/// Error type for `tcx.lit_to_const`. #[derive(Copy, Clone, Debug, Eq, PartialEq, HashStable)] pub enum LitToConstError { <ins> /// The literal's inferred type did not match the expected `ty` in the input. /// This is used for graceful error handling (`delay_span_bug`) in /// type checking (`AstConv::ast_const_to_const`). TypeError, </ins> UnparseableFloat, Reported, }

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on and , but not on . <details<summaryNightly backtrace</summary</details
triage: P-high, assigning to self.
(This ended up being a great motivation for me to tie off some work I've been doing...)
ICE was introduced between nightly 2020-01-15 and 2010-01-16. Here are the merges from that time period: ( is independently working to identify which one is the culprit.)
Okay finished: searched nightlies: from nightly-2020-01-15 to nightly-2020-01-22 regressed nightly: nightly-2020-01-16 searched commits: from to regressed commit:
Looks like the problem was injected by PR
reassigning to
The following also causes an ICE: (Same reason, but different message.)
Fixed by
Change:
<ins> fn main() { expr as fun()(:); //~ ERROR expected expression } </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
Report from : searched nightlies: from nightly-2020-01-09 to nightly-2020-03-30 regressed nightly: nightly-2020-03-08 searched commits: from to regressed commit:
is the cause. Reduced to: clarified to: clarified further to:
Change:
operand, &mut |elem, op| match elem { TrackElem::Field(idx) => self.ecx.project_field(op, idx.as_usize()).ok(), <del> TrackElem::Variant(idx) => { if op.layout.for_variant(&self.ecx, idx).abi.is_uninhabited() { return None; } self.ecx.project_downcast(op, idx).ok() } </del> <ins> TrackElem::Variant(idx) => self.ecx.project_downcast(op, idx).ok(), </ins> TrackElem::Discriminant => { let variant = self.ecx.read_discriminant(op).ok()?; let discr_value =

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:
pub(crate) use cpuid::codegen_cpuid_call; pub(crate) use llvm::codegen_llvm_intrinsic_call; <ins> use rustc_middle::ty::layout::HasParamEnv; </ins> use rustc_middle::ty::print::with_no_trimmed_paths; use rustc_middle::ty::subst::SubstsRef; use rustc_span::symbol::{kw, sym, Symbol};

Discussion:
It seems that the prefix is used more often than , so we should swap the function names before 0.1.
We're probably going the other direction -
Done.
Change:
<ins> fn main() { () < std::mem::size_of::<_>(); //~ ERROR: mismatched types [0u8; std::mem::size_of::<_>()]; //~ ERROR: type annotations needed } </ins>

Discussion:
Minimal example:
can you reproduce?
I can try, this is from Mar 2nd so not related to my recent changes right?
yes it fails for me with both stable rust 1.25 and the latest nightly rustc 1.27.0-nightly ( 2018-04-11). It's not failing in a part of typeck that I'm familiar with but I'll have a look sometime and see if it makes any sense to me.
Yes this is unrelated to that PR (I think there isn't a nightly including it yet). But since this is related to I thought you might want to take a look.
I started expanding the minimal example so that it didn't depend on nalgebra, it has expanded into quite a lot of code This example is enough to break the compiler but doesn't compile if the ICE is fixed (e.g. if the is commented out). For it to compile it still needs some external dependencies. It appears to be the associated type that is hitting the ICE.
Yeah 's example is huge. Maybe he doesn't know that minimal examples should have no dependencies. if you don't provide minimal examples in bug reports (that is: no dependencies; they should compile in the play ground) they'll take much longer than necessary to fix.
I understand. I'm a relative beginner to rust, so it would take quite a lot of time for me to figure out how to make a more minimal example. I am able to work around this issue in my own code, so it's not that important to me, but I figured it might be easy for someone more experienced to spot what was going wrong. If you don't think it's worth the effort to investigate further, I have no problem with you closing this until a more simple manifestation is discovered.
I've reduced it to the following ():
It's no longer reproduced an ICE on the latest nightly, it seems from 1.38.0. marked as E-needstest
Change:
/// The smallest useful subset of `const_generics`. (accepted, min_const_generics, "1.51.0", Some(74878), None), /// The `unsafe_op_in_unsafe_fn` lint (allowed by default): no longer treat an unsafe function as an unsafe block. <del> (accepted, unsafe_block_in_unsafe_fn, "1.51.0", Some(71668), None), </del> <ins> (accepted, unsafe_block_in_unsafe_fn, "1.52.0", Some(71668), None), </ins> /// Allows the use of or-patterns (e.g., `0 | 1`). (accepted, or_patterns, "1.53.0", Some(54883), None),

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 this code on nightly Rust: This produced a warning claiming that was stabilized in 1.51: I removed the feature gate and tried compiling the code on Rust 1.51.0: However, this led to an error claiming that is unstable: <!-- 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. --: : modify labels: +A-diagnostics +D-incorrect +F-unsafe-block-in-unsafe-fn
According to the milestone on the stabilization PR (), this feature will be stabilized in 1.52, but the PR wasn't updated to account for this.
Thanks for the report, yeah, the stabilized version should be wrong. Submitted as a fix.
Change:
|()| unsafe { if !llvm::LLVMRustLinkInExternalBitcode(llmod, ptr as *const libc::c_char, <del> bc.len() as libc::size_t) { </del> <ins> bc_decoded.len() as libc::size_t) { </ins> link::llvm_err(sess, format!("failed to load bc of `{}`", name.as_slice()));

Discussion:
There's another bug in LLDB that causes it to segfault when reading archive files. This one has already been fixed in May () but it still exists in a lot of LLDB binaries out there. As far as I can tell, the bug occurs when a number of object files are stored in an archive and the last one ends at an uneven byte offset. This often seems to be the case for compressed byte-code archives in rlibs (maybe regular object files are always padded to an even size?). I'm currently compiling a possible workaround (pad the bytecode objects to an even size). It would be good if we could allow for rust code to be debugged with older LLDB versions too.
Update: Padding all archives entries to an even size seems to prevent the crash in LLDB and I have not seen any detrimental side effects to this approach so far. Any idea if the additional padding byte at the end of the compressed LLVM IR object in an archive could potentially lead to a problem?
I'm not familiar enough with the format of object files or bytecode files to know whether an extra byte or two at the end would corrupt them, but if it's working ok currently then I'd just ship it!
I doubt that the containing archive will care about the padding byte, but either the decompression algorithm or the LLVM bitcode reader could trip over it. The safe way to do this would probably be to prepend the actual size of the compressed data, so we always know how much data to pass to . I guess, I'll implement this and make a pull request.
Thinking about it, changing the format here is not as so trivial since the compiler must handle libs with the old format differently from libs with the new format. I see two options: (1) Just add the padding byte and hope for the best (2) Introduce some kind of header (including a version byte) before the compressed bitcode, in order to future-proof this against other changes to the encoding. I think I'd favor option (2).
Is this only a problem for the bytecode in archives, or is it also a problem for object files?
So far it has only occurred for bytecode. All object files I came across had a size dividable by 2. I don't know if that's a coincidence...
Interesting!

I'm all for putting the bytecode in whatever format we want (it's already just a huge deflated stream)
I'll come up with something and then we can discuss the matter further when we have some code to look at in a PR, OK?
Sounds good to me!
Change:
<ins> #![allow(dead_code)] extern "C" { fn rust_interesting_average(_: i64, ...) -> f64; } fn test<T, U>(a: i64, b: i64, c: i64, d: i64, e: i64, f: T, g: U) -> i64 { unsafe { rust_interesting_average( 6, a as f64, b, b as f64, f, c as f64, d, d as f64, e, e as f64, f, g, //~ ERROR use of moved value: `f` [E0382] ) as i64 } } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 5'', 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 5'' 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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
bisects to cc
Thank you. claim
Change:
|                 ^^^^ `str` cannot be indexed by `{integer}` | = help: the trait `std::ops::Index<{integer}>` is not implemented for `str` <ins> = note: you can use `.chars().nth()` or `.bytes().nth()` see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings> </ins> error: aborting due to previous error

Discussion:
The following buggy code: produces the error: This is usefully documented in TRPL (ch08-02-strings), but that is not easily discoverable from the error. Meanwhile, the error itself is a natural one that programmers from many languages (C, C++, etc) might run into. Speaking as someone who spent some time assuming that the issue was related to slices/references/usize (i.e. various new, Rust-specific concepts), not strings and UTF-8 encoding, I wonder whether a special case might be produced, replacing error E0277, when the types involved are specifically strings/strs and integers. :
We should add a pointing to in the following code of E0277 errors. The example has a similar case to this one, but the additional code should be something along the lines of This will cause an extra to be displayed for this case. Beyond changing the code, you will also need to add a new test case with the repro case above and (running and possibly updating the test comments for any remaining failing tests).
I would like to work on this.
do not hesitate to reach out either here or on if you need help!
Possible proposed output from :
Change:
self, def_id: DefId, ) -> impl Iterator<Item = ty::EarlyBinder<Ty<'tcx>>> { <del> let generator_layout = &self.mir_generator_witnesses(def_id); </del> <ins> let generator_layout = self.mir_generator_witnesses(def_id); </ins> generator_layout <del> .field_tys .iter() </del> <ins> .as_ref() .map_or_else(|| [].iter(), |l| l.field_tys.iter()) </ins> .filter(|decl| !decl.ignore_for_traits) .map(|decl| ty::EarlyBinder(decl.ty)) }

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
regression in cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic
Change:
<del> //! Codegen the completed AST to the LLVM IR. //! //! Some functions here, such as codegen_block and codegen_expr, return a value -- //! the result of the codegen to LLVM -- while others, such as codegen_fn //! and mono_item, are called only for the side effect of adding a //! particular definition to the LLVM IR output we're producing. </del> <ins> //! Codegen the MIR to the LLVM IR. </ins> //! //! Hopefully useful general knowledge about codegen: //! <del> //! * There's no way to find out the `Ty` type of a Value. Doing so </del> <ins> //! * There's no way to find out the [`Ty`] type of a [`Value`]. Doing so </ins> //!   would be "trying to get the eggs out of an omelette" (credit: <del> //!   pcwalton). You can, instead, find out its `llvm::Type` by calling `val_ty`, //!   but one `llvm::Type` corresponds to many `Ty`s; for instance, `tup(int, int, //!   int)` and `rec(x=int, y=int, z=int)` will have the same `llvm::Type`. </del> <ins> //!   pcwalton). You can, instead, find out its [`llvm::Type`] by calling [`val_ty`], //!   but one [`llvm::Type`] corresponds to many [`Ty`]s; for instance, `tup(int, int, //!   int)` and `rec(x=int, y=int, z=int)` will have the same [`llvm::Type`]. //! //! [`Ty`]: rustc_middle::ty::Ty //! [`val_ty`]: common::val_ty </ins> use super::ModuleLlvm;

Discussion:
The reference functions named and , but those functions anywhere in rustc. It seems the docs for this module have , so perhaps that is why?
modify labels to T-doc C-enhancement
It looks like has the .
modify labels: A-codegen
I finally have enough knowledge to fix these!
Change:
<ins> fn main() { let iter_fun = <&[u32]>::iter; //~^ ERROR no function or associated item named `iter` found for reference `&[u32]` in the current scope [E0599] //~| function or associated item not found in `&[u32]` //~| HELP the function `iter` is implemented on `[u32]` for item in iter_fun(&[1,1]) { let x: &u32 = item; assert_eq!(x, &1); } } </ins>

Discussion:
Given the following code (): The current output is: This suggestion is on the right track, but unfortunately it introduces a parse error. It should be: This suggestion is in . It suggests adding around the type because the type is a slice, but I already have in my program (and the span doesn't include the existing ). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim