jiebi/CodeConvo huggingface dataset:
Change:
When debugging a large Miri trace, I like to put the trace into a file that I can analyze and search through in an editor. Unfortunately, since the recent logging changes, that leads to a lot of garbage in the file: Looks like the color escape sequences are printed even when redirecting to a file. This makes working with the logfile much harder than it was before. Is there a way to fix that? Cc
This is the fault of I should be checking for whether the terminal supports colors before activating colors
A workaround until then is to use
How can I run miri from the rust repo? (i.e. built using )
You can run the test suite with , but that's not what you were asking... that's not supported yet unfortunately:
Until then, . Some of the commands might need adjusting though as changed.
Ah, thanks! I forgot about that part of the docs :)
Hmm, I'm getting this error: I'm using the latest master rustc and the latest miri. Is miri broken right now? EDIT: Oh, I think I need .
Yeah looks like you are using the wrong stage or so. The docs are from back when stage 2 was the default...
I'm afraid the problem was not solved by that PR. When I run Miri like this locally I still get all the ANSI codes in that logfile, which makes the file very hard to work with.
Looks like the code tests , but logging goes to stderr so this is the wrong test.
Hmm, I guess I didn't notice any issues because I always redirect stderr to stdout and then view that.
Working on a fix.
Yeah, for now using to redirect both to the logfile is an okay work-around.
FYI you can view the original color with , which prints them directly to the terminal. That doesn't work in an editor, though.

Discussion:
} } <ins> // FIXME remove these and use winapi 0.3 instead #[cfg(unix)] fn stderr_isatty() -> bool { unsafe { libc::isatty(libc::STDERR_FILENO) != 0 } } #[cfg(windows)] fn stderr_isatty() -> bool { use winapi::um::consoleapi::GetConsoleMode; use winapi::um::processenv::GetStdHandle; use winapi::um::winbase::STD_ERROR_HANDLE; unsafe { let handle = GetStdHandle(STD_ERROR_HANDLE); let mut out = 0; GetConsoleMode(handle, &mut out) != 0 } } </ins> fn handle_explain(registry: Registry, code: &str, output: ErrorOutputType) { let normalised = if code.starts_with('E') { code.to_string() } else { format!("E{0:0>4}", code) };

Ok(value) => match value.as_ref() { "always" => true, "never" => false, <del> "auto" => stdout_isatty(), </del> <ins> "auto" => stderr_isatty(), </ins> _ => early_error( ErrorOutputType::default(), &format!(

), ), }, <del> Err(std::env::VarError::NotPresent) => stdout_isatty(), </del> <ins> Err(std::env::VarError::NotPresent) => stderr_isatty(), </ins> Err(std::env::VarError::NotUnicode(_value)) => early_error( ErrorOutputType::default(), "non-Unicode log color value: expected one of always, never, or auto",
Change:
Previously: Now: <!-- 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
Inlining exposes a use of unnormalized local in a call terminator (not sure if this is more of an issue with inlining or a validator): Note: revision annotation doesn't work in an auxiliary file (so it isn't tested on CI with mir-opt-level=2). modify labels: +A-mir-opt-inlining
This ICEs again because the fix was reverted Can someone reopen please?
Due to this new requires to trigger. <details<summaryICE:</summary</details
(FWIW can also trigger this: )
fixes this for and , but it still ICEs with on its own or with mir-opt-level 1/2 cc

Discussion:
fn run_pass(&self, tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) { // This pass must run before inlining, since we insert callee bodies in RevealAll mode. // Do not apply this transformation to generators. <del> if (tcx.sess.mir_opt_level() >= 3 || !super::inline::is_enabled(tcx)) </del> <ins> if (tcx.sess.mir_opt_level() >= 3 || super::inline::is_enabled(tcx)) </ins> && body.generator.is_none() { let param_env = tcx.param_env_reveal_all_normalized(body.source.def_id());

<del> // EMIT_MIR issue_78192.f.InstCombine.diff </del> <ins> // compile-flags: -Zmir-opt-level=1 -Zinline-mir </ins> pub fn f<T>(a: &T) -> *const T { let b: &*const T = &(a as *const T); *b

fn main() { f(&2); } <ins> // EMIT_MIR issue_78192.f.InstCombine.diff </ins>
Change:
While working on , I've run into the following ICE. On further consideration, the issue also appears with as long as is non zero sized. This ICE was likely not encountered during testing of because in the case of , is zero sized. In the example below, removing the borrow of will cause the compilation to succeed. could you take a look at this? :) cc you may run into this as well on <!-- 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<pFrom playground </p</details
This ice is still showing up in . We are using it over in in embedded programming to allocate from heaps located on externally mounted sdram.
Vec is not affected by this, and can even be used to get a Box. This code did not ICE on playground.
Interestingly, trying to print the Box created in that way gives the same ICE as
Hello, I get this error in two flavor: By ref: Produce the following: Without ref: Cause: Where does implement both and traits.
I'm hitting this issue too, on code that basically equates to this: Seems like there are plenty of ways to reproduce this in here, but if a minimal test case is needed, I would be happy to try to provide one. I just made a repro, wasn't really that tricky.
As far as I understand it, the issue is as follows: std is special cased, it has the attribute This corresponds to , which returns true if the type as been annotated to be a Somewhere, some code which uses makes an assumption that such a box data type only contains one field, the inner pointer itself. This causes the allocator struct field to be removed. This breaks when there is a non ZST allocator field that needs to be accessed in generated code. I'm guessing this might be related to the special deref move semantics for boxes? Is the case where the compiler should call for the for the box in the case where a deref move is performed even handled correctly as is today?
It seems that is the one that developed the feature, in He had been warned of the incomming issue, , and opt for a "workaround", can you give us more information about the problem you , the workaround you choose, any hint for why it isn't working, and maybe give us possible path to explore ?

Discussion:
ty::Ref(..) | ty::RawPtr(_) => { return self.field(cx, index).llvm_type(cx); } <del> ty::Adt(def, _) if def.is_box() => { </del> <ins> // only wide pointer boxes are handled as pointers // thin pointer boxes with scalar allocators are handled by the general logic below ty::Adt(def, substs) if def.is_box() && cx.layout_of(substs.type_at(1)).is_zst() => { </ins> let ptr_ty = cx.tcx.mk_mut_ptr(self.ty.boxed_ty()); return cx.layout_of(ptr_ty).scalar_pair_element_llvm_type(cx, index, immediate); }

<ins> // check-pass #![feature(allocator_api)] fn main() { Box::new_in((), &std::alloc::Global); } </ins>
Change:
The change in made non-PGO builds of Firefox's 's .text section grow by close to 1MB. has a ~89MB section, which makes it a 1% size increase in a library where about only 16% of the code is rust, which makes it a 7% (!) increase in size. This comes from the fact that essentially all uses of Vec::push inline this all for some reason, and it's used all across the place.
modify labels: I-heavy T-libs
Error: Label libs-impl can only be set by Rust team members Please let know if you're having trouble with this bot.
inling seems to have a noticable performance benefit, so not doing so is probably not desirable, see Not sure how else we would be able to directly remedy this issue.
Assigning as and removing .

Discussion:
// above `RawVec::grow_amortized` for details. (The `A` parameter isn't // significant, because the number of different `A` types seen in practice is // much smaller than the number of `T` types.) <ins> #[inline(never)] </ins> fn finish_grow<A>( new_layout: Result<Layout, LayoutError>, current_memory: Option<(NonNull<u8>, Layout)>,

I: TrustedLen<Item = T>, { fn from_iter(iterator: I) -> Self { <del> let mut vector = Vec::new(); </del> <ins> let mut vector = match iterator.size_hint() { (_, Some(upper)) => Vec::with_capacity(upper), _ => Vec::new(), }; </ins> // must delegate to spec_extend() since extend() itself delegates // to spec_from for empty Vecs vector.spec_extend(iterator);
Change:
Alternate title: "Rust is literally C++" As of nightly-2020-10-29, rustc fails to parse the following code. The previous nightly and all past stable releases since 1.0.0 are not affected. The relevant commit range is
Mentioning because "Tweak invalid  header and body parsing" sounds extremely relevant.
Assigning and removing as in the prioritization working group.
searched nightlies: from nightly-2020-10-27 to nightly-2020-10-29 regressed nightly: nightly-2020-10-29 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </detailsYeah, seems likely that is the culprit.
Yep, this was me :-/ I'll have a PR up in the next hour.

Discussion:
req_name: ReqName, ret_allow_plus: AllowPlus, ) -> PResult<'a, P<FnDecl>> { <del> let inputs = self.parse_fn_params(req_name)?; let output = self.parse_ret_ty(ret_allow_plus, RecoverQPath::Yes)?; if let ast::FnRetTy::Ty(ty) = &output { if let TyKind::Path(_, Path { segments, .. }) = &ty.kind { if let [.., last] = &segments[..] { // Detect and recover `fn foo() -> Vec<i32>> {}` self.check_trailing_angle_brackets(last, &[&token::OpenDelim(token::Brace)]); } } } Ok(P(FnDecl { inputs, output })) </del> <ins> Ok(P(FnDecl { inputs: self.parse_fn_params(req_name)?, output: self.parse_ret_ty(ret_allow_plus, RecoverQPath::Yes)?, })) </ins> } /// Parses the parameter list of a function, including the `(` and `)` delimiters.

<ins> // check-pass // Regression test for #78507. fn foo() -> Option<fn() -> Option<bool>> { Some(|| Some(true)) } fn main() {} </ins>

// Verify that '>' is not both expected and found at the same time, as it used // to happen in #24780. For example, following should be an error: <del> // expected one of ..., `>`, ... found `>`. No longer exactly this, but keeping for posterity. </del> <ins> // expected one of ..., `>`, ... found `>`. </ins> <del> fn foo() -> Vec<usize>> { //~ ERROR unmatched angle bracket </del> <ins> fn foo() -> Vec<usize>> { //~ ERROR expected one of `!`, `+`, `::`, `;`, `where`, or `{`, found `>` </ins> Vec::new() }

<del> error: unmatched angle bracket </del> <ins> error: expected one of `!`, `+`, `::`, `;`, `where`, or `{`, found `>` </ins> --> $DIR/issue-24780.rs:5:23 | LL | fn foo() -> Vec<usize>> { <del> |                       ^^ help: remove extra angle bracket </del> <ins> |                       ^ expected one of `!`, `+`, `::`, `;`, `where`, or `{` </ins> error: aborting due to previous error
Change:
This code panics under Miri, and also when I compile to WASM, though not when running normally. The overflow is here:
I can reproduce when using Miri, but it works fine for me with WASM: (Same with nightly toolchain.)
panics with it always fails here because is greater than so underflows.
Why is this specific to ZSTs?
does not allocate for and starts out with capacity which overflows when converting to a deque which does not expect this
Assigning and removing as in the prioritization working group.
Currently on playground it seems to work fine both under Miri and regular rustc? Indeed something would be very wrong if it only panicked on Miri... version panics both with rustc and Miri. Maybe the example in the OP should be updated.
Yes, though at time of posting it did fail under miri (and only under miri) on the playground. Sorry if I was unclear; I meant that I got the same panic when running the built WASM.
My guess is that something in libstd changed to fix the panic for your case (but not for and when you tested this, Miri was broken in the latest toolchain so playground had an older version of Miri. When this happens again, please note down the exact versions of every component involved, so we can make sure this is comparing Miri and rustc for the same toolchain, not two different versions of Rust.
The originally reported panic is an overflow check and one of those that is not inherited cross-crate. To observe it the standard library must be built with overflow checks. It's still an issue right now.
Ah, so this stopped to fail in Miri when we recently stopped building libstd with debug assertions.

Discussion:
let len = other.len(); // We need to extend the buf if it's not a power of two, too small <del> // or doesn't have at least one free space if !buf.capacity().is_power_of_two() </del> <ins> // or doesn't have at least one free space. // We check if `T` is a ZST in the first condition, // because `usize::MAX` (the capacity returned by `capacity()` for ZST) // is not a power of two and thus it'll always try // to reserve more memory which will panic for ZST (rust-lang/rust#78532) if (!buf.capacity().is_power_of_two() && mem::size_of::<T>() != 0) </ins> || (buf.capacity() < (MINIMUM_CAPACITY + 1)) || (buf.capacity() == len) {

} } } <ins> #[test] fn test_from_zero_sized_vec() { let v = vec![(); 100]; let queue = VecDeque::from(v); assert_eq!(queue.len(), 100); } </ins>
Change:
Spot the bug: Unfortunately, instead of pointing to the missing iterator, rust points to the 1: I'd love it to instead say 'missing iterator for loop': Other variants of this with less than ideal errors: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Well, it thinks the block is the iterator.
Yes, I understand, but a) is not an iterator, and b) since there's no body of the loop I was hoping the parser could recover somehow and understand that the block expression was intended to be the body.
Yes, I just wanted to make sure we were on the same page :)
I could have sworn there was an old ticket for this already but I can't find it
claim

Discussion:
.use_in_not_of = try using `in` here instead .add_in = try adding `in` here <ins> parse_missing_expression_in_for_loop = missing expression to iterate on in `for` loop .suggestion = try adding an expression to the `for` loop </ins> parse_missing_comma_after_match_arm = expected `,` following `match` arm .suggestion = missing a comma here to end this `match` arm

} #[derive(Diagnostic)] <ins> #[diag(parse_missing_expression_in_for_loop)] pub(crate) struct MissingExpressionInForLoop { #[primary_span] #[suggestion( code = "/* expression */ ", applicability = "has-placeholders", style = "verbose" )] pub span: Span, } #[derive(Diagnostic)] </ins> #[diag(parse_missing_comma_after_match_arm)] pub(crate) struct MissingCommaAfterMatchArm { #[primary_span]

let pat = self.recover_parens_around_for_head(pat, begin_paren); <ins> // Recover from missing expression in `for` loop if matches!(expr.kind, ExprKind::Block(..)) && !matches!(self.token.kind, token::OpenDelim(token::Delimiter::Brace)) && self.may_recover() { self.sess .emit_err(errors::MissingExpressionInForLoop { span: expr.span.shrink_to_lo() }); let err_expr = self.mk_expr(expr.span, ExprKind::Err); let block = self.mk_block(vec![], BlockCheckMode::Default, self.prev_token.span); return Ok(self.mk_expr( lo.to(self.prev_token.span), ExprKind::ForLoop(pat, err_expr, block, opt_label), )); } </ins> let (attrs, loop_block) = self.parse_inner_attrs_and_block()?; let kind = ExprKind::ForLoop(pat, expr, loop_block, opt_label);

<ins> fn main() { for i in { //~^ ERROR missing expression to iterate on in `for` loop } } </ins>

<ins> error: missing expression to iterate on in `for` loop --> $DIR/missing-expression-in-for-loop.rs:2:14 | LL |     for i in { |              ^ | help: try adding an expression to the `for` loop | LL |     for i in /* expression */ { |              ++++++++++++++++ error: aborting due to previous error </ins>
Change:
: : I expected to see this happen: completes successfully with a "unresolved link to " warning Instead, this happened: <!-- 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<summaryBacktrace</summary<p</p</details
I bet the source span is wrong somehow.
The issue is that the documentation on the re-export is being combined with the original documentation. splits it up by the module it's scoped to, which is different for the two doc-comments; if you remove it works fine. needs to only pass the documentation for the current scope to , not the combined docs. Not sure why it needs a separate file.
The markdown range it comes up with is 3..13. Hmm, this is weird - I think this is actually the correct span because they both come from , which doesn't care about scoping and just works on strings. Maybe it is a bug in after all?
Aha, here we go: is trying to look at the rustc snippet instead of the text it was provided. Maybe it could just work with instead?
Hmm, there are some other bugs here too: normally rustdoc will resolve docs in the scope inside the module and to the scope of the parent. But since there are inner docs, it will resolve all of the links inside the module. I think the fix for both the issues is to separate outer docs from inner ones; not yet sure how to do that.
To add another test-case for what I believe is another instance of the same problem: This doesn't panic, but produces: For an even more confused case, split the module into its own file: Which yields this nonsensical warning: Essentially, the span of the unresolved link is misattributed to the wrong file. The line and column values are correct, it's just the wrong file that's used.
That's is assuming there is only inner or outer docs, not both.

Discussion:
'outer: for (line_no, md_line) in md_lines.enumerate() { loop { <del> let source_line = src_lines.next().expect("could not find markdown in source"); </del> <ins> let source_line = src_lines.next()?; </ins> match source_line.find(md_line) { Some(offset) => { if line_no == starting_line {

<ins> //! [`long_cat`] is really long </ins>

<ins> // check-pass macro_rules! m { () => { /// A //~^ WARNING #[path = "auxiliary/module_macro_doc.rs"] pub mod mymodule; } } m!(); </ins>

<ins> warning: unresolved link to `long_cat` --> $DIR/macro-docs.rs:5:9 | LL |         /// A |         ^^^^^ ... LL | m!(); | ---- in this macro invocation | = note: `#[warn(rustdoc::broken_intra_doc_links)]` on by default = note: the link appears in this line: [`long_cat`] is really long ^^^^^^^^^^ = note: no item named `long_cat` in scope = help: to escape `[` and `]` characters, add '' before them like `[` or `]` = note: this warning originates in the macro `m` (in Nightly builds, run with -Z macro-backtrace for more info) warning: 1 warning emitted </ins>
Change:
This was triggered by overloading a crate in 's : Causing the following panic:
This happens in . It thinks that the crate is a local crate part of the source tree and then panics when it isn't part of the workspace while trying to get the the path to it.
I'm unable to reproduce this, can you provide more details on exactly what changes were made? Which version of were you pointing to? Which commit of the rust repo are you on? FWIW, modifying a single to point to a local dependency can cause problems and is not the best way to go about using a local copy. Usually you want to specify a in the root .
The same happens for ykrustc when using : It is worked around by having skip that specific crate:
I can't see those links for some reason. GitHub is saying "There isn’t anything to compare. We couldn’t figure out how to compare these references, do they point to valid commits?" For example, the following works for me on latest master ():
Github somehow removed the from the urls. The correct urls are: Try moving to the parent dir. Otherwise it is part of the rust workspace.
I see, I forgot that "path deps are workspace members" does not work if it is outside of the workspace root. Regardless, it is still probably best in this particular case of to use a . BTW, those links still don't seem to work. I just see " This comparison is big! We’re only showing the most recent 250 commits", and a long list of commits. I posted with a fix at .
Seems like github doesn't switch to the "files changed" tab automatically. Anyway here is a copy:
Thanks and for tracking this down. This was just with the latest s of both repos at the time, specifically rust and libc . Maybe I didn't match the versions carefully enough or something, but building the patched out-of-tree with does work correctly. FWIW, I also tried with a , which gave the same error. I can give more details if this changes things.

Discussion:
let krate = &self.crates[&krate]; ret.push(krate); for dep in &krate.deps { <ins> if !self.crates.contains_key(dep) { // Ignore non-workspace members. continue; } </ins> // Don't include optional deps if their features are not // enabled. Ideally this would be computed from `cargo // metadata --features …`, but that is somewhat slow. Just
Change:
<!-- 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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Output on 1.46: modify labels: +regression-from-stable-to-stable
Assigning and removing as in the prioritization working group.

Discussion:
let _tables = tcx.typeck(body_owner); &*path } <del> _ => span_bug!(DUMMY_SP, "unexpected const parent path {:?}", parent_node), </del> <ins> _ => { tcx.sess.delay_span_bug( tcx.def_span(def_id), &format!("unexpected const parent path {:?}", parent_node), ); return None; } </ins> }; // We've encountered an `AnonConst` in some path, so we need to

<ins> #![crate_type = "lib"] struct S; fn f() { S::A::<f> {} //~^ ERROR ambiguous associated type } </ins>

<ins> error[E0223]: ambiguous associated type --> $DIR/issue-78622.rs:5:5 | LL |     S::A::<f> {} |     ^^^^^^^^^ help: use fully-qualified syntax: `<S as Trait>::A` error: aborting due to previous error For more information about this error, try `rustc --explain E0223`. </ins>