jiebi/CodeConvo huggingface dataset:
Change:
<ins> // build-fail // ignore-emscripten no asm! support // Regression test for #69092 #![feature(asm)] fn main() { unsafe { asm!(".ascii "Xen0""); } //~^ ERROR: <inline asm>:1:9: error: expected string in '.ascii' directive } </ins>

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd like to work on this. claim
Now ICE no longer occurs, I think it's fixed by . Marked as E-needstest.

When executed in the : <details<summaryCompiler output</summary</detailsEDIT: Here's the updated and the new stack trace as of Jan 7, 2020: <details<summaryCompiler output</summary</details
cc
I think this is another instance of However, we can leave this issue open to remember to add a test case when it's fixed.
The original issue no longer ICEs and instead errors with: which is essentially correct. However, providing the type annotations produces a new ICE:
In Source: <details<summaryStack trace</summary<p</p</details
Now ICE no longer occurs. I think it's fixed by .

This occurs on 1.34.1 and 1.34.0, is a regression from 1.33.0, and does.. not occur on nightly? Reproduction: compiled with Yields: I found this in building crates like and but pared it down to this
I think this is fixed in which might explain why it doesn't occur on nightly
triage: Probably fixed by . Normally an ICE would lead me to tag this as P-high, but the fact that this is only exposed by leads me to prioritize this as P-medium.
assigning to self to confirm that is the reason this is fixed, and (if need be) add a regression test.
Here's a slightly smaller case of what appears to potentially be the same thing which shows up if you select the "show MIR" option in In particular the following error is observed:
I think this issue is fixed in all channels. I tried stable and nightly both locally and on , and couldn't get any ICEs. Should we add a test? Otherwise we can just close I think.
Adding a test with seems like a good idea.

Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.
Change:
<ins> // build-fail // ignore-emscripten no asm! support // Regression test for #69092 #![feature(asm)] fn main() { unsafe { asm!(".ascii "Xen0""); } //~^ ERROR: <inline asm>:1:9: error: expected string in '.ascii' directive } </ins>

Discussion:
results in: Removing the constgenerics feature flag gets the expected error message: (IIUC that itself is a bug related to ) Using directly outside of a const-context works, which I guess is something const_generics enables that isn't otherwise allowed. Finally, the error message is the same whether or not the code is in a provided method or a impl block; I actually ran into the bug in the later.
I believe this should be fixed by
Now, it shows different ICE(s) ():
Now ICE no longer occurs. I think it's fixed by .
Change:
let ctxt = BreakableCtxt { // cannot use break with a value from a while loop coerce: None, <del> may_break: true, </del> <ins> may_break: false,  // Will get updated if/when we find a `break`. </ins> }; <del> self.with_breakable_ctxt(expr.id, ctxt, || { </del> <ins> let (ctxt, ()) = self.with_breakable_ctxt(expr.id, ctxt, || { </ins> self.check_expr_has_type_or_error(&cond, tcx.types.bool); let cond_diverging = self.diverges.get(); self.check_block_no_value(&body);

Discussion:
Having the following main function results in an illigal instruction on stable, beta and nighlty. It should be noted that when is not used after the loop, the illigal instruction does not occur Interestingly putting the same while-loop in a function works fine:
Update: A more simple version that also results in an illigal instruction: after some more trying, it can be shortened to this (and works for functions other than in main, as shown here: ) : adding a statement at the end of main seems to 'fix' the problem
Checking with godbolt, 1.25 and above: results in undefined instruction (this issue) 1.18 to 1.24: ICE with broken MIR 1.17: becomes no-op 1.16 and below: Error "use of undeclared label "
Err the last example is even featured in (introduced in ), but why this seems not tested at all . Edit: It generates an at MIR level. <details<summaryThe initial MIR already contains an unreachable.</summary</details<details<summary-Zunpretty=hir,typed</summary</details
It's because in the example that is tested, there's no semicolon: Why that makes a difference, I haven't determined yet.
The problem is, for some reason, the type checker inferred to have type , and thus the rest of the block is . However, without the the inferred type is just as expected.
Maybe slightly off-topic, but why are references to the label even allowed in the condition, rather than solely the body? You don't achieve extra expressiveness, as it's equivalent to returning false in the condition, and it makes things more complicated.
having code like this results in an ICE:
Because it is consistent with the desugaring of the while loop to a which is a valid and fairly sensible code.
I think the bug in in the type-checker then: it should not be giving the type of , clear. — you interested in fixing? I can give a few tips...
Marking as P-medium: technically a regression, but a very old one, and kind of a corner case. Still, I'll try to leave some notes on how to fix.
yeah, I can have a look into this. Might be a little delayed, but definitely within the next couple of weeks.
Change:
let trait_predicate = infcx.resolve_type_vars_if_possible(trait_predicate); <del> if !trait_predicate.references_error() { </del> <ins> if !infcx.tcx.sess.has_errors() || !trait_predicate.references_error() { </ins> let trait_ref = trait_predicate.to_poly_trait_ref(); span_err!(infcx.tcx.sess, obligation.cause.span, E0277, "the trait `{}` is not implemented for the type `{}`",

Discussion:
Hello folks, I'm dutifully reporting this as the compiler told me to so. The bug is the same reported already by and , although it appeared on a different circumstance. I have this simple program (I'm a Rust newbie so It's very likely I'm doing things terribly wrong): Expected outcome: The compile to tell me how wrong I am Actual outcome: Meta Shows up with latest beta as well:
cc me
Minified: We do write tyerr to node 11 (). Apparently we somehow don't report an error.
triage: P-medium
Whoops. There is indeed an error, which is indeed gets to reportselectionerror, but when we do (), we get an error, and think this one was a duplicate.
no_std version:
You don't even need the trait:
Change:
), ); } <del> self.check_bb(location, *target); </del> <ins> self.check_edge(location, *target, EdgeKind::Normal); </ins> if let Some(cleanup) = cleanup { <del> self.check_bb(location, *cleanup); </del> <ins> self.check_edge(location, *cleanup, EdgeKind::Unwind); </ins> } } TerminatorKind::Yield { resume, drop, .. } => { <del> self.check_bb(location, *resume); </del> <ins> self.check_edge(location, *resume, EdgeKind::Normal); </ins> if let Some(drop) = drop { <del> self.check_bb(location, *drop); </del> <ins> self.check_edge(location, *drop, EdgeKind::Normal); </ins> } } TerminatorKind::FalseEdge { real_target, imaginary_target } => { <del> self.check_bb(location, *real_target); self.check_bb(location, *imaginary_target); </del> <ins> self.check_edge(location, *real_target, EdgeKind::Normal); self.check_edge(location, *imaginary_target, EdgeKind::Normal); </ins> } TerminatorKind::FalseUnwind { real_target, unwind } => { <del> self.check_bb(location, *real_target); </del> <ins> self.check_edge(location, *real_target, EdgeKind::Normal); </ins> if let Some(unwind) = unwind { <del> self.check_bb(location, *unwind); </del> <ins> self.check_edge(location, *unwind, EdgeKind::Unwind); </ins> } } TerminatorKind::InlineAsm { destination, .. } => { if let Some(destination) = destination { <del> self.check_bb(location, *destination); </del> <ins> self.check_edge(location, *destination, EdgeKind::Normal); </ins> } } // Nothing to validate for these.

Discussion:
Blocks that are part of unwinding code always need to marked as . This seems like an easy thing to check in the validation pass. I believe this would have caught a bug in the generator transform (a pretty long time ago). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Good point! Moreover, cleanup block terminators should also only jump to cleanup blocks, and other terminators should only jump to non-cleanup blocks. Basically, unwind edges must be the only ones that cross the "cleanup to non-cleanup" boundary. (Miri is already checking this.)
claim
Change:
if layout.size.bytes() % layout.align.abi.bytes() != 0 { bug!("size is not a multiple of align, in the following layout:n{layout:#?}"); } <ins> if layout.size.bytes() >= cx.tcx.data_layout.obj_size_bound() { bug!("size is too large, in the following layout:n{layout:#?}"); } </ins> if !cfg!(debug_assertions) { // Stop here, the rest is kind of expensive.

Discussion:
rustc generally detects when a static type is larger than bytes, giving an error that + 10x80000000isize::MAX + 1`): (The is to ensure that an object of size is actually created on the stack.) This is clearly unsound, since it breaks the size invariant of , and since third-party crates may depend on types being no larger than for soundness. However, it's nontrivial to observe unexpected behavior from this using only safe APIs in the standard library, since placing the overlarge type within any other type, even a wrapper, will result in a compile error as expected, and the standard APIs tend to refer to when creating a slice from a reference.
Wow, good catch! Looks like we're doing the check before rounding up to the next multiple of alignment? That's bad.
Change:
const STACK_SIZE: usize = 32_000_000; // 32MB env_logger::init().unwrap(); let res = std::thread::Builder::new().stack_size(STACK_SIZE).spawn(move || { <del> let s = env::args().collect::<Vec<_>>(); main_args(&s) </del> <ins> get_args().map(|args| main_args(&args)).unwrap_or(1) </ins> }).unwrap().join().unwrap_or(101); process::exit(res as i32); } <ins> fn get_args() -> Option<Vec<String>> { env::args_os().enumerate() .map(|(i, arg)| arg.into_string().map_err(|arg| { print_error(format!("Argument {} is not valid Unicode: {:?}", i, arg)); }).ok()) .collect() } </ins> fn stable(g: getopts::OptGroup) -> RustcOptGroup { RustcOptGroup::stable(g) } fn unstable(g: getopts::OptGroup) -> RustcOptGroup { RustcOptGroup::unstable(g) }

Discussion:
I was able to perform the commands above successfully with both fish and bash fish bash
I am able to as well. Closing! Thanks for the triage.
Hm I'm actually quite surprised that this works. What versions of the compilers were you using? For me it continues to not work:
Oh this may be a shell thing (I'm using zsh), when running after executing the commands in bash I see: I think that the escape syntax for bash must be different.
I just tried zsh and got your error:
Reproducable in bash (note the ).
It now fails saying, "called on an value". I believe this is simply due to using rather than , so it panics on the non-utf8. You can reproduce this with any bad argument at all, e.g. in bash: Accepting will require changes down through the crate, and I guess all the other users of that should be updated too. I'm interested to try, if this sounds ok...
Change:
<ins> error: any use of this value will cause an error --> $DIR/ub-incorrect-vtable.rs:10:14 | LL | / const INVALID_VTABLE_ALIGNMENT: &dyn Trait = LL | |     unsafe { std::mem::transmute((&92u8, &[0usize, 1usize, 1000usize])) }; | |______________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^__- |                | |                invalid vtable: alignment `1000` is not a power of 2 | = note: `#[deny(const_err)]` on by default = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800> error: any use of this value will cause an error --> $DIR/ub-incorrect-vtable.rs:16:14 | LL | / const INVALID_VTABLE_SIZE: &dyn Trait = LL | |     unsafe { std::mem::transmute((&92u8, &[1usize, usize::MAX, 1usize])) }; | |______________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^__- |                | |                invalid vtable: size is bigger than largest supported object | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800> error: aborting due to 2 previous errors </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
must not be a power of two to work (e.g. 3, 5, 7, 9, 10, 11, ...). seems to be a lower bound, but I'm not entirely sure. Doesn't panic with anything below these values. Regression in cc
We need to report a proper ub error in for the unwrap on the alignment. Basically do the same thing as if the result of Align::from_bytes is Err. cc
agreed, that's the right fix.
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
Change:
// Check that AST json printing works. <ins> #![crate_type = "lib"] </ins> // check-pass <del> // compile-flags: -Zast-json-noexpand </del> <ins> // compile-flags: -Zast-json </ins> // normalize-stdout-test ":d+" -> ":0" // Only include a single item to reduce how often the test output needs

Discussion:
The JSON for is broken because the for attributes serializes to nothing. An empty library produces the following: The important bit which is clearly not valid JSON. It looks like the  serialization was removed in . I'm not sure what a solution is here. I'm guessing AST serialization is used elsewhere, where this field isn't needed. I'm not too familiar with , so I'm not sure if it has something equivalent to . cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like the encoding/decoding change from needs to be reverted. Reverting should be ok because and don't do anything anyway (at least when inlined) during metadata encoding and decoding. The change is trivial, so marking this as E-easy, but if it's not done until the weekend I'll submit the PR myself.
claim
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // ignore-msvc -- sprintf isn't a symbol in msvcrt? maybe a #define? #![feature(libc, std_misc)] extern crate libc; use std::ffi::{CStr, CString}; use libc::{c_char, c_int}; </del> <ins> #[link(name = "rust_test_helpers")] </ins> extern { <del> fn sprintf(s: *mut c_char, format: *const c_char, ...) -> c_int; } unsafe fn check<T, F>(expected: &str, f: F) where F: FnOnce(*mut c_char) -> T { let mut x = [0 as c_char; 50]; f(&mut x[0] as *mut c_char); assert_eq!(expected.as_bytes(), CStr::from_ptr(x.as_ptr()).to_bytes()); </del> <ins> fn rust_interesting_average(_: u64, ...) -> f64; </ins> } pub fn main() { <ins> // Call without variadic arguments </ins> unsafe { <del> // Call with just the named parameter let c = CString::new(&b"Hello Worldn"[..]).unwrap(); check("Hello Worldn", |s| sprintf(s, c.as_ptr())); // Call with variable number of arguments let c = CString::new(&b"%d %f %c %sn"[..]).unwrap(); check("42 42.500000 a %d %f %c %snn", |s| { sprintf(s, c.as_ptr(), 42, 42.5f64, 'a' as c_int, c.as_ptr()); }); </del> <ins> assert!(rust_interesting_average(0).is_nan()); } </ins> <del> // Make a function pointer let x: unsafe extern fn(*mut c_char, *const c_char, ...) -> c_int = sprintf; </del> <ins> // Call with direct arguments unsafe { assert_eq!(rust_interesting_average(1, 10i64, 10.0f64) as i64, 20); } </ins> <del> // A function that takes a function pointer unsafe fn call(fp: unsafe extern fn(*mut c_char, *const c_char, ...) -> c_int) { // Call with just the named parameter let c = CString::new(&b"Hello Worldn"[..]).unwrap(); check("Hello Worldn", |s| fp(s, c.as_ptr())); </del> <ins> // Call with named arguments, variable number of them let (x1, x2, x3, x4) = (10i64, 10.0f64, 20i64, 20.0f64); unsafe { assert_eq!(rust_interesting_average(2, x1, x2, x3, x4) as i64, 30); } </ins> <del> // Call with variable number of arguments let c = CString::new(&b"%d %f %c %sn"[..]).unwrap(); check("42 42.500000 a %d %f %c %snn", |s| { fp(s, c.as_ptr(), 42, 42.5f64, 'a' as c_int, c.as_ptr()); }); } </del> <ins> // A function that takes a function pointer unsafe fn call(fp: unsafe extern fn(u64, ...) -> f64) { let (x1, x2, x3, x4) = (10i64, 10.0f64, 20i64, 20.0f64); assert_eq!(fp(2, x1, x2, x3, x4) as i64, 30); } </ins> <del> // Pass sprintf directly call(sprintf); </del> <ins> unsafe { call(rust_interesting_average); </ins> <del> // Pass sprintf indirectly </del> <ins> // Make a function pointer, pass indirectly let x: unsafe extern fn(u64, ...) -> f64 = rust_interesting_average; </ins> call(x); } }

Discussion:
This test is ignored on MSVC because MSVC does not have a sprintf function. We have a variadic function defined in test helpers, which should be used in this test as well. See for an example.
The ? What to do with it?
It should be copied over along with the block.
Change:
use rustc_hir::def_id::{DefId, DefIdMap, LocalDefId}; use rustc_hir::intravisit::{self, Visitor}; use rustc_middle::query::Providers; <del> use rustc_middle::ty::{self, GenericArgs, ImplTraitInTraitData, Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, ImplTraitInTraitData, TyCtxt}; </ins> use rustc_span::symbol::kw; pub(crate) fn provide(providers: &mut Providers) {

Discussion:
Minimal example (): outputs In the example, the implementation is irrelevant. The definition itself is the cause for error. Removing either the lifetime or the results in successful compilation as expected. I don't understand why it's causing a cycle error, but intuitively I don't see why it should be. Introducing an trait with a blanket implementation is a possible workaround and what I'll be doing while the issue exists.
Change:
<ins> #![crate_type = "rlib"] #![feature(lang_items)] #![feature(panic_unwind)] #![no_std] extern crate panic_unwind; #[panic_handler] pub fn panic_handler(_: &core::panic::PanicInfo) -> ! { loop {} } #[no_mangle] extern "C" fn __rust_drop_panic() -> ! { loop {} } </ins>

Discussion:
Compiling following under some circumstances result in undefined references to : This linking issue occurs only under for some codegen partitioning but not the others. Reproducing it requires controlling the options that influence the number of codegen units. I can reproduce it with either , or combined with . The weak lang items introduce cyclic dependencies between crates. For example, the alloc crate depends on oom lang item which is defined in std. When linking the std comes first, and it may so happen that object file that contains definition is not used and omitted (this suggest why large number of codegen units is necessary to reproduce the issue), and subsequently alloc crate will fail to link. The [linking code][0] tries to account for cyclic dependencies using start-group and end-group, but as far as I can see it based on assumption that weak lang items dependencies are always reversed, which no longer holds true. [0]:
Change:
<del> Subproject commit 8ca261268068d80c0969260fff15199bad87b587 </del> <ins> Subproject commit 960d610e7f33889a2577f5f17c26f0d5c82b30df </ins>

Discussion:
Compile the above (faulty) code with gives me this:
Probably related to .
Thanks for the information! Close this one.
Change:
pub struct AnonPipe(FileDesc); pub fn anon_pipe() -> io::Result<(AnonPipe, AnonPipe)> { <del> weak! { fn pipe2(*mut c_int, c_int) -> c_int } </del> <ins> syscall! { fn pipe2(fds: *mut c_int, flags: c_int) -> c_int } </ins> static INVALID: AtomicBool = ATOMIC_BOOL_INIT; let mut fds = [0; 2];

Discussion:
Sorry for the cryptic title, didn't knew exactly what to put there. On musl targets (well and (hf)) for some reason pipe2 is not used (even on kernels that support it). Pipe2 is important to protect against race condition when multiple threads run external commands. The following is an example that due to this bug will deadlock on the musl targets listed above (and probably all linux musl ones). Running with strace proves that pipe2 is not used, and that instead the fallback is: vs the target: Versions affected: 1.30.1 1.31.0 - Current stable rustc 1.32.0-nightly ( 2018-12-07) Later Edit: Just to be clear, if I compile a C file with the same musl toolchain that rust uses pipe2 works, so it's not a bug in Musl (or doesn't look like one to me).
cc
Did some investigation regarding this bug: The culprit seems to be: More specifically the following comment: “It assumes that //! we've been dynamically linked to the library the symbol comes from, but that //! is currently always the case for things like libpthread/libc.” Well this is not the case for musl target binaries. pipe2 is one of the symbols rust uses this mechanism to check for existence.(for fair reasons, the symbol is not there on old kernels). But on any musl target this symbol does exist because musl is emulating it in it’s standard library in case the systemcall is missing. A solution would thus be to assume this symbol always exists on musl targets (and it’s probably the same for the other ones) and make the weak! macro return the symbol directly for such targets. I could do it myself if this sounds resonable.
Thanks for the report Your investigation sounds right to me and I agree that we can probably just assume these symbols always exist on the musl target (as we're mostly pulling in the libc anyway). Should be fine to update the standard library to assume so!
Is this kind of what you had in mind? I wanna know if I should go like this, or I understood you wrong.