jiebi/CodeConvo huggingface dataset:
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. // xfail-pretty // Don't fail on blocks without results // There are several tests in this run-pass that raised // when this bug was oppened. The cases where the compiler // failed before the fix have a comment. struct S {x:()} fn test(slot: &mut Option<proc() -> proc()>, _: proc()) -> () { let a = slot.take(); let _a = match a { // `{let .. a(); }` would break Some(a) => { let _a = a(); }, None => (), }; } fn not(b: bool) -> bool { if b { !b } else { // `fail!(...)` would break fail!("Break the compiler"); } } pub fn main() { // {} would break let _r = {}; let mut slot = None; // `{ test(...); }` would break let _s : S  = S{ x: { test(&mut slot, proc() {}); } }; let _b = not(true); } </ins>

Discussion:
Was trying to find another bug, found this bug! That code will fail with
I'll take it
Different testcases: EDIT: Found more testcases
Interesting. I'm looking into it. Not sure what is causing this, though.
Another testcase: (The and are both necessary.)
Even simpler example: Debug Log EDIT: Making the block return doesn't raise this issue.
My final testcase:
Could this be related to the no-argument version of lambda block expressions that were used in syntax? Looking in , there's a comment to this form of lambda expressions used with . As far as why doesn't raise the issue, maybe that's parsed as a block expression instead?
I don't see how it could be related. The error here has to do with a (or just zero-sized? I'm not sure) result of a block being stored somewhere. I'm not even sure the assert needs to be that strict.
Yet another test case to consider:
thanks! I'll get back to debug this in a bit
Change:
} }; <del> if !fn_abi.ret.is_ignore() { classify_ret(cx, &mut fn_abi.ret, abi); } </del> <ins> classify(cx, &mut fn_abi.ret, abi, true); </ins> for arg in fn_abi.args.iter_mut() { <del> if arg.is_ignore() { continue; } classify_arg(cx, arg, abi); </del> <ins> classify(cx, arg, abi, false); </ins> } }

Discussion:
I tried this code: I expected to see this happen: test suite passing Instead, this happened: The return failure is: The pass failure is: : This occurs in every version since the test was . I see this with 1.79.0 and 1.80.0 as well as my 1.81.0 beta build (). I haven't dug in to all of the nitty-gritty yet, but I have a feeling may be potentially incorrect?
Indeed, if I remove those two lines, it passes the tests correctly: But I'm not sure why they are there and if this could possibly cause breakage elsewhere. I'd be happy to open a PR with this change for comment if that is the best way forward, or we can continue to discuss here.
Indeed, there is fallout - this test used to pass:
Reading over the ELF ABI specification and how LLVM and GCC implement this, arguments and return values should be treated the same. So, trying to duplicate the logic from in yielded me: and gave me: which is actually the first time I've ever seen Rust complete its test suite fully on a big endian PPC64/musl environment! Since the logic doesn't vary between endian in , I'm not sure why it should in . Unfortunately, I don't have any spare hardware to try and run little-endian, so I can't test if this change actually does the right thing on LE. I suppose since the original code had a BE case which was suspiciously similar to the first half of , I could do the code as another branch there. But that feels ugly, and I'd like to know if this simpler way would work on both endians before trying to shoehorn deeper nested branches.
Change:
// Check if `malloc` failed: if p as usize == 0 { <del> abort(); </del> <ins> intrinsics::abort(); </ins> } p

Discussion:
The following file, when compiled without optimizations, correctly generates an overflow check in : However, compiling with optimizations plus or generates code without the overflow check. However, if I move to a separate no_core crate like this, the issue disappears and the overflow check is generated:
noticed that my panic implementation () is UB according to LLVM (see ), so it optimizes the overflow check out on the assumption that it can never be triggered (since that would be UB). Replacing it with e.g. fixes the issue.
Change:
<ins> // Copyright 2015 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. // Test that we don't ICE when we are missing the owned_box lang item. // error-pattern: requires `owned_box` lang_item #![no_std] #![feature(lang_items, no_std, box_syntax)] extern crate core; fn main() { let x = box 1i32; } #[lang = "stack_exhausted"] extern fn stack_exhausted() {} #[lang = "eh_personality"] extern fn eh_personality() {} #[lang = "panic_fmt"] fn panic_fmt() -> ! { loop {} } </ins>

Discussion:
Hi, first time contributor here. This might be a bug. I think every factor mentioned in the title is required to trigger this. (I'm trying to do horrible things to the runtime, but I don't think this is significant here.) Source: Backtrace (rustc 0.13.0-nightly ( 2015-01-04 00:50:59 +0000) installed via rustup on Ubuntu LTS):
This happened to me as well, with an almost identical program. More info:
Following the backtrace, it looks like assumes that the 'ownedbox' lang item is always defined and calls unwrap(), triggering the panic.
Triage: still ICEs:
Change:
/// /// ``` /// trait Foo { <del> ///     fn bar(&self); </del> <ins> ///     fn bar(&self) -> u8; </ins> ///     fn baz(&self); <ins> ///     fn qux(&self) -> Result<u64, ()>; </ins> /// } /// ``` /// /// We want to implement `Foo` on one of our types, but we also want to work on /// just `bar()` first. In order for our code to compile, we need to implement <del> /// `baz()`, so we can use `todo!`: </del> <ins> /// `baz()` and `qux()`, so we can use `todo!`: </ins> /// /// ``` /// # trait Foo { <del> /// #     fn bar(&self); </del> <ins> /// #     fn bar(&self) -> u8; </ins> /// #     fn baz(&self); <ins> /// #     fn qux(&self) -> Result<u64, ()>; </ins> /// # } /// struct MyStruct; /// /// impl Foo for MyStruct { <del> ///     fn bar(&self) { ///         // implementation goes here </del> <ins> ///     fn bar(&self) -> u8 { ///         1 + 1 </ins> ///     } /// ///     fn baz(&self) { <del> ///         // let's not worry about implementing baz() for now </del> <ins> ///         // Let's not worry about implementing baz() for now </ins> ///         todo!(); ///     } <ins> /// ///     fn qux(&self) -> Result<u64, ()> { ///         // We can add a message to todo! to display our omission. ///         // This will display: ///         // "thread 'main' panicked at 'not yet implemented: MyStruct is not yet quxable'". ///         todo!("MyStruct is not yet quxable"); ///     } </ins> /// } /// /// fn main() { ///     let s = MyStruct; ///     s.bar(); /// <del> ///     // we aren't even using baz(), so this is fine. </del> <ins> ///     // We aren't even using baz() or qux(), so this is fine. </ins> /// } /// ``` #[macro_export]

Discussion:
The documentation of the macro currently does not mention at all that it also accepts optional format arguments, for example: Other macros like at least have the following sentence under "Panics": So maybe it would be good to do the following? [ ] Update the "Panics" section to be similar to [ ] Extend / adjust example to also show usage of custom message <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Any ? I mostly drew from the docs for , and I also took the liberty of cleaning up some of the formatting/typography.
Thanks! To me this looks good, but I don't know what the maintainers think.
Change:
} /// The `InterpCx` is only meant to be used to do field and index projections into constants for <del> /// `simd_shuffle` and const patterns in match arms. </del> <ins> /// `simd_shuffle` and const patterns in match arms. It never performs alignment checks. </ins> /// /// The function containing the `match` that is currently being analyzed may have generic bounds /// that inform us about the generic bounds of the constant. E.g., using an associated constant

Discussion:
code from rustc this causes a new panic when executed via miri:
Ah, there was a reason why we disabled alignment checks in CTFE... This can probably be reproduced without Miri by passing -Zextra-const-ub-checks to rustc.
Yeah this just need "cargo miri run", no additional flags required. Edit: oops, misread :sweat_smile:
Right, this does also reproduce with . Do you want to move the issue?
Yeah let's move this to the rustc repo.
Change:
in_root: true, handler: handler, is_proc_macro_crate: is_proc_macro_crate, <ins> is_test_crate: is_test_crate, </ins> }; visit::walk_crate(&mut collect, &krate);

Discussion:
I setup a crate using the example from There are no tests setup: no tests folder, no #[test] attributes. succeeds fails with: #[procmacroderive]proc-macro Naturally I expected this error not to occur. Run on the latest nightly via rustup: rustc 1.14.0-nightly ( 2016-10-27) binary: rustc commit-hash: commit-date: 2016-10-27 host: x86_64-unknown-linux-gnu release: 1.14.0-nightly LLVM version: 3.9
You can probably work around this by using (although I haven't tested that).
Thanks for the report! I'm not sure what the best way to solve this would be. We could either tell the compiler that doesn't work for these crate types, or we could tell Cargo to not test proc-macro libraries. Both should have the end goal though of having work by default.
Would a simple fix for this be to add to ? Or should - where it currently panics - quietly bail out if this is a test crate?
I'd personally prefer for to keep doing the same feature gating it's doing today, so in that sense I don't think it should take the same bail-out route that rustdoc takes. Adding some logic to though sounds good to me.
I think it was wrong that this ticket was closed with since it states
Actually fixing this appears simpler than I expected. I'm guessing a should be enough. This will ensure all the feature gating is still done, but no expansion is performed. Did you have any further thoughts?
of it works it works for me!
this is failing again. It works correctly on nightly-2017-01-17 rustc 1.16.0-nightly ( 2017-01-17) but fails on nightly-2017-01-18 rustc 1.16.0-nightly ( 2017-01-17).
This could be related to recently enabling doc-testing of proc-macro crates in cargo This rustc change should fix that If you look at the cargo output, does the error happen when running the normal tests, or after trying to run doc-tests? Edit: I've tested this in the latest nightly from rustup, and this is definitely what is happening. Hopefully it will be fixed soon.

thanks for staying on top of this! I've approved and p=1'd it to hopefully get it in soon. sorry for the breakage!
Change:
<ins> //check-pass #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] struct Foo<const N: usize> where [(); N + 1]: ; impl<const N: usize> Drop for Foo<N> where [(); N + 1]: , { fn drop(&mut self) {} } fn main() {} </ins>

Discussion:
This issue seems to be specific to the trait. : label A-const-generics F-constevaluatablechecked T-compiler
Also, is it expected that the where bounds need to be repeated in each of the type's trait impls?
Yes, bounds on type definitions need to be repeated in impls, at least until are introduced.
Is anyone aware of a way to work around this issue at the moment?
Change:
an example block that looks like this: ```text <del> /// Some documentation. # fn foo() {} </del> <ins> /// /// Some documentation. /// # fn foo() {} // this function will be hidden /// println!("Hello, World!"); </ins> ``` It will render like this:

Discussion:
See for details. Let me know if anything needs clarification.
cc
Oh! That could use some clarification. Thanks for the report!
You're welcome!
Change:
<ins> // check-pass #![crate_type = "lib"] pub struct Foo; pub struct Path<T: Bar> { _inner: T::Slice, } pub trait Bar: Sized { type Slice: ?Sized; fn open(_: &Path<Self>); } impl Bar for Foo { type Slice = [u8]; fn open(_: &Path<Self>) { unimplemented!() } } </ins>

Discussion:
Minimal example:
can you reproduce?
I can try, this is from Mar 2nd so not related to my recent changes right?
yes it fails for me with both stable rust 1.25 and the latest nightly rustc 1.27.0-nightly ( 2018-04-11). It's not failing in a part of typeck that I'm familiar with but I'll have a look sometime and see if it makes any sense to me.
Yes this is unrelated to that PR (I think there isn't a nightly including it yet). But since this is related to I thought you might want to take a look.
I started expanding the minimal example so that it didn't depend on nalgebra, it has expanded into quite a lot of code This example is enough to break the compiler but doesn't compile if the ICE is fixed (e.g. if the is commented out). For it to compile it still needs some external dependencies. It appears to be the associated type that is hitting the ICE.
Yeah 's example is huge. Maybe he doesn't know that minimal examples should have no dependencies. if you don't provide minimal examples in bug reports (that is: no dependencies; they should compile in the play ground) they'll take much longer than necessary to fix.
I understand. I'm a relative beginner to rust, so it would take quite a lot of time for me to figure out how to make a more minimal example. I am able to work around this issue in my own code, so it's not that important to me, but I figured it might be easy for someone more experienced to spot what was going wrong. If you don't think it's worth the effort to investigate further, I have no problem with you closing this until a more simple manifestation is discovered.
I've reduced it to the following ():
It's no longer reproduced an ICE on the latest nightly, it seems from 1.38.0. marked as E-needstest
Change:
<ins> error[E0369]: binary operation `+` cannot be applied to type `&str` --> $DIR/issue-47380.rs:12:33 | 12 |     println!("🦀🦀🦀🦀🦀"); let _a = b + ", World!"; |                                      ^^^^^^^^^^^^^^ `+` can't be used to concatenate two `&str` strings help: `to_owned()` can be used to create an owned `String` from a string reference. String concatenation appends the string on the right to the string on the left and may require reallocation. This requires ownership of the string on the left | 12 |     println!("🦀🦀🦀🦀🦀"); let _a = b.to_owned() + ", World!"; |                                      ^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
This code (containing tabs) gives an error (): The error works fine on stable: But is mispositioned on rustc 1.25.0-nightly ( 2018-01-11) as well as on rustc 1.24.0-beta.2 ( 2018-01-10): cc
Interesting. Im new to code work so following you guys has been extremely helpful thanks
Using bisect-rust I could see that the issue started with , but probably the actual issue is somewhere else (e.g. in the machinery in that starts using for tabs).
Yeah, the issue also exists when emojis are involved (no tabs): Gives: The emoji manifestation of the issue is no beta regression, seems to exist on stable as well.
I've created for the emoji/unicode issue.
It seems to me that the issue only manifests itself in suggestions, and that is handled separately from the main diagnostics. Mentoring instructions:  needs to be modified to use instead of , the start being and the end being ( already accounts for unicode chars). This change should fix both this and .
Will pick this up
Change:
<ins> //! Previously we would try to issue a suggestion for `let x <op>= 1`, i.e. a compound assignment //! within a `let` binding, to remove the `<op>`. The suggestion code unfortunately incorrectly //! assumed that the `<op>` is an exactly-1-byte ASCII character, but this assumption is incorrect //! because we also recover Unicode-confusables like `➖=` as `-=`. In this example, the suggestion //! code used a `+ BytePos(1)` to calculate the span of the `<op>` codepoint that looks like `-` but //! the mult-byte Unicode look-alike would cause the suggested removal span to be inside a //! multi-byte codepoint boundary, triggering a codepoint boundary assertion. //! //! issue: rust-lang/rust#128845 fn main() { // Adapted from #128845 but with irrelevant components removed and simplified. let x ➖= 1; //~^ ERROR unknown start of token: u{2796} //~| ERROR: can't reassign to an uninitialized variable } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' 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: --
Can you start pingbacking at least for all of these?
ice since
can you add a filter for is:issue is:open label:I-ICE "bpos.to_u32" into the ticket you mentioned? That should find all relevant past an future issues automatically I think.
A filter? How do I do that?
oh, you mean a link
I a label , I'll go back and tag some of them later.
Change:
<ins> error[E0072]: recursive type `ExplicitlyPadded` has infinite size --> $DIR/transmute_infinitely_recursive_type.rs:22:5 | LL |     struct ExplicitlyPadded(ExplicitlyPadded); |     ^^^^^^^^^^^^^^^^^^^^^^^ ---------------- recursive without indirection | help: insert some indirection (e.g., a `Box`, `Rc`, or `&`) to break the cycle | LL |     struct ExplicitlyPadded(Box<ExplicitlyPadded>); |                             ++++                + error[E0391]: cycle detected when computing layout of `should_pad_explicitly_packed_field::ExplicitlyPadded` | = note: ...which immediately requires computing layout of `should_pad_explicitly_packed_field::ExplicitlyPadded` again = note: cycle used when evaluating trait selection obligation `(): core::mem::transmutability::BikeshedIntrinsicFrom<should_pad_explicitly_packed_field::ExplicitlyPadded, assert::Context, core::mem::transmutability::Assume { alignment: false, lifetimes: false, safety: false, validity: false }>` = note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information error: aborting due to 2 previous errors Some errors have detailed explanations: E0072, E0391. For more information about an error, try `rustc --explain E0072`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'not implemented: Cycle'', 'thread 'rustc' panicked at 'not implemented: Cycle'' 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
/ ping :grin:
Change:
const my_exports = {}; let nexports = 0; for (const entry of list) { <del> if (entry.kind !== 'function') continue; my_exports[entry.name] = true; nexports += 1; </del> <ins> if (entry.kind == 'function'){ nexports += 1; } my_exports[entry.name] = entry.kind; </ins> } <del> if (my_exports.foo === undefined) </del> <ins> if (my_exports.foo != "function") </ins> throw new Error("`foo` wasn't defined"); <ins> if (my_exports.FOO != "global") throw new Error("`FOO` wasn't defined"); </ins> if (my_exports.main === undefined) { if (nexports != 1) throw new Error("should only have one function export");

Discussion:
Repro rustc 1.40.0 ( 2019-12-16) , the resulting wasm file doesn't have the symbol . But if we compile with , the symbol is correctly exported in the wasm file. Expected behavior: Public static variables should get exported by default. We believe this is a regression from 1.39.0. Does correctly export static variables.
cc
Symbols for wasm are and it looks like no flag is passed for , which is the bug. It looks like this may trace back to not including statics, but that's just a guess. I don't personally have time to deeply investigate this right now.
After a some investigation: disables , which means all the symbols are exported. This is why appears. If is set, symbols have to be exported , which is not the case for as has stated above The reason for this is is false. is a rust symbol and we export to a c lib. Statics are explicitly marked as . It is unclear to me how this should be handled. Maybe statics should be exported with if the static is a number? I'll make a PR for it, that might be a better place to talk about implementation details.
Oh good find! I'm not sure about emscripten, but wasm has changed in the meantime so that it can export statics, so the wasm case there I believe can be removed.
Change:
<ins> //@ aux-build:block-on.rs //@ edition:2021 //@ run-pass //@ check-run-results // Same as miri's `tests/pass/async-closure-captures.rs`, keep in sync #![feature(async_closure)] extern crate block_on; fn main() { block_on::block_on(async_main()); } async fn call<T>(f: &impl async Fn() -> T) -> T { f().await } async fn call_once<T>(f: impl async FnOnce() -> T) -> T { f().await } #[derive(Debug)] #[allow(unused)] struct Hello(i32); async fn async_main() { // Capture something by-ref { let x = Hello(0); let c = async || { println!("{x:?}"); }; call(&c).await; call_once(c).await; let x = &Hello(1); let c = async || { println!("{x:?}"); }; call(&c).await; call_once(c).await; } // Capture something and consume it (force to `AsyncFnOnce`) { let x = Hello(2); let c = async || { println!("{x:?}"); drop(x); }; call_once(c).await; } // Capture something with `move`, don't consume it { let x = Hello(3); let c = async move || { println!("{x:?}"); }; call(&c).await; call_once(c).await; let x = &Hello(4); let c = async move || { println!("{x:?}"); }; call(&c).await; call_once(c).await; } // Capture something with `move`, also consume it (so `AsyncFnOnce`) { let x = Hello(5); let c = async move || { println!("{x:?}"); drop(x); }; call_once(c).await; } } </ins>

Discussion:
Something is still wrong w/ async call shims. I think I'm not doing the transform correctly or something. Putting this up so I don't forget about it, but I'll fix it.
ohhhhh lol it's drop glue. Huh.
Oh hell yes this is actually totally wrong wtf:
Change:
let main_attr = ecx.attr_word(sym::rustc_main, sp); // #[coverage(off)] let coverage_attr = ecx.attr_nested_word(sym::coverage, sym::off, sp); <del> // #[allow(missing_docs)] let missing_docs_attr = ecx.attr_nested_word(sym::allow, sym::missing_docs, sp); </del> <ins> // #[doc(hidden)] let doc_hidden_attr = ecx.attr_nested_word(sym::doc, sym::hidden, sp); </ins> // pub fn main() { ... } let main_ret_ty = ecx.ty(sp, ast::TyKind::Tup(ThinVec::new()));

Discussion:
I tried this code: I expected to see this happen: no errors Instead, this happened: : Very likely to be related
Looks like allowed missing docs on the generated function, but didn't test having any actual s. cc
Attempt fix in