jiebi/CodeConvo huggingface dataset:
Change:
use rustc_errors::{DiagArgName, DiagArgValue, DiagMessage, Diagnostic, IntoDiagArg}; use rustc_hir::CRATE_HIR_ID; <del> use rustc_middle::mir::interpret::Provenance; </del> <ins> use rustc_middle::mir::interpret::{Provenance, ReportedErrorInfo}; </ins> use rustc_middle::mir::AssertKind; use rustc_middle::query::TyCtxtAt; use rustc_middle::ty::TyCtxt;

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: interpret const eval failure of Unevaluated(UnevaluatedConst { def: DefId(0:11 ~ ice[ec8e]::EEKZERO), args: [], promoted: Some(promoted[0]) }, &'{erased} [Eek; 0usize]) which is not in requiredconsts', 'error: internal compiler error: interpret const eval failure of Unevaluated(UnevaluatedConst { def: DefId(0:11 ~ ice[ec8e]::EEKZERO), args: [], promoted: Some(promoted[0]) }, &'{erased} [Eek; 0usize]) which is not in requiredconsts' 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: 6 | const EEKZERO: &[Eek] = &[]; [evaltoallocationraw] const-evaluating + checking [evaltoconstvalueraw] simplifying constant for the type system [analysis] running analysis passes on this crate --
cc
Caused by running the interpreter on code that doesn't even pass name resolution. Not sure where to fix this, but probably not in the interpreter.^^ Cc
this is a promoted failing to compile because it gets the layout of this broken type, which gives us back an . I'm certain we can prevent const eval from running by checking such layouts earlier in the MIR pipeline, but the fix isn't clear to me yet.
The issue is that in the sanity check we only know it's an , we don't know whether it was a typeck error on a const-eval error. So we can't really distinguish these cases. If this is a , we could probably fix it by tweaking the error handling . But there probably are similar cases where a promoted fails to evaluate due to a SizeOverflow and then we have to report the error somewhere.

The only option I see right now is to add another variant to (or a flag in ) to track whether this was a failure inside the constant itself or a failure in something the constant referenced. But this distinction isn't always very clear anyway... it would basically have to be "is this an error that can occur even for supposedly infallible operations like ", i.e., match exactly the usecase of the const-eval / promoted sanity check. Which is not great.
We already got the flag that we can reuse for that
Change:
<ins> pub static TEST_STR: &'static str = "Hello world"; </ins>

Discussion:
When learning async/await feature I was struggling with running multiple tasks simultaneously. Loop causes compiler to crash Github Action crash output: I expected to see this happen: Error message if something goes wrong. Instead, this happened: Compiler crashed Crash happens on macOS rustc 1.40 / Linux rustc 1.40 / Linux rustc 1.39 ( github actions ) :
If you could provide an example that ICEs in e.g. the playground that would be helpful towards fixing the issue. :)
Provided example is pretty small, but it is dependent on tokio and actix-web. I do not know how to create such an example in playground, I do know know how I can replace async tokio::sync::mpsc with standard library which does not have async alternative as far as i know. I have tried to simplify code but then crash disappear. Just putting everything into one file and crash is gone, code wont compile and reasonable errors show up.
Visiting from triage.. we decided that as the first step we should reduce this reproducer to a more self-contained one.
Can repro. Will try and min.
Reduced version so far is here:
This no longer ICEs on the latest nightly.
Let's see if we can shrink further so that we can add a test. 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
I’ve reduced it quite a bit. Down to dependencies on only. Appears to need 2 crates.

I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.
Change:
} fn get_const(&self, local: Local) -> Option<Const<'tcx>> { <del> let l = &self.ecx.frame().locals[local]; // If the local is `Unitialized` or `Dead` then we haven't propagated a value into it. // // `InterpCx::access_local()` mostly takes care of this for us however, for ZSTs, // it will synthesize a value for us. In doing so, that will cause the // `get_const(l).is_empty()` assert right before we call `set_const()` in `visit_statement` // to fail. if let LocalValue::Uninitialized | LocalValue::Dead = l.value { return None; } </del> self.ecx.access_local(self.ecx.frame(), local, None).ok() } <del> fn set_const(&mut self, local: Local, c: Const<'tcx>) { let frame = self.ecx.frame_mut(); if let Some(layout) = frame.locals[local].layout.get() { debug_assert_eq!(c.layout, layout); } frame.locals[local] = LocalState { value: LocalValue::Live(*c), layout: Cell::new(Some(c.layout)), }; } </del> fn remove_const(&mut self, local: Local) { self.ecx.frame_mut().locals[local] = LocalState { value: LocalValue::Uninitialized,

Discussion:
The following code results in a const eval divide by zero error, when it cannot actually error at runtime:
Bisected to , which corresponds to . cc BTW, you need to actually use (e.g. by calling it in ) to trigger the error. Just adding won't do it.
Fun thing, it doesn't even depend on the conditions in the if clause: also ICEs
Thanks
Change:
// sockaddr and misc bindings //////////////////////////////////////////////////////////////////////////////// <del> pub fn setsockopt<T>(sock: &Socket, opt: c_int, val: c_int, payload: T) -> io::Result<()> { </del> <ins> pub fn setsockopt<T>( sock: &Socket, level: c_int, option_name: c_int, option_value: T, ) -> io::Result<()> { </ins> unsafe { <del> let payload = &payload as *const T as *const c_void; cvt(c::setsockopt(sock.as_raw(), opt, val, payload, mem::size_of::<T>() as c::socklen_t))?; </del> <ins> cvt(c::setsockopt( sock.as_raw(), level, option_name, &option_value as *const T as *const _, mem::size_of::<T>() as c::socklen_t, ))?; </ins> Ok(()) } } <del> pub fn getsockopt<T: Copy>(sock: &Socket, opt: c_int, val: c_int) -> io::Result<T> { </del> <ins> pub fn getsockopt<T: Copy>(sock: &Socket, level: c_int, option_name: c_int) -> io::Result<T> { </ins> unsafe { <del> let mut slot: T = mem::zeroed(); let mut len = mem::size_of::<T>() as c::socklen_t; cvt(c::getsockopt(sock.as_raw(), opt, val, &mut slot as *mut _ as *mut _, &mut len))?; assert_eq!(len as usize, mem::size_of::<T>()); Ok(slot) </del> <ins> let mut option_value: T = mem::zeroed(); let mut option_len = mem::size_of::<T>() as c::socklen_t; cvt(c::getsockopt( sock.as_raw(), level, option_name, &mut option_value as *mut T as *mut _, &mut option_len, ))?; Ok(option_value) </ins> } }

Discussion:
This bug was found and mitigated by the Wine project here: The types for each setsockopt are documented here: As the Wine commit explains, Windows itself is more liberal in what values of optlen it will accept for boolean arguments, which is why this has not affected Windows proper, but it would still be better to pass the expected type and length, so that the Rust bindings will also work on more strict implementations of winsock, such as Wine's prior to this fix. I confirmed that this is the case using Wine 7.0, which is the current stable branch available from Wine 5.0.3, which is the version that Debian/Ubuntu distribute themselves, is not affected by this problem. I tried this code: I set up a listening peer with , built with , and ran with . I expected to see this happen: all the socket operations succeed, and prints "hello" and exits. Instead, this happened: setnodelay returns an Err: If I run with , which shows the Linux system calls that wine makes on behalf of the program, I can see: I tested this using rust 1.58.1, but I confirmed that the code in question is still doing the same thing on the branch of rust. Here is a commit which should fix the issue: I was able to test it myself and confirmed that the error goes away: That this error isn't formatted correctly is probably another bug, but I haven't looked into it.
Thanks for reporting this! Would you mind creating a pull request with your changes? The rustc dev guide has information on the .
Sure thing:
Change:
use crate::compile; use crate::config::{Config, TargetSelection}; use crate::tool::{self, prepare_tool_cargo, SourceType, Tool}; <del> use crate::util::{symlink_dir, t, up_to_date}; </del> <ins> use crate::util::{dir_is_empty, symlink_dir, t, up_to_date}; </ins> use crate::Mode; macro_rules! submodule_helper {

Discussion:
This might not be a valid request (I have to tell it what to test), but surely it shouldn't just result in such an obscure panic. Cc
you don't have dir ?
it doesn't exists until fetching the submodule
Seems like I don't have that submodule checked out; I don't work on the book so it's not needed (and I keep the checked-out submodules to a minimum to avoid having to update them all the time).
I reproduced it in local, without in and don't update submodule manually, will fail like this.
I can fix it tomorrow, feel free to work on it if you want to fix it earlier.
by the way, do you know why we use those for here?
Not particularly, I am not so familiar with the compiletest code. Probably we panic there so the compiletest runner process can handle(being able to understand compiletest was failed) that.
The fix shouldn't make any changes on the compiletest side. We just need to avoid using submodules(if doesn't exists) instead of assuming that they exist.
Yes, that's another issue, I just met it today.
Change:
use ty::{self, Ty, TyCtxt, TypeFoldable}; use ty::fold::TypeVisitor; use ty::subst::{Subst, UnpackedKind}; <ins> use ty::maps::TyCtxtAt; </ins> use ty::TypeVariants::*; use util::common::ErrorReported; use middle::lang_items;

Discussion:
One example is the method on . Internally it creates a , when it could simply be taking exactly that as an argument. In miri I had to write which just feels a little riddiculous (taking apart the , just to have the method construct it back). There's probably many other similar methods and functions that should be taking a
Can I take this one if no one is working on that ?
it's all yours!
Change:
} else { debug!("find_existential_constraints: scope={:?}", tcx.hir().get(scope)); match tcx.hir().get(scope) { <del> Node::Item(ref it) => intravisit::walk_item(&mut locator, it), Node::ImplItem(ref it) => intravisit::walk_impl_item(&mut locator, it), Node::TraitItem(ref it) => intravisit::walk_trait_item(&mut locator, it), </del> <ins> // We explicitly call `visit_*` methods, instead of using `intravisit::walk_*` methods // This allows our visitor to process the defining item itself, causing // it to pick up any 'sibling' defining uses. // // For example, this code: // ``` // fn foo() { //     existential type Blah: Debug; //     let my_closure = || -> Blah { true }; // } // ``` // // requires us to explicitly process `foo()` in order // to notice the defining usage of `Blah`. Node::Item(ref it) => locator.visit_item(it), Node::ImplItem(ref it) => locator.visit_impl_item(it), Node::TraitItem(ref it) => locator.visit_trait_item(it), </ins> other => bug!( "{:?} is not a valid scope for an existential type item", other

Discussion:
Mentioning the existential types tracking issue Mentioning and
O_o I don't think I considered closures at all. Should closures be defining uses? Or just uses (and thus only be able to return that type by calling a function that defines the existential)?
As a motivating use case, existential types defined by a closure are required if we want to extend to support referring to local variables.
Yeah, any in-scope use (including in a binding) can be a defining use.
A binding like this? It looks like this is not currently picked up. It is why I had to write rather than simply in my previous comment.
Yeah, the RFC specifies that that should work.
I chose a simpler logic: any in scope use must be a defining use.
We've moved from segmentation faults to an ICE:
Change:
#[doc(alias)] //~ ERROR #[doc(alias = 0)] //~ ERROR #[doc(alias("bar"))] //~ ERROR <ins> #[doc(alias = """)] //~ ERROR #[doc(alias = "n")] //~ ERROR #[doc(alias = " ")] //~^ ERROR #[doc(alias = " ")] //~ ERROR #[doc(alias = "t")] //~ ERROR </ins> pub struct Foo;

Discussion:
From this comment: Still remaining the .
Actually, the character has a meaning in the search (for "exact" search). But instead of just removing it, maybe we should instead emit an error when we encounter it. What do you think ?
That doesn't work for though, maybe it should? It would make sense to restrict allowed characters because even whitespace is allowed at the moment which seems questionable.
It sounds like we need to make sure this lands before we branch beta or so?
Let's forbid , whitespaces and tabs in the the doc alias then.
Can we avoid ad-hoc rules and say something like "must be a rust identifier"?
Even better! Great suggestion !
Just thought about it, but it cannot be the case : we allow things like "*" or "+" (for the traits for example), so it cannot be ident only. I'll stick to the listed characters above.
The documentation () has no mention of that -- can you elaborate?
Doc aliases can be something else than a rust identifier. For example, you can look for or in the std docs, and you'll see aliases results.
Ah, I see what you mean. Okay, then I agree that we need more than just Rust identifiers, and it might be reasonable to just allow as you suggest -- everything except whitespace and quotes. I'm a bit worried that'll hurt us in terms of how expansive it is but it's probably fine.
I don't expect attributes to be used widely, so we should be fine. ;)
Is there more justification for removing whitespace support other than calling the characters questionable? If I have a struct or a function that implements an algorithm, I would like to alias the item to the plaintext name of the algorithm, for example .
I just had in mind "idents", so no whitespace in them. However I don't see any reason to not allow specfically. I'll send a PR tomorrow.
rustdoc only being ident-centric is .
path-centric would be more accurate. ;)
Change:
target_module: Module<'b>, directive: &'b ImportDirective) -> ResolveResult<()> { <ins> if let Some(Def::Trait(_)) = target_module.def { self.resolver.session.span_err(directive.span, "items in traits are not importable."); } </ins> if module_.def_id() == target_module.def_id() { // This means we are trying to glob import a module into itself, and it is a no-go let msg = "Cannot glob-import a module into itself.".into();

Discussion:
Code that compiles fine with rustc is causing an internal compiler error: unexpected panic with rustdoc. I tried this code (): The second line is essentially a typo, which can happen if used to be an Enum for instance. Again, the following works fine (although I'm not sure why, can you even add anything to the namespace?): However, if I run: I get the error: This actually happened on a version of a package already pushed to (hdf5-sys 0.3.0), so anything that depends on the erroneous version and runs will see this error. Run on . Backtrace:
This is easy to fix in rustdoc, but should this even compile?
Whoa kinda crazy... cc (resolve weridness, longstanding though!)
Change:
<ins> error[E0412]: cannot find type `Bar` in this scope --> $DIR/dont-compute-arg-names-for-non-fn.rs:8:14 | LL | impl Foo for Bar {} |              ^^^ | help: you might have meant to use the associated type | LL | impl Foo for Self::Bar {} |              ++++++ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0412`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'DefId(2: ~ core[ef64]::ops::index::Index::Output) does not have a "fnargnames"'', 'thread 'rustc' panicked at 'DefId(2: ~ core[ef64]::ops::index::Index::Output) does not have a "fnargnames"'' 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: [fnargnames] looking up function parameter names for [resolverforlowering_raw] getting the resolver for lowering --
cc
Change:
[[package]] name = "tar" <del> version = "0.4.12" </del> <ins> version = "0.4.13" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "filetime 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)",

Discussion:
I got in a project of mine for recent nightlies which I think are releated to the rustification of rust-installer but I'm not 100% certain: does this sound familiar to you?
Oh looks like and are all related to this as well.
Ah, yes, backslashes in the manifest are an easily understood problem. Executable is harder. At least I left a note about that . :) Since Windows doesn't really have such flags, I suspect it must have worked on some MSYS tricks with ACLs before. Maybe we should make a special case for this when writing the tarball, like writing known-executable file names with manually-tweaked metadata?
Yeah I think we'll probably just want to special case everything going into the tarballs and manually set the metadata for the various bits and pieces. I'm... not entirely sure how this worked with MSYS, but presumably there's some weird translation layer which we're not aware of and isn't surfaced through winapi things...
OK, so should fix up the manifests at least. Researching the file modes, I first wondered whether the crate should read the advanced ACLs for , as right now it just . But it looks like all created files have "execute" privileges anyway -- e.g. even includes . You can remove that with in MSYS/Cygwin/etc., but it appears atypical for a file not_ to be executable. The good news is that also doesn't care about execute when unpacking on Windows, just . The rest will follow the defaults of , still with executable ACLs. So I think the permissions created by rustup will be fine, but I guess if one manually unpacks with MSYS/Cygwin tar they may get non-executable etc. The quickest hack for you would be to just change this: Step 7 : RUN /tmp/rust-mingw-nightly-i686-pc-windows- --prefix= ... to invoke instead, which doesn't care about execute privileges. :)
Ah yeah I don't think there's a great way to flag a file on Windows as executable/not-executable, I'm basically just thinking that we have a whitelist of files/patterns that will get listed as executable in the tarball (as the tarball stores unix modes) and we'd just follow that.
Change:
) -> PResult<'a, ast::Crate> { sess.diagnostic() .set_continue_after_error(control.continue_parse_after_error); <ins> hygiene::set_default_edition(sess.edition()); </ins> if sess.profile_queries() { profile::begin(sess);

Discussion:
Rustdoc seems to fail on async syntax in some situations. With in , the following is a sample of some apparent issues. This should build fine, but fails when running rustdoc: Tested with a few different nightlies (rustc 1.30.0-nightly ( 2018-08-05)) and latest master ().
This is a bug between rustdoc and , where the only place that is handed to libsyntax is this specific all-in-one entry point to the compiler: However, since rustdoc manages the phases of compilation itself, this line is never hit, and thus the global state telling libsyntax what edition to use is not set. We use this call manually for building doctests (see ), but not anywhere else. I propose moving the call from to , right before it sets up the parse session. That way, rustdoc can continue to set the edition in the session options, and other consumers of aren't caught by this gotcha.
Change:
/// # Panics /// /// Panics if `begin` does not point to the starting byte offset of <del> /// a character (as defined by `is_char_boundary`), or if `begin >= len`. </del> <ins> /// a character (as defined by `is_char_boundary`), or if `begin > len`. </ins> #[stable(feature = "str_checked_slicing", since = "1.20.0")] unsafe impl SliceIndex<str> for ops::RangeFrom<usize> { type Output = str;

Discussion:
mentions "Panics [...] if begin end, or if end len", which I think is correct. However, mentions "Panics [...] if begin = len", which I think is wrong, isn't it? Shouldn't this be "Panics [...] if begin len"? The current stable compiler doesn't seem to create a panicking program when I use "begin = len". The documentation for slice slicing doesn't mention anything at all: It would be great to have the (correct) description there as well. I think this has already been fixed in and (more than 4 years ago), but it seems to have gotten lost again since then? Or am I missing something?
You're right, I guess it's a copy/paste error from in ? We're happy to see a PR to fix it :)
Change:
} TerminatorKind::Call { func, args, destination, cleanup, .. } => { let func_ty = func.ty(&self.body.local_decls, self.tcx); <del> let func_ty = self.tcx.normalize_erasing_regions(self.param_env, func_ty); </del> match func_ty.kind() { ty::FnPtr(..) | ty::FnDef(..) => {} _ => self.fail(

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. --I think all of these happen since <!-- 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</detailsThe following samples also did not crash with -Zvalidate-mir with but do crash with  `
cc