jiebi/CodeConvo huggingface dataset:
Change:
<ins> #![feature(marker_trait_attr)] #[marker] trait A {} impl<'a> A for (&'static (), &'a ()) {} //~ ERROR type annotations needed impl<'a> A for (&'a (), &'static ()) {} //~ ERROR type annotations needed fn main() {} </ins>

Discussion:
() same code with an additional line of whitespace/comments where indicated: however, the playground seems to behave different from my local nightly here Tested on label T-compiler requires-nightly F-markertraitattr A-traits A-typesystem and someone please add “I-unsound ”
ACTUALLY… the error after adding the whitespace disappears again with . Which would explain why it isn’t reproducable in the playground. Might be related to label A-incr-comp.
This test doesn't seem to compile with the most recent nightly but I don't think the underlying issue has been fixed. Not sure how to retrigger this issue
Change:
<del> Subproject commit 788592fb2740d560d0614a77035b319b9d07aa38 </del> <ins> Subproject commit 1bbe0b3e1d756116cbf1fcf049555066ef929008 </ins>

Discussion:
Trying to build rustc with Visual Studio 2019 Build Tools results in the following error: I've tried version versions 16.1.1 and 16.1.3 on different machines with the same result. Visual Studio 2017 Build Tools work fine. Is there some magic incantation I'm missing?
I get this as well. I've been hacking around it with I think this was introduced in , so cc
I don't think that anything is being missed here. This is probably a bug with either: An upstream compiler-rt bug that needs to be fixed A bug with how we build compiler-rt since we're not using the standard build system The former may already even be fixed upstream, the latter is probably some missing flag we're not passing and would require inspecting the source. In both cases the source needs to be inspected likely :)
was applied to our fork, but it was lost somehow, breaking VS 2019 builds.
Change:
/// from at least one local module and returns true. If the crate defining `def_id` is /// declared with an `extern crate`, the path is guaranteed to use the `extern crate`. fn try_print_visible_def_path( <ins> self, def_id: DefId, ) -> Result<(Self, bool), Self::Error> { let mut callers = Vec::new(); self.try_print_visible_def_path_recur(def_id, &mut callers) } /// Does the work of `try_print_visible_def_path`, building the /// full definition path recursively before attempting to /// post-process it into the valid and visible version that /// accounts for re-exports. /// /// This method should only be callled by itself or /// `try_print_visible_def_path`. /// /// `callers` is a chain of visible_parent's leading to `def_id`, /// to support cycle detection during recursion. fn try_print_visible_def_path_recur( </ins> mut self, def_id: DefId, <ins> callers: &mut Vec<DefId>, </ins> ) -> Result<(Self, bool), Self::Error> { define_scoped_cx!(self);

Discussion:
I have three crates: (library), (library), and (binary). has no dependencies, and its is just: has the following dependency and : has the following dependency and : The following error happens running or in crate : Try as I may, I can't manage to make the error happen without putting in every one of those lines and dependencies. EDIT: the bug only requires , not
pre-triage: P-high, removing nomination tag. assigning to self for initial investigation.
(seems to me like the line is not necessary to reproduce the bug?) ((but the nonetheless does remain necessary for reproduction....))
Here is a shell script to compile the files using itself (so we get out of the way) and run the compile of under :
and the backtrace from gives us a pretty good hint as to where we might be infinite-looping: (and so on, for at least 15,000 stack frames...)
(prior to rust 1.35.0, it seems like we might have infinite looped here with no stack overflow. Not 100% sure of that yet; and this test case currently relies on 2018 edition, so its not easy to go back to earlier than 1.31.0)
Also, you can inline the contents of crate a into crate b and preserve the erroneous behavior:
Okay I think I have a solution for this. Hope to post PR today or tomorrow.
Change:
param_substs, callee_substs) } <ins> traits::VtableObject(ref data) => { let trait_item_def_ids = ty::trait_item_def_ids(ccx.tcx(), trait_id); let method_offset_in_trait = trait_item_def_ids.iter() .position(|item| item.def_id() == method_id) .unwrap(); let (llfn, ty) = trans_object_shim(ccx, data.object_ty, trait_id, method_offset_in_trait); immediate_rvalue(llfn, ty) } </ins> _ => { tcx.sess.bug(&format!("static call to invalid vtable: {}", vtbl.repr(tcx))[]);

Discussion:
Discovered this ICE in the rollup that I'm preparing:
In Grust, I tried to change to: The crate compiles without an issue, but compiling another crate where this is used results in an ICE that looks to be this one.
Looks like I missed a case in
Nominating for 1.0 beta.
Are there any known workarounds for this problem? I ran into this in a hard way trying to update to the newest nightlies.
not sure, I'll try to get a PR up today
a new type wrapper around the object would probably work, ping me on irc () for more details
I just wanna run iron example on MAC 10.10 with rust-nightly, the same error occurs, I don't know if it's of the same case: error: internal compiler error: static call to invalid vtable: VtableObject(VtableObject(object_ty=error::Error + 'static))
This is also blocking Iron, which itself compiles well, but using the crate fails:
Fix in , sorry for the delay.
thanks for the work! I pulled your PR and built with it, and my code compiles again. Hooray!
Change:
) -> Result<&'tcx Layout, LayoutError<'tcx>> { use SavedLocalEligibility::*; let tcx = self.tcx; let subst_field = |ty: Ty<'tcx>| ty.subst(tcx, substs); <del> let info = tcx.generator_layout(def_id); </del> <ins> let info = match tcx.generator_layout(def_id) { None => return Err(LayoutError::Unknown(ty)), Some(info) => info, }; </ins> let (ineligible_locals, assignments) = self.generator_saved_local_eligibility(&info); // Build a prefix layout, including "promoting" all ineligible

Discussion:
See below:
Reduced to only use the task proc-macro: It seems important, that Foo isn't defined, if I define a , the ICE goes away.
searched nightlies: from nightly-2020-06-01 to nightly-2021-01-01 regressed nightly: nightly-2020-10-27 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: </detailsI'm pretty sure that isn't at fault here, but instead it just uncovers the problem.
MCVE:
Panic location:
Change:
// Checks that only make sense for the compiler. check!(error_codes, &root_path, &[&compiler_path, &librustdoc_path], verbose); check!(fluent_alphabetical, &compiler_path, bless); <ins> check!(target_policy, &root_path); </ins> // Checks that only make sense for the std libs. check!(pal, &library_path);

Discussion:
(wrapped by hand to make the problem clear) The function pointer alignment is the same as our powerpc64-unknown-linux-gnu target, so the discrepancy must be in LLVM. While this is a tier 3 target, we are completely unable to generate code for it, so at some point this part of the target tier policy will become relevant (emphasis mine): If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (there are none, not even for the Tier 2 -gnu variant) (and potentially other people who have previously worked on the target), to check potential interest in improving the situation. I have trawled the issue tracker and I cannot find any evidence that this target is in use; all issues seem related to or the targets.
Does this also impact ppc64le? That's supported by Alpine, which uses musl. It looks like is the maintainer with musl. Not knowing anything about ppc, or very much about LLVM's data layouts, it looks like may be what broke this.
powerpc64le is not affected. Unfortunately looking at that diff I still can't figure out which of the targets is correct.
So I'm running into this in , the relevant code in LLVM is: () () We get rather than because of the musl-ness of the target. As far as I can tell, this would have been the case since , and the definition of hasn't changed . I think we just got this value wrong in .
Just as a side note – I am using it and I've hit this bug while building the current stable branch. Thank you for maintaining it.
Change:
} // Error possibly reported in `check_assign` so avoid emitting error again. <del> err.emit_unless(expression.filter(|e| fcx.is_assign_to_bool(e, expected)) .is_some()); </del> <ins> let assign_to_bool = expression // #67273: Use initial expected type as opposed to `expected`. // Otherwise we end up using prior coercions in e.g. a `match` expression: // ``` // match i { //     0 => true, // Because of this... //     1 => i = 1, // ...`expected == bool` now, but not when checking `i = 1`. //     _ => (), // }; // ``` .filter(|e| fcx.is_assign_to_bool(e, self.expected_ty())) .is_some(); err.emit_unless(assign_to_bool); </ins> self.final_ty = Some(fcx.tcx.types.err); }

Discussion:
Code: <details<summaryBacktrace</summary</details
modify labels: I-ICE C-Bug T-compiler A-mir Regression from 1.34 to 1.35
Additionally, this one ICEs with different error message: () <details<summaryBacktrace</summary</details
This code should not get all the way to codegen without an error
Another, different ICE? <details<summaryBacktrace</summary</summary
Regression somewhere between ...
looks suspicious, cc In particular, maybe is falsly returning here since the expected type is due to the other match arms?
Change:
} } <del> pub fn register_foreign_item_fn(ccx: &CrateContext, abi: Abi, foreign_item: &ast::ForeignItem) -> ValueRef { </del> <ins> pub fn register_foreign_item_fn(ccx: &CrateContext, abi: Abi, fty: ty::t, name: &str, span: Option<Span>) -> ValueRef { </ins> /*! * Registers a foreign function found in a library. * Just adds a LLVM global. */ debug!("register_foreign_item_fn(abi={},  <del> path={},  foreign_item.id={})", </del> <ins> ty={},  name={})", </ins> abi.repr(ccx.tcx()), <del> ccx.tcx.map.path_to_str(foreign_item.id), foreign_item.id); </del> <ins> fty.repr(ccx.tcx()), name); </ins> let cc = match llvm_calling_convention(ccx, abi) { Some(cc) => cc, None => { <del> ccx.sess().span_fatal(foreign_item.span, format!("ABI `{}` has no suitable calling convention  for target architecture", abi.user_string(ccx.tcx()))); </del> <ins> match span { Some(s) => { ccx.sess().span_fatal(s, format!("ABI `{}` has no suitable calling convention  for target architecture", abi.user_string(ccx.tcx()))) } None => { ccx.sess().fatal( format!("ABI `{}` has no suitable calling convention  for target architecture", abi.user_string(ccx.tcx()))) } } </ins> } }; // Register the function as a C extern fn <del> let lname = link_name(foreign_item); let tys = foreign_types_for_id(ccx, foreign_item.id); </del> <ins> let tys = foreign_types_for_fn_ty(ccx, fty); </ins> // Make sure the calling convention is right for variadic functions // (should've been caught if not in typeck)

Discussion:
Spidermonkey's type is a union of size 64 bits. We represent this as in Rust. This works great on 64bit platforms. On 32bit platforms, the values get mangled when passed to the C library functions. This seems to be an ABI issue. We've encountered this before with which was about 32bit ARM. This gist contains sample programs and the generated IR for minimal test programs using rust-mozjs: Note that you will need my 32bit branch of rust-mozjs: You can put debugging printfs in in to see the value on the C side. The only notable thing I see in the IR is that the clang IR has when passing the . This seems like a Rust bug, but I'd also be interested if there is a workaround that will work on all platforms.
cc
cc me
Change:
&local: &Local, _: PlaceContext<'tcx>, _: Location) { <del> match self.mir.local_kind(local) { </del> <ins> let kind = self.mir.local_kind(local); match kind { </ins> LocalKind::ReturnPointer => { self.not_const(); } <del> LocalKind::Arg => { self.add(Qualif::FN_ARGUMENT); } </del> LocalKind::Var => { self.add(Qualif::NOT_CONST); } <ins> LocalKind::Arg | </ins> LocalKind::Temp => { <ins> if let LocalKind::Arg = kind { self.add(Qualif::FN_ARGUMENT); } </ins> if !self.temp_promotion_state[local].is_promotable() { self.add(Qualif::NOT_PROMOTABLE); }

Discussion:
These currently compile, even if they can be used from compile-time code to trigger a drop: cc
Change:
build.run(&mut cmd); // Create source tarball in rust-installer format <del> let mut cmd = Command::new("sh"); </del> <ins> let mut cmd = Command::new(SH_CMD); </ins> cmd.arg(sanitize_sh(&build.src.join("src/rust-installer/gen-installer.sh"))) .arg("--product-name=Rust") .arg("--rel-manifest-dir=rustlib")

Discussion:
The configure script begins with: This works on machines where bash implements its own version of sh. But fails on Solaris where sh and bash are separated programs. To fix, I changed that first line into: And after that it ran.
cf. .
If the problem here is that we are using bashisms in the configure script, I would rather fix that.
works for me today. Was this issue fixed? I remember some other issues...
works, but the installer has the same issue. For this reason, doesn't work on Solaris.
According to , as one example, gen- is using bashsims or other shell extensions: But in all honesty, I don't think it's worth it. I would encourage you to either rewrite the script in Python (such that it is compatible with Python 2.x and 3.x) or simply change the scripts to use instead. On Solaris, is the traditional bourne shell, not bash, and is not even POSIX compliant. This is for backwards-compatibility reasons, among others. The posix shell is .
Change:
/// Construct `Self` via a conversion. /// <ins> /// **Note: this trait must not fail**. If the conversion can fail, use a dedicated method which /// return an `Option<T>` or a `Result<T, E>`. /// </ins> /// # Examples /// /// `String` implements `From<&str>`:

Discussion:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart.

:+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!
Change:
libc = { version = "0.2.153", default-features = false, features = ['rustc-dep-of-std'], public = true } [target.'cfg(all(not(target_os = "aix"), not(all(windows, target_env = "msvc", not(target_vendor = "uwp")))))'.dependencies] <del> object = { version = "0.32.0", default-features = false, optional = true, features = ['read_core', 'elf', 'macho', 'pe', 'unaligned', 'archive'] } </del> <ins> object = { version = "0.36.0", default-features = false, optional = true, features = ['read_core', 'elf', 'macho', 'pe', 'unaligned', 'archive'] } </ins> [target.'cfg(target_os = "aix")'.dependencies] <del> object = { version = "0.32.0", default-features = false, optional = true, features = ['read_core', 'xcoff', 'unaligned', 'archive'] } </del> <ins> object = { version = "0.36.0", default-features = false, optional = true, features = ['read_core', 'xcoff', 'unaligned', 'archive'] } </ins> [dev-dependencies] rand = { version = "0.8.5", default-features = false, features = ["alloc"] }

Discussion:
The relevant commit seem to be located at <details<summaryError</summary<p</p</details
Ah. cc
Ah, this was fixed in
Okay, it seems like this is just a misunderstanding. keywords cannot be searched ...
This won't be actually fixed in std until lands.
Change:
const STD_PUBLIC_CRATES: [&str; 5] = ["core", "alloc", "std", "proc_macro", "test"]; #[derive(Debug, Copy, Clone, Hash, PartialEq, Eq)] <del> enum DocumentationFormat { </del> <ins> pub enum DocumentationFormat { </ins> HTML, JSON, }

Discussion:
running only builds the html doc, but builds the json doc. I expected the json flag to act as the documentation says (): using the master branch of this repo commit running with a library profile.
I can't reproduce this. The files show up for me in .
Seems to reproduce, I could totally have overlooked a step tho
oh no it's even simpler than that lol it's calling the wrong function that should be JsonStd, not Std
Should I make the PR or are you gonna do it ?
If you could make a PR that would be great :)
Made the PR but since just changing the ensure wasn't enough there's a thing I'm unsure about (tested it, worked, but could be cleaner)
Change:
LLVM_COMPONENTS=x86 arm mips ipo bitreader bitwriter linker asmparser jit mcjit  interpreter instrumentation <ins> # Only build these LLVM tools LLVM_TOOLS=bugpoint llc llvm-ar llvm-as llvm-dis llvm-mc opt </ins> define DEF_LLVM_VARS # The configure script defines these variables with the target triples # separated by Z. This defines new ones with the expected format.

Discussion:
Today error :
I've heard the error from IRC: misses , but invoking again seems to work well.
Yes I just successfully build it today, thanks
I think the first error is significant and should be fixed (no need to re-). Could you reopen it?
wait... but it's building without errors for me now... Do you mean it's working only because I run build second time?
llvm build is triggered only if you haven't built it before or llvm has been upgraded. So I guess llvm fails to complete, but it anyway succeeded to make some binary we use.
I will try to reproduce with clean build
Right, it's still being failing if I build it first time ( or even if I remove i686-... (build) folder ) with the same error.
What version of mingw/gcc did you use? would show and/or . (If both values exist, trust the second one.)
I also reproduced the error on mingw 4.0 / gcc 4.8.1.
I'm having the same issue:
I'm also having this issue. Same version information as
I am also getting the error. Same versions as ameyp. Any more info on this?
According to , this error happens because this particular binary (llvm-c-test) is compiled with -std=c99 flag. Apparently 'offt' is not in ANSI standard, so mingw's specifically omits it when is defined.
Change:
<ins> // Regression test for issue #121612 trait Trait {} impl Trait for bool {} struct MySlice<T: FnOnce(&T, Idx) -> Idx>(bool, T); //~^ ERROR cannot find type `Idx` in this scope //~| ERROR cannot find type `Idx` in this scope type MySliceBool = MySlice<[bool]>; const MYSLICE_GOOD: &MySliceBool = &MySlice(true, [false]); //~^ ERROR the size for values of type `[bool]` cannot be known at compilation time //~| ERROR the size for values of type `[bool]` cannot be known at compilation time 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</details

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: writeimmediatetomplace: invalid ScalarPair layout: TyAndLayout {', 'error: internal compiler error: writeimmediatetomplace: invalid ScalarPair layout: TyAndLayout {' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [evaltoallocationraw] const-evaluating + checking [evaltoconstvalueraw] simplifying constant for the type system [analysis] running analysis passes on this crate --
cc
Change:
<ins> // check-pass #![feature(fn_traits)] #![feature(adt_const_params)] //~^ WARNING the feature `adt_const_params` is incomplete #[derive(PartialEq, Eq)] struct CompileTimeSettings{ hooks: &'static[fn()], } struct Foo<const T: CompileTimeSettings>; impl<const T: CompileTimeSettings> Foo<T> { fn call_hooks(){ } } fn main(){ const SETTINGS: CompileTimeSettings = CompileTimeSettings{ hooks: &[], }; Foo::<SETTINGS>::call_hooks(); } </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. --Looks a bit like <!-- 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 --
Used as feature and got this: Regressed somewhere between ... <details<summaryBefore</summary</details<details<summaryAfter</summary</details
claim