jiebi/CodeConvo huggingface dataset:
Change:
<del> error[E0118]: no base type found for inherent implementation </del> <ins> error[E0118]: no nominal type found for inherent implementation </ins> --> $DIR/private-in-public-ill-formed.rs:14:10 | LL |     impl <Priv as PrivTr>::AssocAlias { <del> |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ impl requires a base type </del> <ins> |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ impl requires a nominal type </ins> | = note: either implement a trait on it or create a newtype to wrap it instead <del> error[E0118]: no base type found for inherent implementation --> $DIR/private-in-public-ill-formed.rs:30:10 </del> <ins> error[E0118]: no nominal type found for inherent implementation --> $DIR/private-in-public-ill-formed.rs:31:10 </ins> | LL |     impl <Priv as PrivTr>::AssocAlias { <del> |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ impl requires a base type </del> <ins> |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ impl requires a nominal type </ins> | = note: either implement a trait on it or create a newtype to wrap it instead

Discussion:
] To : This should probably use the covered/local terminology from instead of "base type" to avoid the problematic overlap with subtyping/inheritance terminology.
] ] ] (Not really [C-bug], but it was the closest of the template options.)
Just fyi, you can do modify labels to -C-bug +A-diagnostics +C-enhancement +D-newcomer-roadblock which will let you apply most labels yourself. .
Error: Label D-newcomer-roadblock can only be set by Rust team members Please let know if you're having trouble with this bot.
... Oh, unless that happens.
A second attempt :stuckouttongue: modify labels to -C-bug +A-diagnostics +C-enhancement
In the reference, we use the term "nominal type". The error code explanation should also mention unions and trait objects ( is valid). If the person use or , it should also hint at removing the reference and putting them on in the associated items. Not sure if I should open a new issue for that one or not though.
Change:
<ins> error[E0369]: binary operation `==` cannot be applied to type `for<'r> fn(&'r i32) -> &'r i32 {foo}` --> $DIR/issue-77910-1.rs:8:5 | LL |     assert_eq!(foo, y); |     ^^^^^^^^^^^^^^^^^^^ |     | |     for<'r> fn(&'r i32) -> &'r i32 {foo} |     _ | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error[E0277]: `for<'r> fn(&'r i32) -> &'r i32 {foo}` doesn't implement `Debug` --> $DIR/issue-77910-1.rs:8:5 | LL |     assert_eq!(foo, y); |     ^^^^^^^^^^^^^^^^^^^ `for<'r> fn(&'r i32) -> &'r i32 {foo}` cannot be formatted using `{:?}` because it doesn't implement `Debug` | = help: the trait `Debug` is not implemented for `for<'r> fn(&'r i32) -> &'r i32 {foo}` = note: required because of the requirements on the impl of `Debug` for `&for<'r> fn(&'r i32) -> &'r i32 {foo}` = note: required by `std::fmt::Debug::fmt` = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to 2 previous errors Some errors have detailed explanations: E0277, E0369. For more information about an error, try `rustc --explain E0277`. </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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It also fails for every comparison of and
I found another potentially related weirdness: This fails with: But this (without the argument) fails with a different error, even though there should be no difference as is not used: EDIT: Apparently this is intended behavior, see .
searched nightlies: from nightly-2019-01-01 to nightly-2020-10-13 regressed nightly: nightly-2020-05-03 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Darn, is it really the bitcode commit again? Or did it happen sometime around then? Cc
This bisection is incorrect due to:
Marking this as P-
claim
You have to write if you want to assign this issue.
Thanks bro. claim
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. #![crate_type = "rlib"] struct Foo; trait Tr { fn tr(&self); } impl Tr for Foo { fn tr(&self) {} } fn take_method<T>(f: fn(&T), t: &T) {} #[inline] pub fn pass_method() { take_method(Tr::tr, &Foo); } </ins>

Discussion:
While trying to replace the "secret" functions (e.g. ) used for with their UFCS versions (e.g. ), I ran into the following ICE: I couldn't get a backtrace with nor with cc
I have similar ICE without inlining: But i can't reproduce it in simple code example for now.
Caught it! Main body: Test body:
I guess this the related, since I'm actually trying to use UFCS to inline a function and the function is not defined in my crate, Using rustc 0.13.0-dev ( 2014-10-24 03:22:29 +0000) as well as master from playpen, By the way, it might be nice if playpen was able to automatically display (and/or send) that information when ICEs are found.
Some of these look similar to , but the fix for that went in recently...
your issue is , and the fix for it just landed. I think the others still occur.
your ICE does not appear to be UFCS-related. Can you open a separate issue?
I can confirm that the original example still ICEs even with the fix for , so it is a different issue:
I'm seeing a def with the wrong crate ID. It looks like an AST decoding problem. Hopefully an easy fix.
Change:
<ins> error[E0751]: found both positive and negative implementation of trait `Send` for type `TestType<_>`: --> $DIR/issue-106755.rs:13:1 | LL | unsafe impl<T: MyTrait + 'static> Send for TestType<T> {} | ------------------------------------------------------ positive implementation here LL | LL | impl<T: MyTrait> !Send for TestType<T> {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ negative implementation here error[E0119]: conflicting implementations of trait `Send` for type `TestType<_>` --> $DIR/issue-106755.rs:15:1 | LL | unsafe impl<T: MyTrait + 'static> Send for TestType<T> {} | ------------------------------------------------------ first implementation here ... LL | unsafe impl<T: 'static> Send for TestType<T> {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `TestType<_>` error: aborting due to 2 previous errors Some errors have detailed explanations: E0119, E0751. For more information about an error, try `rustc --explain E0119`. </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. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
claim
After doing some more investigation, this also happens on a crate with only the empty crate: and like the original error, and are all used in manual implementations.
There are a bunch of these triggering in various lints it seems, so I wonder if the assert might actually not be thaaat justified?
changed that when a message is not in the primary bundle and debugassertions are on, it ices. So, for example, if you are using a half translated French bundle with messages missing, and have debugassertions on, you'll probably ice a lot. I agree that that in hindsight might have been a bad idea, and we should back that out ...however we don't actually have any other bundles, so I have no idea how this can trigger. I did some more debugging today, and it looks like the primary bundle never has any messages, so it should only trigger if the message requires formatting. I have no idea why that is or why it only happens if you have a rustc built with debug_assertions, rather than during tests for example. The only thing I can come up with is that between invoking rustc and running tests the bundle is created differently.
Change:
} } <del> fn for_each_child_stable<R, F>(&'a self, resolver: &mut R, mut f: F) where R: AsMut<Resolver<'a>>, F: FnMut(&mut R, Ident, Namespace, &'a NameBinding<'a>) { let resolutions = resolver.as_mut().resolutions(self).borrow(); let mut resolutions = resolutions.iter().collect::<Vec<_>>(); resolutions.sort_by_cached_key(|&(&(ident, ns), _)| (ident.as_str(), ns)); for &(&(ident, ns), &resolution) in resolutions.iter() { resolution.borrow().binding.map(|binding| f(resolver, ident, ns, binding)); } } </del> fn res(&self) -> Option<Res> { match self.kind { ModuleKind::Def(kind, def_id, _) => Some(Res::Def(kind, def_id)),

Discussion:
The test appears to be intermittently changing its output. Usually, it prints: but sometimes it prints: See for an example of this happening. Here's a log snippet from a compiler build which prints (the current expected output): Note - this indicates that the chosen (which is what actually gets printed) is Output from a compiler which prints : Note - here, the is . There appears to be some non-determinism occuring, but I'm not sure where.
This is blocking - some builders are printing while others are printing , making it impossible to merge.
Change:
//! switching compilers for the bootstrap and for build scripts will probably //! never get replaced. <del> // NO-RUSTC-WRAPPER #![deny(warnings, rust_2018_idioms, unused_lifetimes)] </del> use std::env; use std::ffi::OsString; use std::io;

Discussion:
When using 1.38 beta to bootstrap itself, I get:
This is expected and not a supported bootstrapping configuration; if you want to not see these errors you'll want to either bootstrap with N-1 compiler (so, in this case, 1.37) or I believe remove from bootstrap and some other libraries, as well as set deny-warnings in to false. Note that only the 1.37 bootstrap method is officially supported as "guaranteed to work", the deny warnings fix is more of a hack. Closing as won't fix.
Huh? In the past this was always fixed as it's a very common practice for distribution packaging (I don't know of a single packager not doing that). See e.g. or (in which you sort of acknowledged that yourself) deny-warnings is already set to false in , so I guess it somehow doesn't apply to building bootstrap itself.
I hope is an acceptable compromise wrt this. Thanks for pointing out the deny-warnings option which I forgot (since it has been set to false forever for us and never had any effect on the build of bootstrap itself)
Yeah is great; in this case the unsafe block is needed for 1.37 but not on 1.38; if there was an easy way to support both use cases then I'd be happy to accept a PR targeting beta but I'm not personally aware of one -- it looks like we don't seem to have an or similar? We try to support distros and such where possible in this configuration, it's just that this specific case I'm not sure how much we can do. deny-warnings=false is always my recommendation when using a different bootstrap compiler, or manual patches to the code.
Change:
docker cp . checkout:/checkout args="$args --volumes-from checkout" else <del> args="$args --volume $root_dir:/checkout:ro" </del> <ins> args="$args --volume $root_dir:/checkout$SRC_MOUNT_OPTION" </ins> args="$args --volume $objdir:/checkout/obj" args="$args --volume $HOME/.cargo:/cargo" args="$args --volume $HOME/rustsrc:$HOME/rustsrc"

Discussion:
I have this totally normal config: Then I want to run Then inside the container, Bootstrap is compiled, but then emits this: My repository history is not too shallow. The only way to use the CI scripts seems to be to set . The reason download-ci-llvm doesn't work seems to be the ownership of the mount: So maybe this is an easy fix? Can we just run that somewhere? It seems to work, I'm just not sure where it would be run.
That script should set the uid of the processes inside the container to match what you use outside of the container and thus who owns the source repo: If you use podman, are you maybe using a version of podman which doesn't contain the literal string in ? And can you run outside and inside the container?
I am not using Podman
Outside the container: After
I assume this is related with your docker privileges (the user group assigned on docker). Can't reproduce this on my side.
That seems reasonable? What should that be instead?
should be able to handle this
That's very nice of you, but if I have a scuffed Docker setup on my dev machine I'd like to know in what way it's scuffed if you don't mind :sweat_smile:
By default, docker runs under root mode, and I believe this is the main issue here. On the other hand, podman runs in rootless mode by default: I was able to reproduce the problem by running podman under root privileges. I believe the problem here is more related to the nature of docker rather than an issue with your docker setup.
The snippet I mentioned in should ensure that the programs inside the container run as the same user as the one with which was invoked.
And when the user is root (e.g., running the script with root user), you get .
Change:
<ins> // compile-flags: -C no-prepopulate-passes #![feature(link_llvm_intrinsics)] #![crate_type = "lib"] struct A; impl Drop for A { fn drop(&mut self) { println!("A"); } } extern { #[link_name = "llvm.sqrt.f32"] fn sqrt(x: f32) -> f32; } pub fn do_call() { let _a = A; unsafe { // Ensure that we `call` LLVM intrinsics instead of trying to `invoke` them // CHECK: call float @llvm.sqrt.f32(float 4.000000e+00 sqrt(4.0); } } </ins>

Discussion:
I guess intrinsics need to be ed and not d? Maybe the MIR inliner is inlining the intrinsic's wrapper, but keeps the target intact when it shouldn't. Or this should be handled in codegen, not sure.
The implementation ends up calling pause intrinsic declared as follows: The rustc codegen is completely unaware that it is dealing with an intrinsic, it just changes the symbol name. Looks like the whole feature was introduced by accident, and feature gate was introduced after the fact to make it unstable.
Change:
sp: Span, tts: &[ast::TokenTree]) -> Box<base::MacResult+'static> { <del> let e_attrs = cx.expr_vec_ng(sp); let e_visibility = cx.expr_path(cx.path_global(sp, vec!( id_ext("syntax"), id_ext("ast"), id_ext("Inherited")))); let expanded = expand_parse_call(cx, sp, "parse_method", vec!(e_attrs, e_visibility), tts); </del> <ins> let expanded = expand_parse_call(cx, sp, "parse_method_with_outer_attributes", vec!(), tts); </ins> base::MacExpr::new(expanded) }

Discussion:
As of a few weeks ago was able to parse attributes attached to a quoted method. Recently this fails with a syntax error, See example .
I suspect your commit is the culprit here as it removes a from .
Change:
use_kind, lp_base); } LpExtend(ref lp_base, _, LpInterior(InteriorField(_))) => { <ins> match lp_base.to_type().sty { ty::ty_struct(def_id, _) | ty::ty_enum(def_id, _) => { if ty::has_dtor(self.tcx(), def_id) { // In the case where the owner implements drop, then // the path must be initialized to prevent a case of // partial reinitialization // // FIXME (22079): could refactor via hypothetical // generalized check_if_path_is_moved let loan_path = owned_ptr_base_path_rc(lp_base); self.move_data.each_move_of(id, &loan_path, |_, _| { self.bccx .report_partial_reinitialization_of_uninitialized_structure( span, &*loan_path); false }); return; } }, _ => {}, } </ins> // assigning to `P.f` is ok if assigning to `P` is ok self.check_if_assigned_path_is_moved(id, span, use_kind, lp_base);

Discussion:
So I was curious how Drop handles cycles, because this could lead to dangling pointers, which is why . And indeed the below example does not call Drop. But is moved into , so why does this compile at all?
Nominating, seems like a soundness hole.
This is an issue with zeroing dynamic drops (which are going to be removed: rust-lang/rfcs) – when is moved, its drop flag is cleared, which prevents the destructor of from running. A clearer example is:
Structs that implement drop are not supposed to be in a partially initialized state. We already prevents moves out from individual fields, but we also need to prevent individual fields from being re-initialized. cc since (iirc?) he was working on the patches that made us more accepting around re-initializing fields and so forth, and maybe this bug is of interest to him.
So we are not supposed to allow structs that implement drop to be partially initialized. We already disallow going from fully-initialized to partially initialized. But it seems (from the first example) that we missed disallowing going from fully-uninitialized to partially initializd. That needs to be fixed. Assigning P-backcompat-lang, 1.0.
While this will hopefully be fixed soon, as there is a PR up, it seems to have fallen through the cracks as a P-backcompat-lang issue that is only on the 1.0 milestone and not 1.0 beta. Nominating for 1.0 beta. (Also, I guess I will try to run through and find any other such overlooked issues.)
Assigning 1.0 beta.
Change:
<ins> fn main() { // foo must be used. foo(); } // For this test to operate correctly, foo's body must start on exactly the same // line and column and have the exact same length in bytes in a.rs and b.rs. In // a.rs, the body must end on a line number which does not exist in b.rs. // Basically, avoid modifying this file, including adding or removing whitespace! fn foo() { assert_eq!(1, 1);//// } </ins>

Discussion:
I encountered an ICE today. Below you find the backtrace of running . I ran afterwards and the ICE vanished, so it seams to be connected to incremental compilation. If required I can attach the full project including the build directories, as I zipped it after the ICE.
If possible, we would most of all appreciate a reproducer that works on the playground (this will facilitate fixing the bug faster) but if that's not possible a link to the zip would be good also.
Sorry, I didn't had enough time for it lately. Are there any guidelines how to track down such an incremental compilation error? Unfortunately I cannot recall the steps I've done. I've minimized the code in such a way, that removing any more causes the ICE to vanish. I'll attach this Zip-archive, so somebody else might have a look. Note, that this is not yet a MCVE.
any luck so far? The code looks good, now you have to recall what you did (rename a variable, changed something from a struct to a trait? Deleted members of a struct? Added functions? Removed them?) I know it's hard to debug incremental bugs (I encountered two so far). Any chance that you can tell us, what you did between , and the second ?
Unfortunately no. I tried to recall things, that I've done at this point, but any change I made either also ICEs or compiles fine. I've tried to reproduce this by writing the same code again, but obviously I write it a little bit different now, so I cannot get it to crash. Are there any tips how to deal with those incremental compilation crashes? Trying to reproduce like I'm doing it now is poking around in the dark.
As said, it could be anything ^^ Here are some examples I've seen so far in the wild:
Okay, thanks, I'll have a look at the linked issues :smiley:
Today I encountered the same ICE with "the len is 1077 but the index is 1077". I was writing and running some integration tests; it involved a serialization format (with Serde). I changed an array constant in a test case, then the panic occurred. When I changed it again, the ICE went away, and then I couldn't reproduce it anymore, not even with the value that seems to have caused it in the first place.

We've got the same bug with the len number of 30, not on my machine but on (the CI account isn't mine). If you guys know how to do the magic to pull the build artifacts from travis - you're welcome, CI account's owner seems willing to cooperate
Maybe the commit succession can be of interest to investigate the bug.
I got this same panic, and it also went away after a clean build.
Another one here, looks like the same problem and it also went away for now after .
Change:
match r { // ignore bound regions that appear in the type (e.g., this // would ignore `'r` in a type like `for<'r> fn(&'r u32)`. <del> ty::ReLateBound(..) => return r, </del> <ins> ty::ReLateBound(..) | </ins> // ignore `'static`, as that can appear anywhere <del> ty::ReStatic => return r, </del> <ins> ty::ReStatic | // ignore `ReScope`, as that can appear anywhere // See `src/test/run-pass/issue-49556.rs` for example. ty::ReScope(..) => return r, </ins> _ => { } }

Discussion:
I got ICE for sometime and also searched in issues but cannot find a relative one. Sorry for not able to produce the minimal cases to pin down the actual failing case in my code base by simply reverting my code. x This issue does not exists in . Error message as follows: meta for 2018-03-21 meta for 2018-03-24 I appreciate any hints and suggestions on helping me to reproduce this issue into minimal case but right now I just can't find out what changes in my code caused this problem. My code base is
I have dig into this and found the snippet of code caused this problem: It should produce an error which did not appeared in previous build This is not the whole story, when I assign to a variable and return the variable, it got the same ICE but the type inference error gone. I finally able to mitigate the problem by turning the return type from to
I got a possibly same ICE with this code: Meta: <detailsBacktrace: </details
This gives me the same ICE: However this does not ICE:
Hi all. does not fix my issue.
Sorry, I forgot to test with your case. Though you seem to be using a nightly-2018-03-23 which can never contain unmerged , right? depends on which is not even compilable with recent nightlies.
Hi, sorry for the slow reply. I will try that again once the branch have been merged. Any ETA on when it will go into nightly? Thanks
No, it varies due to approval of other PRs. Here is the current queue:
Nightly 2018-04-14 contains . Could you reopen if the problem persists?
As at least one data point, I had the same issue and it was resolved with 2018-04-15.
Change:
use rustc_span::symbol::{kw, sym, Ident, Symbol}; use rustc_span::{BytePos, DesugaringKind, ExpnKind, MacroKind, Span, DUMMY_SP}; use rustc_target::spec::abi; <ins> use std::assert_matches::debug_assert_matches; </ins> use std::borrow::Cow; use std::iter;

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. --issue appeared when going from 1 -2, was able to fix it by adding 3 <!-- 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
I've only skimmed the code but this is very likely due to the diagnostic method constructing a projection, more precisely an , with created for the trait item, not the associated type (with (pseudo) ), so we're missing the own generic arguments for the GAT.