jiebi/CodeConvo huggingface dataset:
Change:
/// Returns a `BitSet` containing all basic blocks reachable from the `START_BLOCK`. pub fn reachable_as_bitset(body: &Body<'_>) -> BitSet<BasicBlock> { let mut iter = preorder(body); <del> iter.by_ref().for_each(drop); </del> <ins> while let Some(_) = iter.next() {} </ins> iter.visited }

Discussion:
tracking issue: Inspired by comment in For things like it'd be nice to not have to even give LLVM the code for the else branch to have to emit. Ought to save time and binary size. Tentatively marked mir-opt, since we presumably still need to make the MIR for it, in order to borrow-check and such the unreachable code. But might need to be codegen-time instead to pick up on monomorphized inline constants. Hopefully should be doable relatively easily when the const is an inline const, since that forces const folding already, and thus there should just be a in the MIR.
Well, turns out this already works for simple constants in MIR! However, the place I actually needed it was more like , which doesn't work with today. So maybe come back to this once that's fixed.
This should be done by which AFAIK is run unconditionally. I wonder if its match needs to be expanded? Is there mcve?
The problem is that this can't be done on generic constants, as we don't mir-optimize post-monomorphization. We could start doing some benchmarks to see how bad running all mir opts (or at least a select few) would be if we duplicated, substituted and optimized MIR bodies for concrete generic parameters.
I would say qualifies as an MCVE as the monomorphized gives the following llvm ir
Maybe it should also be evaluated together with polymorphization or constevaluatablechecked since those can cut down on the duplication before applying further optimizations.
Bonus points if this can avoid monomorphizing functions called in the dead code too. Demo extracted from : (cc ) Would be great to not codegen all the downstream stuff that's only called in the else block of a .
FYI this should work with
Totally wild (and probably bad) idea: could we avoid borrow-checking unreachable code? After all, the purpose of borrow-checking is to prevent memory unsafety at runtime, but unreachable code cannot be memory unsafe, because it never executes!
We already do! As a , (But this isn't really the right issue to discuss possible extensions to that.)
This seems closely related to and
recent PR seems related here? If the condition becomes a constant during codegen, we should be entirely skipping it now and not even generate LLVM IR.

However, if that dead code calls functions, those still get codegen'd as usual -- the collector that determines which function to codegen doesn't know about dead branches. We'd have to embed a (simple) monomorphization-time reachability analysis in the collector to fix that.
Change:
#[macro_export] #[cfg(dox)] macro_rules! concat_idents { <del> ($($e:ident),*) => ({ /* compiler built-in */ }) </del> <ins> ($($e:ident),*) => ({ /* compiler built-in */ }); ($($e:ident,)*) => ({ /* compiler built-in */ }); </ins> } /// Concatenates literals into a static string slice.

Discussion:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged
Change:
tts.into() ).into()) }, <del> token::CloseDelim(_) => { </del> <ins> token::CloseDelim(delim) => { </ins> // An unexpected closing delimiter (i.e., there is no // matching opening delimiter). let token_str = token_to_string(&self.token); let msg = format!("unexpected close delimiter: `{}`", token_str); let mut err = self.string_reader.sess.span_diagnostic .struct_span_err(self.token.span, &msg); <ins> if let Some(span) = self.last_delim_empty_block_spans.remove(&delim) { err.span_label( span, "this block is empty, you might have not meant to close it" ); } </ins> err.span_label(self.token.span, "unexpected close delimiter"); Err(err) },

Discussion:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.
Change:
<ins> // edition:2018 // aux-build:extern_macros.rs </ins> // compile-flags:--test --test-args=--test-threads=1 // normalize-stdout-test: "src/test/rustdoc-ui" -> "$$DIR" // check-pass

Discussion:
Doctest test names have changed due to . Doc comments that pass through a macro defined in another crate now seem to report a different span. /// assert!(true); /// running with previously looked like this: Now the test names look like this: Frankly, neither are particularly great. It would be nice if the test name used the span from where the macro was invoked, not where it was defined.
I think this also affects normal backtraces :( Just got this rather unuseful backtrace while bootstrapping: full:
cc
What you're describing is entirely in the opposite direction, is the old (and arguably bad) kind of that's impossible to get anymore. I've hidden your comment to focus on the reported issue.
That makes sense, we have a way to get the outermost invocation, that is used by / and : We'd just need to use this in .
cc
cc
Removed label, left nomination for to decide about this issue.
Well, using what suggested seems like the best thing to do.
Change:
name.as_ptr() as *mut libc::c_void); } } <ins> #[cfg(target_os = "solaris")] pub fn set_name(name: &CStr) { weak! { fn pthread_setname_np( libc::pthread_t, *const libc::c_char ) -> libc::c_int } if let Some(f) = pthread_setname_np.get() { unsafe { f(libc::pthread_self(), name.as_ptr()); } } } </ins> #[cfg(any(target_env = "newlib", <del> target_os = "solaris", </del> target_os = "haiku", target_os = "l4re", target_os = "emscripten",

Discussion:
Both Solaris 11 and recentish Illumos provide the same API. While libstd can't presume the existence of the symbol, it seems like using works sufficiently to set the thread name when necessary. While the implementation is different, the API is basically the same for the purposes of . The Linux implementation of will silently truncate the thread name, while the NetBSD (and I think, FreeBSD) will return an error. Since the implementation has no way to return an error right now, we need to choose between silent truncation or silent failure. Given the risk of mis-identification in truncation (it's likely that the unique part of the name is the end), it seems best to fail silently instead. On the plus side, this API has significantly more space than Linux's.
Change:
<del> Subproject commit 974c8be95ec17cd986251d7700cd432a39576939 </del> <ins> Subproject commit a7891c05f7fdb329f68c991abbb39dafc1f6b4a5 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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! And nominating for compiler team prioritization.
Already fixed in Miri, but I have some PRs open that will break Miri again so I am waiting a bit before updating the submodule.
Tagging as check
Blocked on
Change:
fn _var_os(key: &OsStr) -> Option<OsString> { os_imp::getenv(key) <del> .unwrap_or_else(|e| panic!("failed to get environment variable `{:?}`: {}", key, e)) </del> } /// The error type for operations interacting with environment variables.

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 --
Simplified. The other malformed-looking bytes don't matter, do they?
You are right, they don't. I should have simplified it before submit.
Going to have a go at this. If I can't figure it out, I'll either ask for help or unassign myself. claim
Still working on this, but I figured an update may be helpful. My research indicates that the two characters that are potentially problematic are and . The work that needs to be done consists of 1) updating the macro expansion functions in to error in these cases; and 2) updating the macro documentation in to mention the new errors. Edit: It just occurred to me that I also need to add UI tests. Haven't figured out where to do that yet, but I will.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I don't think just adding a check to raise error in these cases would be enough. The function shouldn't really panic (from the internals discussion). Another problem is when the OS supports this kind of environment variable. e.g. as key. would deny it while it can be valid i.e. a false positive. You should still keep your work though (and eventually open a PR) as this must be changes to which would take a while.
If this is going to be fixed upstream in in even the mid-term future, I'm not sure fixing it here makes sense. Sure, it generates an ICE, but the ICE has an unusually helpful error message.
Actually, simple solution: I'll do the fix.

Working on that now.
Was this fuzzer output? If so, which fuzzer were you using
Yes, I am using kira, a work-in-progress fuzzing tool
Have you considered sorry using structure-aware fuzzing? That could help find bugs not just in the lexer and parser, but also in the middle and back ends.
Yes, actually kira is structure-aware.
Change:
use syntax::codemap::Span; use rustc_target::spec::abi::Abi; <del> use rustc::mir::interpret::{EvalResult, Scalar, Value}; </del> <ins> use rustc::mir::interpret::EvalResult; </ins> use super::{EvalContext, Place, Machine, ValTy}; use rustc_data_structures::indexed_vec::Idx;

Discussion:
I saw that was closed when was merged so I thought it would fix the same error on my own code as well however as of nightly: it still happens. Code: Playground: From what I can tell its an alignment issue because changing id from a to a fixes the issue.
Change:
generate_link_to_definition, call_locations, no_emit_shared, <ins> html_no_source, </ins> .. } = options;

Discussion:
Kind of related to and the  attribute. The behaviour would be the same as the latter but wouldn't require any source code changes. My use-case here is to generate docs on the CI and reduce the size (400MB just for docs for each version is a bit much), but if people want to generate docs locally they should still be able to get the source code pages if they want. suggested to create an issue for this.
To reduce the global documentation size, I suggested in to group items that don't have impls by kinds. Would require an RFC though. In any case, I think it's a good idea to add an option to have this done in the command line.
Change:
<ins> // Using labeled break in a while loop has caused an illegal instruction being // generated, and an ICE later. // // See https://github.com/rust-lang/rust/issues/51350 for more information. const CRASH: () = 'a: while break 'a {}; fn main() { println!("{:?}", CRASH); } </ins>

Discussion:
A while ago, this would cause an illigal instruction, but has been fixed, see , and no longer is an issue in the current nightly. Except, using such code while creating a constant, results in an ICE: This is rustc 1.28.0-nightly ( 2018-05-30). Backtrace:
I can look into this. I should be able to reference the previous PR to help resolve the issue.
the problem here is quite different. The issue is that the gets turned into a , which then causes to be called (which causes the ICE): and hence the error to never be reached here: Really, it feels like this error is happening at too low a level, and it'd be better to match on the expressions at a higher level to report a similar error, rather than doing the analysis on the MIR.
Still ICE's in both 2015 and 2018 editions.
As of now, this no longer ICE's. Looking on godbolt, since stable 1.33 this code just compiles.
Added a test case:
Change:
} } <del> pub const DEFAULT_MIN_STACK_SIZE: usize = 4096; </del> <ins> pub const DEFAULT_MIN_STACK_SIZE: usize = 64 * 1024; </ins> impl Thread { // unsafe: see thread::Builder::spawn_unchecked for safety requirements

Discussion:
The DEFAULTMINSTACK_SIZE is the default stack size assigned when creating a thread. This value varies across different platforms. The issue is that there isn't enough explanation as to why these values are different, and users might not realize that the stack size can vary. Recently, I was running existing Windows code on a WASI target, and I kept encountering font decoding failures. Since it worked correctly on Windows, I suspected WASI's instability and spent considerable time debugging. After several days, I discovered that the root cause was the stack size: WASI has a very small stack size of 4KB, while Windows has a much larger stack size of 2MB. Once I forcibly increased the thread's stack size, all issues were resolved. I felt quite frustrated that such a simple reason caused the problem. Although this is my personal experience, I believe that rather than setting different default stack sizes for different platforms without a compelling reason, it would be better to have a consistent stack size across all platforms in Rust. However, I acknowledge that this suggestion might not be very effective because the required memory can vary depending on the instruction set or architecture. I would like to discuss this matter further.
Different platforms have different useful minimum stack sizes. I have no idea why only 4KiB is reserved on wasi.
In my opinion, this isn't an issue of "inconsistency" this is an issue of a target having an absurdly low value, period. Please open a PR to raise it.
What are the criteria for determining that? Since I don't know, I can't tell whether the 4KB for WASI is inappropriate or not, and I also can't open a PR because I don't know the appropriate value.
...a zillion insanely low-level minutiae like how big the registers are, mostly. an article that might help: as that article explains, the smallest thread stack size of all platforms that I'm aware of, aside from the ones in our repo that only ask for 4096 bytes, is 64KiB. the current 4096 bytes boundary has caused you significant pain so it seems sensible to raise it to at least that much, then fool around and see how it works.

having done some review of our platform code, I am pretty sure 4096 bytes was just picked as the "unsupported" value and platforms that initially lacked thread support, like wasm32-wasi, just inherited that value.
I understand. The differences between the platforms are indeed huge..! Before proceeding, I would like to hear the opinion or history from Alex Crichton, the main maintainer of the wasi target. , could you please share your thoughts on this issue?
I commented a bit on but I've no recollection for the current value for wasi. I suspect it was a number of historical accidents that led to this, and stack sizes should definitely be larger than 4k by default on wasi. Thanks for the issue
Change:
|                         -^ |                         || |                         |not allowed in type signatures <del> |                         help: replace with the correct return type: `&&usize` </del> <ins> |                         help: replace with the correct return type: `&'static &'static usize` </ins> error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> $DIR/typeck_type_placeholder_item.rs:52:52

Discussion:
Hello, While trying to figure out how to keep a JoinHandle in a thread-local variable, I tried compiling this incorrect code, and rust crashed. It will not panic if I use a regular static var instead of in a block. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The ICE happens since 1.44 label: +regression-from-stable-to-stable
ping icebreakers-cleanup-crew can we add a bit more detail and trace where this starts?
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
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Regression between ... If I had to guess, I would say
Reduced testcase:
Not sure if of any help, but the thread_local macro is not needed:
const : Option<= map(value); ;)
Change:
}); } <ins> fn has_own_existential_vtable_entries(tcx: TyCtxt<'_>, trait_def_id: DefId) -> bool { own_existential_vtable_entries_iter(tcx, trait_def_id).next().is_some() } </ins> fn own_existential_vtable_entries(tcx: TyCtxt<'_>, trait_def_id: DefId) -> &[DefId] { <ins> tcx.arena.alloc_from_iter(own_existential_vtable_entries_iter(tcx, trait_def_id)) } fn own_existential_vtable_entries_iter( tcx: TyCtxt<'_>, trait_def_id: DefId, ) -> impl Iterator<Item = DefId> + '_ { </ins> let trait_methods = tcx .associated_items(trait_def_id) .in_definition_order() .filter(|item| item.kind == ty::AssocKind::Fn); // Now list each method's DefId (for within its trait). let own_entries = trait_methods.filter_map(move |&trait_method| { debug!("own_existential_vtable_entry: trait_method={:?}", trait_method);

Discussion:
While working on I think I found a bug. Given this program: rustc outputs the following vtable layout: Which is surprising, because is unnecessary — does not have any methods, so vtable can be inlined... I think we should be smarter here: (for the record, I'm pretty sure this happens in practice, I've found this with ) Originally posted by in
cc
sorry been slow a little recently... This is a nice improvement.
Change:
let b: &Foo<Foo<[u8]>> = &foo; let c: &Foo<dyn std::fmt::Debug> = &Foo { value: 7i32 }; <ins> // Also check unsized tuples let tuple_slice: &(i32, i32, [i32]) = &(0, 1, [2, 3]); let tuple_dyn: &(i32, i32, dyn std::fmt::Debug) = &(0, 1, &3u64); </ins> zzz(); // #break }

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. --code from <!-- 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
cc It looks like this might be related to
reports that this is regression in (which is indeed in PR ).
reports in zulip that this test case fails at that same injection point when combined with (aka ): ./src/test/run-pass-valgrind/dst-dtor-4.rs : <details<summaryContent of above file</summary</details
Files that reproduce the ice one way or another with : `
Thanks for the bug report, I'll look into it.
Looks like this should be an easy fix. The code just doesn't expect tuples to be unsized (which of course it should).
Change:
} } } <ins> if let ty::Dynamic(traits, _) = self_ty.kind { for t in *traits.skip_binder() { match t { ty::ExistentialPredicate::Trait(trait_ref) => { flags.push((sym::_Self, Some(self.tcx.def_path_str(trait_ref.def_id)))) } _ => {} } } } </ins> if let Ok(Some(command)) = OnUnimplementedDirective::of_item(self.tcx, trait_ref.def_id, def_id)

Discussion:
gives The in particular is confusing. This can be a pretty intimidating error message for someone new to async/await, when all they forgot was . I'm not sure if we can fix this without stabilizing so we can sprinkle some magic compiler dust on its error messages. Maybe there's something we can do, though. Maybe some intelligent use of type aliases in our error messages? cc
This can be handled without needing to stabilize the struct. It should act the same way that the primitive type cast suggestions do.
Some observations: There is no struct, it's a type-alias We could suggest invoking but that is a method defined only in the futures crate, which feels a bit awkward to me; I'd rather it were part of libstd We can* suggest as well ()
marking as OnDeck, since BoxFuture gets used quite often
I have a PR that suggests the right code for this: <img width="1269" alt="Screen Shot 2020-02-11 at 5 09 37 PM" src="https://user-"But if first you try : <img width="1271" alt="Screen Shot 2020-02-11 at 5 10 12 PM" src="https://user-"or : <img width="1303" alt="Screen Shot 2020-02-11 at 5 11 11 PM" src="https://user-"we will send you in a wild goose chase: <img width="946" alt="Screen Shot 2020-02-11 at 5 10 53 PM" src="https://user-"
Filed for the uncovered cases.
Change:
crate fn print_arg(&mut self, input: &ast::Arg, is_closure: bool) { self.ibox(INDENT_UNIT); <ins> self.print_outer_attributes_inline(&input.attrs); </ins> match input.ty.node { ast::TyKind::Infer if is_closure => self.print_pat(&input.pat), _ => {

Discussion:
As this This is the example proc-macro: This is the test: Run both of result and result are: Formal parameter attributes disappear in proc-macro. Toolchain:
cc
I have a fix in
Change:
<ins> // Regression test for #60976: ICE (with <=1.36.0) when another file had `use <primitive_type>;`. // check-pass // aux-build:extern-use-primitive-type-lib.rs extern crate extern_use_primitive_type_lib; fn main() {} </ins>

Discussion:
Hello, I was working on my toy project here: The project was compiling and running fine at this commit: However, I decided I wanted to move functionality out of and into , so I moved all of it except the declarations, and then tried to compile. This led to the compiler panic. The repro commit for this: I am using CLion, and the command I run is simply . I am pretty new to Rust so it might just be me doing something really wrong, but it'd be great if someone could look into this and advise. Thank you! With : With : EDIT: Updated with last working commit. EDIT2: Posted crash message with --verbose flag and clarified IDE. EDIT3: Added MSVC toolchain error.
I have a PR that will fix the underlying problem, but we need to come up with a reproduction case to avoid regressions in the future.
Removing nomination since a fix is already approved
Thank you so much for the super-fast response! However, I am not at all familiar with rust's compiler code, so if you could tell which part of the code the compiler trips upon, I can try isolating that part of the code to make a smaller reproducible example.
Reduced it down to two files: (replace obvisouly ^^) can be any primtive type as , , , . Haven't managed to get it down to one file sadly :/
is there a problem of adding the test in two files (with )? if not, I could try to work on this as a first issue.
No, that's totally fine. Go for it!