jiebi/CodeConvo huggingface dataset:
Change:
On current num-integer master (commit ), rustc nightly and beta both crash when targeting . Stable is fine. (The inline attribute warning is irrelevant to success/failure, but I'll clean that up separately.) cc rust-num/num-integer
<details<summaryGDB backtrace of the SIGSEGV thread on nightly:</summary</details
Thanks Minimal reproducible test case:
triage: P-high for now. (but this is a Tier-2 target, so it may get downgraded to P-medium after a few weeks. We will see.)
cc -- the versions correspond to the LLVM change for emscripten.
This looks like an error in the LLVM verifier, so there is something wrong with the generated LLVM IR. I think we can rule out a bug in the WebAssembly LLVM backend.
Sorry I'm not sure where this would be coming from either.. It's likely due to the upgrade of LLVM for the emscripten target for sure though
Hello, Is there an ETA for the fix? Or maybe someone more familiar with the issue could guide me on where/how this can be fixed, so I can try on my own if it's not part of the roadmap yet?
This is on my backlog of things to look into, but I don't know when I will be able to get to it. I don't know of anyone else planning to look into it.
It looks like this affects as well:
tested the minimum test case (above) on wasm32-unknown-emscripten using stable (1.40.0 2019-12-16) and nightly (1.42.0 - 2020-01-01) with the same result: Called function must be a pointer! call addrspace() void &lt;badref(i8* %40), !dbg !52 in function ZN4core4iter5range116implu20u20AGT$9nextback17h9348d20e8f4fe0bcE LLVM ERROR: Broken function found, compilation aborted!
I started looking into this and I can successfully reproduce the crash. On some runs I get additional errors where the junk string is nondeterministic. Sometimes I also get the message . Clearly there is a memory corruption issue. Is there a way to build rustc and its LLVM with AddressSanitizer enabled?
It looks like this is a use-after-free when LLVM is built in release mode. It is caught earlier by an assertion with a debug build of LLVM, and from the backtrace there it looks like there is indeed a previously-unknown issue with the Emscripten exception lowering pass. We are investigating further now.
Fix in LLVM incoming: Once it merges upstream, I will handle getting it merged to Rust's LLVM fork and from there to rustc.
Should be fixed by
Were you able to verify that? I can still reproduce it with .
No, I just checked that the patch had landed. Reopening.
I thought it had been fixed because the regression test I had locally for it passes. But it turns out the test runner uses by default and the crash now needs to be triggered. I will continue looking into this.
Confirmed, thanks!

Discussion:
<del> Subproject commit a6f4c1bb07d58df5956d2c49be68547143f77b18 </del> <ins> Subproject commit a56b846ec7c96d8dc86418819baee40d70c92974 </ins>

<ins> // build-pass // compile-flags: --crate-type lib -C opt-level=0 // Regression test for LLVM crash affecting Emscripten targets pub fn foo() { (0..0).rev().next(); } </ins>
Change:
The following code, when compiled with opt level of 2 or higher results in an llvm assertion (if they're enabled) on i686-pc-windows-gnu. <details<summaryllc backtrace when compiling the --emit llvm-ir output</summary</details
I don't think it's windows-gnu specific: I'll try to backport the fix.
Opened which waits for (I don't have permission).

Discussion:
<del> Subproject commit 14a3b123074e066d64a99886941473058e52197d </del> <ins> Subproject commit cf9304d6d0c6a66c27a1664dd55d8bcc8be0bf09 </ins>
Change:
When compiling a personal project, I got an error that the compiler panicked and entered unreachable code. I've dumped the output: And I committed my code which caused the bug here: It might be because I had only written half of an anonymous function at at line 92. This is not that urgent as I only saw it with half-written code, but since the compiler suggested I file a bug I did. :
Good call! Reducing it to is enough to trigger the ICE. <details<summarybacktrace </summary
modify labels: I-ICE T-compiler C-bug A-frontend
I've traced the problem down to this call:
triage: P-high, removing nomination label.

Discussion:
crate fn unexpected<T>(&mut self) -> PResult<'a, T> { match self.expect_one_of(&[], &[]) { Err(e) => Err(e), <del> Ok(_) => unreachable!(), </del> <ins> // We can get `Ok(true)` from `recover_closing_delimiter` // which is called in `expected_one_of_not_found`. Ok(_) => FatalError.raise(), </ins> } }

<ins> // The problem in #66357 was that the call trace: // // - parse_fn_block_decl // - expect_or // - unexpected // - expect_one_of // - expected_one_of_not_found // - recover_closing_delimiter // // ended up bubbling up `Ok(true)` to `unexpected` which then used `unreachable!()`. fn f() { |[](* } //~^ ERROR expected one of `,` or `:`, found `(` //~| ERROR expected one of `)`, `-`, `_`, `box`, `mut`, `ref`, `|`, identifier, or path, found `*` </ins>

<ins> error: expected one of `,` or `:`, found `(` --> $DIR/issue-66357-unexpected-unreachable.rs:12:13 | LL | fn f() { |[](* } |             ^ expected one of `,` or `:` error: expected one of `)`, `-`, `_`, `box`, `mut`, `ref`, `|`, identifier, or path, found `*` --> $DIR/issue-66357-unexpected-unreachable.rs:12:14 | LL | fn f() { |[](* } |             -^ help: `)` may belong here |             | |             unclosed delimiter error: aborting due to 2 previous errors </ins>
Change:
Filing this since had the idea and so that we don't forget. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
It should be as easy (unless I'm overlooking something) as adding to all declaretool_lint invocations and then fixing the fallout (changing imports as described by the lint)
I'd like to handle this claim

Discussion:
declare_tool_lint! { pub rustc::DEFAULT_HASH_TYPES, Allow, <del> "forbid HashMap and HashSet and suggest the FxHash* variants" </del> <ins> "forbid HashMap and HashSet and suggest the FxHash* variants", report_in_external_macro: true </ins> } pub struct DefaultHashTypes {

declare_tool_lint! { pub rustc::USAGE_OF_TY_TYKIND, Allow, <del> "usage of `ty::TyKind` outside of the `ty::sty` module" </del> <ins> "usage of `ty::TyKind` outside of the `ty::sty` module", report_in_external_macro: true </ins> } declare_tool_lint! { pub rustc::TY_PASS_BY_REFERENCE, Allow, <del> "passing `Ty` or `TyCtxt` by reference" </del> <ins> "passing `Ty` or `TyCtxt` by reference", report_in_external_macro: true </ins> } declare_tool_lint! { pub rustc::USAGE_OF_QUALIFIED_TY, Allow, <del> "using `ty::{Ty,TyCtxt}` instead of importing it" </del> <ins> "using `ty::{Ty,TyCtxt}` instead of importing it", report_in_external_macro: true </ins> } declare_lint_pass!(TyTyKind => [

} // This module has a very short name because it's used a lot. <ins> #[allow(rustc::default_hash_types)] </ins> pub mod sym { use super::Symbol; use std::convert::TryInto;
Change:
() Triggers on playground on beta and nightly channels, not on stable. Stacktrace:
Even smaller sample (from
triage: P-high. Removing nomination.
triage: P-high, removing nomination label.

Discussion:
// can be reborrowed without needing to spill to a temporary. // If this were not the case, then we could conceivably have // to create intermediate temporaries.) <del> let ty = self.fcx.tables.borrow().expr_ty(expr); self.record(ty, scope, Some(expr), expr.span); </del> <ins> // // The type table might not have information for this expression // if it is in a malformed scope. (#66387) if let Some(ty) = self.fcx.tables.borrow().expr_ty_opt(expr) { self.record(ty, scope, Some(expr), expr.span); } else { self.fcx.tcx.sess.delay_span_bug(expr.span, "no type for node"); } </ins> } }

<ins> // edition:2018 async fn f() -> i32 { if true { //~ ERROR if may be missing an else clause return 0; } // An `if` block without `else` causes the type table not to have a type for this expr. // Check that we do not unconditionally access the type table and we don't ICE. } fn main() {} </ins>

<ins> error[E0317]: if may be missing an else clause --> $DIR/issue-66387-if-without-else.rs:3:5 | LL | /     if true { LL | |         return 0; LL | |     } | |_____^ expected (), found i32 | = note: expected type `()` found type `i32` = note: `if` expressions without `else` evaluate to `()` = help: consider adding an `else` block that evaluates to the expected type error: aborting due to previous error For more information about this error, try `rustc --explain E0317`. </ins>
Change:
The following ICEs on beta and nightly: () <details<summarygdb backtrace </summary</details
triage: P-high.

Discussion:
use rustc_data_structures::fx::FxHashMap; use rustc_index::vec::IndexVec; use rustc::ty::layout::{ <del> LayoutOf, TyLayout, LayoutError, HasTyCtxt, TargetDataLayout, HasDataLayout, </del> <ins> LayoutOf, TyLayout, LayoutError, HasTyCtxt, TargetDataLayout, HasDataLayout, Size, </ins> }; use crate::rustc::ty::subst::Subst;

use crate::const_eval::error_to_const_error; use crate::transform::{MirPass, MirSource}; <ins> /// The maximum number of bytes that we'll allocate space for a return value. const MAX_ALLOC_LIMIT: u64 = 1024; </ins> pub struct ConstProp; impl<'tcx> MirPass<'tcx> for ConstProp {

ecx .layout_of(body.return_ty().subst(tcx, substs)) .ok() <del> // Don't bother allocating memory for ZST types which have no values. .filter(|ret_layout| !ret_layout.is_zst()) </del> <ins> // Don't bother allocating memory for ZST types which have no values // or for large values. .filter(|ret_layout| !ret_layout.is_zst() && ret_layout.size < Size::from_bytes(MAX_ALLOC_LIMIT)) </ins> .map(|ret_layout| ecx.allocate(ret_layout, MemoryKind::Stack)); ecx.push_stack_frame(

) -> Option<()> { let span = source_info.span; <ins> // #66397: Don't try to eval into large places as that can cause an OOM if place_layout.size >= Size::from_bytes(MAX_ALLOC_LIMIT) { return None; } </ins> let overflow_check = self.tcx.sess.overflow_checks(); // Perform any special handling for specific Rvalue types.

<ins> // check-pass // only-x86_64 // Checks that the compiler does not actually try to allocate 4 TB during compilation and OOM crash. fn foo() -> [u8; 4 * 1024 * 1024 * 1024 * 1024] { unimplemented!() } fn main() { foo(); } </ins>

<ins> // check-pass // only-x86_64 // Checks that the compiler does not actually try to allocate 4 TB during compilation and OOM crash. fn main() { [0; 4 * 1024 * 1024 * 1024 * 1024]; } </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium. Removing nomination.

Discussion:
<del> Subproject commit 86b8643586aa39f36fb7a02e98c8d64d31415e70 </del> <ins> Subproject commit b4f1769734b6204fc6bece8556b7b80a7683271e </ins>
Change:
Follow up to and , as per Minimize a test that exercises the same codepath as
As already stated in the proc macro can be reduced to:
How do you write a UI test that depends on 3rd-party libraries?
is an example of a test that relies on a procmacro, and we can use snippet for the necessary proc_macro being tested.

Discussion:
<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_attribute] pub fn vec_ice(_attr: TokenStream, input: TokenStream) -> TokenStream { // This redundant convert is necessary to reproduce ICE. input.into_iter().collect() } </ins>

<ins> // aux-build:issue-66286.rs // Regression test for #66286. extern crate issue_66286; #[issue_66286::vec_ice] pub extern fn foo(_: Vec(u32)) -> u32 { //~^ ERROR: parenthesized type parameters may only be used with a `Fn` trait 0 } fn main() {} </ins>

<ins> error[E0214]: parenthesized type parameters may only be used with a `Fn` trait --> $DIR/issue-66286.rs:8:22 | LL | pub extern fn foo(_: Vec(u32)) -> u32 { |                      ^^^^^^^^ |                      | |                      only `Fn` traits may use parentheses |                      help: use angle brackets instead: `Vec<u32>` error: aborting due to previous error For more information about this error, try `rustc --explain E0214`. </ins>
Change:
I'm seeing an internal compiler error on the following input (found by ): Note that a similar issue () was recently closed. The fix for that ( it seems) apparently does not prevent this crash. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
It seems the ICE has been fixed in latest nightly.
Bisected, I think it has been fixed by . Adding regression test is reasonable so marked as E-needstest.

Discussion:
// ignore-tidy-linelength // ignore-wasm32-bare compiled with panic=abort by default <ins> // compile-flags: -Z mir-opt-level=3 </ins> #![feature(box_syntax)] fn main() {

<ins> // build-pass trait AssociatedConstant { const DATA: (); } impl<F, T> AssociatedConstant for F where F: FnOnce() -> T, T: AssociatedConstant, { const DATA: () = T::DATA; } impl AssociatedConstant for () { const DATA: () = (); } fn foo() -> impl AssociatedConstant { () } fn get_data<T: AssociatedConstant>(_: T) -> &'static () { &T::DATA } fn main() { get_data(foo); } </ins>

<ins> // build-pass #![feature(type_alias_impl_trait)] use std::marker::PhantomData; /* copied Index and TryFrom for convinience (and simplicity) */ trait MyIndex<T> { type O; fn my_index(self) -> Self::O; } trait MyFrom<T>: Sized { type Error; fn my_from(value: T) -> Result<Self, Self::Error>; } /* MCVE starts here */ trait F {} impl F for () {} type DummyT<T> = impl F; fn _dummy_t<T>() -> DummyT<T> {} struct Phantom1<T>(PhantomData<T>); struct Phantom2<T>(PhantomData<T>); struct Scope<T>(Phantom2<DummyT<T>>); impl<T> Scope<T> { fn new() -> Self { unimplemented!() } } impl<T> MyFrom<Phantom2<T>> for Phantom1<T> { type Error = (); fn my_from(_: Phantom2<T>) -> Result<Self, Self::Error> { unimplemented!() } } impl<T: MyFrom<Phantom2<DummyT<U>>>, U> MyIndex<Phantom1<T>> for Scope<U> { type O = T; fn my_index(self) -> Self::O { MyFrom::my_from(self.0).ok().unwrap() } } fn main() { let _pos: Phantom1<DummyT<()>> = Scope::new().my_index(); } </ins>
Change:
If the wrapped iterator implements then blindly delegates to it. The underlying iterator may know its exact size but return spurious results anyway, on which will stop iterating even though the source knows that there are elements left to iterate, meaning will indicate that there are elements left but never return them. The behavior was introduced in but didn't see any discussion.
Implementations of have soundness implications, thus marking as . That being said, the documentation for is fairly exact in its wording that the first means "end of iteration".
Hm, seeing as is not an unsafe trait, I would not expect code to be able to rely on it for soundness? Maybe we do so internally for std types though...
Unsafe code can't rely on correctness (there's for that). The length of an iterator is defined as the number of items yielded before it returns None, so Fuse's implementation is correct.
Oh my bad, I was confusing it with TrustedLen.
Ok, makes sense. But I will be pedantic here since I prefer documentation to have slightly more formal flavor. docs: The module documentation: Now resume can be interpreted as continuing the the previous iteration instead of starting a new iteration (conceptually a new iteration would require a new iterator then). Under this interpretation should report the complete length of all iteration including possible resumptions which must be known when claiming exact sizing knowledge. The documentation could use a more precise definition of what an iteration is and that resumption is really considered a new iteration.

Discussion:
//! are elements, and once they've all been exhausted, will return `None` to //! indicate that iteration is finished. Individual iterators may choose to //! resume iteration, and so calling [`next`] again may or may not eventually <del> //! start returning `Some(Item)` again at some point. </del> <ins> //! start returning `Some(Item)` again at some point (for example, see [`TryIter`]). </ins> //! //! [`Iterator`]'s full definition includes a number of other methods as well, //! but they are default methods, built on top of [`next`], and so you get

//! [`Iterator`]: trait.Iterator.html //! [`next`]: trait.Iterator.html#tymethod.next //! [`Option`]: ../../std/option/enum.Option.html <ins> //! [`TryIter`]: ../../std/sync/mpsc/struct.TryIter.html </ins> //! //! # The three forms of iteration //!

/// ``` #[stable(feature = "rust1", since = "1.0.0")] pub trait ExactSizeIterator: Iterator { <del> /// Returns the exact number of times the iterator will iterate. </del> <ins> /// Returns the exact length of the iterator. </ins> /// <ins> /// The implementation ensures that the iterator will return exactly `len()` /// more times a `Some(T)` value, before returning `None`. </ins> /// This method has a default implementation, so you usually should not /// implement it directly. However, if you can provide a more efficient /// implementation, you can do so. See the [trait-level] docs for an
Change:
Leaving this issue as a reminder for It should be as simple as adding a checkplace call to the <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This bug appears in as well: Might as well stop letting inline ASM through to MIRI while you're at it.
I'm taking this one :P
assign

Discussion:
trace!("visit_statement: statement={:?} location={:?}", statement, location); match statement.kind { <del> StatementKind::Assign(..) => { </del> <ins> StatementKind::Assign(..) | StatementKind::SetDiscriminant { .. } => { </ins> self.super_statement(statement, location); } StatementKind::FakeRead(FakeReadCause::ForMatchedPlace, _) => {

} // FIXME(eddyb) should these really do nothing? StatementKind::FakeRead(..) | <del> StatementKind::SetDiscriminant { .. } | </del> StatementKind::StorageLive(_) | StatementKind::StorageDead(_) | StatementKind::InlineAsm {..} |

StatementKind::FakeRead(_, place) => check_place(tcx, place, span, def_id, body), // just an assignment <del> StatementKind::SetDiscriminant { .. } => Ok(()), </del> <ins> StatementKind::SetDiscriminant { place, .. } => check_place(tcx, place, span, def_id, body), </ins> | StatementKind::InlineAsm { .. } => { Err((span, "cannot use inline assembly in const fn".into()))
Change:
The corresponding issue has been closed by PR , so is that passage still relevant or can it be removed? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems likely it can be removed. Marking as E-help-wanted; I don't expect we'll do this ourselves but if someone files a PR removing the comment I think it's likely we can accept that pretty easily.
Hi:) I would like to work on this.
claim

Discussion:
// Note, however, that we run on lots older linuxes, as well as cross // compiling from a newer linux to an older linux, so we also have a // fallback implementation to use as well. <del> // // Due to rust-lang/rust#18804, make sure this is not generic! </del> #[cfg(any( target_os = "linux", target_os = "fuchsia",
Change:
This code ran in the latest nightly(2019-11-19) does not compile: And it prints this error message
Reduced:
that gives a different error, because isn't defined. Perhaps you meant something like:
This appears to be working now.

Discussion:
<ins> #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash pub struct MyArray<const COUNT: usize>([u8; COUNT + 1]); //~^ ERROR constant expression depends on a generic parameter impl<const COUNT: usize> MyArray<COUNT> { fn inner(&self) -> &[u8; COUNT + 1] { //~^ ERROR constant expression depends on a generic parameter &self.0 } } fn main() {} </ins>

<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-61522-array-len-succ.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default error: constant expression depends on a generic parameter --> $DIR/issue-61522-array-len-succ.rs:4:40 | LL | pub struct MyArray<const COUNT: usize>([u8; COUNT + 1]); |                                        ^^^^^^^^^^^^^^^ | = note: this may fail depending on what value the parameter takes error: constant expression depends on a generic parameter --> $DIR/issue-61522-array-len-succ.rs:8:24 | LL |     fn inner(&self) -> &[u8; COUNT + 1] { |                        ^^^^^^^^^^^^^^^^ | = note: this may fail depending on what value the parameter takes error: aborting due to 2 previous errors </ins>

<ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash trait Trait<const NAME: &'static str> { type Assoc; } impl Trait<"0"> for () { type Assoc = (); } fn main() { let _: <() as Trait<"0">>::Assoc = (); } </ins>

<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-66596-impl-trait-for-str-const-arg.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>
Change:
This causes a crash when trying to test libcore with cgclif, as Cranelift doesn't allow incompatible definitions of the same function. While this currently works for cgllvm, according to it is likely to become forbidden with cg_llvm too.
modify labels:+A-cranelift

Discussion:
+ +[dependencies] +rand = "0.7" <del> diff --git a/library/core/tests/ptr.rs b/library/core/tests/ptr.rs index 1a6be3a..42dbd59 100644 --- a/library/core/tests/ptr.rs +++ b/library/core/tests/ptr.rs @@ -250,6 +250,7 @@ fn test_unsized_nonnull() { }; } +/* #[test] #[allow(warnings)] // Have a symbol for the test below. It doesn’t need to be an actual variadic function, match the @@ -277,6 +277,7 @@ pub fn test_variadic_fnptr() { let mut s = SipHasher::new(); assert_eq!(p.hash(&mut s), q.hash(&mut s)); } +*/ #[test] fn write_unaligned_drop() { </del> -- 2.21.0 (Apple Git-122)

#![feature(const_ptr_offset)] #![feature(const_trait_impl)] #![feature(const_likely)] <ins> #![feature(core_ffi_c)] </ins> #![feature(core_intrinsics)] #![feature(core_private_bignum)] #![feature(core_private_diy_float)]

} #[test] <del> #[allow(warnings)] // Have a symbol for the test below. It doesn’t need to be an actual variadic function, match the // ABI, or even point to an actual executable code, because the function itself is never invoked. #[no_mangle] </del> <ins> #[cfg(unix)] // printf may not be available on other platforms #[allow(deprecated)] // For SipHasher </ins> pub fn test_variadic_fnptr() { <ins> use core::ffi; </ins> use core::hash::{Hash, SipHasher}; extern "C" { <del> fn test_variadic_fnptr(_: u64, ...) -> f64; </del> <ins> // This needs to use the correct function signature even though it isn't called as some // codegen backends make it UB to declare a function with multiple conflicting signatures // (like LLVM) while others straight up return an error (like Cranelift). fn printf(_: *const ffi::c_char, ...) -> ffi::c_int; </ins> } <del> let p: unsafe extern "C" fn(u64, ...) -> f64 = test_variadic_fnptr; </del> <ins> let p: unsafe extern "C" fn(*const ffi::c_char, ...) -> ffi::c_int = printf; </ins> let q = p.clone(); assert_eq!(p, q); assert!(!(p < q));