jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: cannot find macro `something_later` in this scope --> $DIR/defined-later-issue-121061-2.rs:3:9 | LL |         something_later!(); |         ^^^^^^^^^^^^^^^ consider moving the definition of `something_later` before this call | note: a macro with the same name exists, but it appears later at here --> $DIR/defined-later-issue-121061-2.rs:6:18 | LL |     macro_rules! something_later { |                  ^^^^^^^^^^^^^^^ error: aborting due to 1 previous error </ins>

Discussion:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!
Change:
} } <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) };

Discussion:
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.
Change:
//! After a const evaluation has computed a value, before we destroy the const evaluator's session //! memory, we need to extract all memory allocations to the global memory pool so they stay around. <del> use rustc::ty::layout::LayoutOf; </del> use rustc::ty::{Ty, TyCtxt, ParamEnv, self}; use rustc::mir::interpret::{ InterpResult, ErrorHandled,

Discussion:
The build of smoltcp on nightly started failing recently with an ICE: https://travis- ~I suspect this might be caused by E0713, but it shouldn't be an ICE in any case.~
I believe the fundamental cause of the error is that the code looks like the following: That's pretty obviously unsound.
Correction for earlier comment: E0713 is completely unrelated. I've eliminated the problematic code that caused it in m-labs/smoltcp but the crash is still there.
cc (also, such an ICE should say "const checking" or similar - we should maybe even rename the pass itself in the compiler - the "qualify" part isn't as primary for MIR as it is for the AST side).
<details<summaryFull backtrace</summary</details<details<summaryfunction </summary</details
MCVE: : ok : ICE I'm bisecting it now.
Bisected to / .
Oh, I forgot about the ZST trickery, sorry, will have a fix tomorrow
What's the ZST here? in ?
Yes. That's a that gets unsized to .
Change:
all: off packed unpacked ifeq ($(UNAME),Darwin) <del> # If disabled, don't run dsymutil </del> <ins> # If disabled, don't run `dsymutil`. </ins> off: rm -rf $(TMPDIR)/*.dSYM $(RUSTC) foo.rs -g -C split-debuginfo=off

Discussion:
When I add to my in (on Linux), my build fails with: In debug I initially had the same problem but a fixed it without requiring me to turn off . However, release continues to be failing even after . rustc --version rustc 1.65.0 ( 2022-11-02) cargo --version cargo 1.65.0 ( 2022-10-20)
It's silent in my macOS in release profile, but no dSYM generated. It's OK in dev profile.
Oh not sure if it matters, but I also have debug = true set for my release build.
Thanks for your reminder. I forgot that is off by default in release profile.
Can confirm this happens for me as well but with .
Can you provide some more information, such as the target you are building for (?), the output of , and anything else that might help narrow down the issue? Is your profile exactly this?
I got this same error when I tried compiling with both split debug info and linker plugin LTO.
also need LTO enabled, works fine without here
Thanks for clarifying. Yeah, I do have LTO on as well.
cc or in case this didn't hit your radar. The reproduction is: with the error: From what I can tell, the archiver is expecting a file to exist ( around ). AFAIK, that doesn't make sense with a bitcode-only output. The decision of whether or not a dwo is expected I think is made around . I'm guessing that decision (or perhaps something at a higher level) needs to be aware that the split-dwarf won't happen with bitcode-only output? (IOW, that case should only be true if was called with a value with ?)
Should this issue be marked as a stable-to-stable regression?
Submitted to fix this.
Thanks for the ping and the great pre-investigation,
I am encountering this on without LTO. (Or at least I'm not explicitly enabling LTO, and I don't have LTO enabled in ). Builds in local projects work fine, only is affected. Adding the following to triggers it: Should I open a new issue, or do you want to track this together with the LTO case?
Can you put together a reproduction?

Also, it might help to post the output of with your command (along with the exact command you are running).
Here are the outputs of : <details<summarySuccessful run</summary</details<details<summaryFailed run</summary</detailsI imagine simply running Ubuntu 20.04 and adding this to should do the trick: But I'll verify it and let you know.
Yes, I've verified that this is reproducible on a clean Ubuntu 20.04 installation or live CD. Other than the commands above you need to and install Rust through
Oh, I see that the failed run does contain the flag. So it is the same issue. I'm confused why implicitly enables it by default while other invocations don't, but that's a separate issue.
rustfilt sets LTO . I don't know what other commands you are running, but if it is , then that would use the dev profile without LTO.
Up on message:
Change:
<ins> // edition:2018 use std::sync::{Arc, Mutex}; pub async fn f(_: ()) {} pub async fn run() { let x: Arc<Mutex<()>> = unimplemented!(); f(*x.lock().unwrap()).await; } </ins>

Discussion:
When learning async/await feature I was struggling with running multiple tasks simultaneously. Loop causes compiler to crash Github Action crash output: I expected to see this happen: Error message if something goes wrong. Instead, this happened: Compiler crashed Crash happens on macOS rustc 1.40 / Linux rustc 1.40 / Linux rustc 1.39 ( github actions ) :
If you could provide an example that ICEs in e.g. the playground that would be helpful towards fixing the issue. :)
Provided example is pretty small, but it is dependent on tokio and actix-web. I do not know how to create such an example in playground, I do know know how I can replace async tokio::sync::mpsc with standard library which does not have async alternative as far as i know. I have tried to simplify code but then crash disappear. Just putting everything into one file and crash is gone, code wont compile and reasonable errors show up.
Visiting from triage.. we decided that as the first step we should reduce this reproducer to a more self-contained one.
Can repro. Will try and min.
Reduced version so far is here:
This no longer ICEs on the latest nightly.
Let's see if we can shrink further so that we can add a test. ping cleanup
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
I’ve reduced it quite a bit. Down to dependencies on only. Appears to need 2 crates.

I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.
Change:
<ins> // check-pass #![feature(type_alias_impl_trait)] pub type Successors<'a> = impl Iterator<Item = &'a ()>; pub fn f<'a>() -> Successors<'a> { None.into_iter() } pub trait Tr { type Item; } impl<'a> Tr for &'a () { type Item = Successors<'a>; } pub fn kazusa<'a>() -> <&'a () as Tr>::Item { None.into_iter() } fn main() {} </ins>

Discussion:
ICE message: <details<summaryBacktrace</summary</summary
This should be erroring in exhaustiveness checking; shouldn't be allowed there. cc
It should be erroring earlier, when trying to create a pattern out of the constant. And it should also not be considered structural-match type-wise.
Triage: This is no longer ICE, seems that it's fixed by , marking as E-needs-test.

gives: My guess is that this has the same underlying cause as , but this one doesn't involve associated consts or arrays at all, so it might be different still.
This appears to be due to a bad interaction between and associated type projections involving lifetimes. When we normalize the function signature during type-checking, we project to . We then convert back to the 'generic' region for , which is . However, this is a distinct early bound region, different from the in (changing the regions to not all be called in the example makes this clearer). This causes issues during , since we've essentially pulled a region out of thin air. This issue doesn't seem to come up for type parameters ( with lifetimes replaced with types). I'm not sure if this is because our handling of type parameters is correct for this kind of projection, or if we need a more complicated example to break things.
The ICE no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.

I got an internal compiler error at commit . I dont know how to minimize it. Relevant code is: If I remove the const field and directly put the array size like below, the ICE goes away and I get the expected compilation error that [u8; 68] is not . <details<summaryBacktrace:</summary</details<details<summaryVersion info</summary</details
The ICE also goes away if I change to
Ok. I minimized it to just: It ICEs on latest nightly:
triage: P-high, assiging to self, removing nomination label
Following example fails to compile: <details<summaryError</summary</detailsEven if I add , still issue: or <details<summaryError</summary</detailsBut this works:
Also just got this; no idea how to minimize it and the trace doesn't seem useful:-
If this is referring to the field , it's defined as where is defined inside the impl as .
Inlining resolves the error, ie changing buffer's definition to .
no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.
Change:
); } <del> if let Some((expected, found)) = tcx .infer_ctxt() .enter(|infcx| infcx.expected_found_str_ty(&ExpectedFound { expected, found })) </del> <ins> if let Some((expected, found)) = self.infcx.expected_found_str_ty(&ExpectedFound { expected, found }) </ins> { // Highlighted the differences when showing the "expected/found" note. err.note_expected_found(&"", expected, &"", found);

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. --(I know this is probably incorrect code, but this is what triggered the internal compiler error). <!-- 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
Assigning as and removing .
44 doesn't have the ICE.
shows that this can result in no user-facing error message. I suggest increasing priority to .
Change:
[stackoverflow]: http://stackoverflow.com/questions/tagged/rust This installer also installs a copy of the documentation locally, so we can <del> read it offline. On UNIX systems, `/usr/local/share/doc/rust` is the location. On Windows, it's in a `share/doc` directory, inside the directory to which Rust was installed. </del> <ins> read it offline. It's only a `rustup doc` away! </ins> # Hello, world!

Discussion:
Specifically at , and recommend for Windows too, right? We've , but in the meantime, the old book should recommend the new recommended toolchain :) If it's too soon to do this because isn't stable enough yet, consider this a reminder issue to make this change once it is :)
wants to wait a bit, and we'd need to then make sure to update the website in sync (see )
Maybe the big red warning "this is beta software" should be removed from the website?
This will be fixed by
Change:
// For this we need to reclone the macro body as the previous parser consumed it. let retry_parser = create_parser(); <del> let parse_result = tt_parser.parse_tt( &mut Cow::Owned(retry_parser), &argument_gram, &mut diagnostics::FailureForwarder, ); </del> <ins> let mut track = diagnostics::FailureForwarder::new(); let parse_result = tt_parser.parse_tt(&mut Cow::Owned(retry_parser), &argument_gram, &mut track); </ins> let Failure((token, _, msg)) = parse_result else { unreachable!("matcher returned something other than Failure after retry"); }; <del> let s = parse_failure_msg(&token); </del> <ins> let s = parse_failure_msg(&token, track.get_expected_token()); </ins> let sp = token.span.substitute_dummy(def.span); let mut err = sess.dcx().struct_span_err(sp, s); err.span_label(sp, msg);

Discussion:
one of the desired output should be much help, rather than: No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
false } <ins> /// Would `maybe_whole_expr` in `parser.rs` return `Ok(..)`? /// That is, is this a pre-parsed expression dropped into the token stream /// (which happens while parsing the result of macro expansion)? crate fn is_whole_expr(&self) -> bool { if let Interpolated(ref nt) = self.kind { if let NtExpr(_) | NtLiteral(_) | NtPath(_) | NtIdent(..) | NtBlock(_) = **nt { return true; } } false } </ins> /// Returns `true` if the token is either the `mut` or `const` keyword. crate fn is_mutability(&self) -> bool { self.is_keyword(kw::Mut) ||

Discussion:
The CI for started to fail today with this error: It appears as though the compiler doesn't see and only sees as the range expression and then generates this error. The expression is inside a expansion. You can reproduce this by cloning the repo and building it: The build succeeds on the stable channel and much older releases, so this appears to be a regression in the nightly. Here's the version on my windows system, but note that this also fails on linux and macos too:
Regression introduced in
More specifically the bug is in: which is called to see whether what follows is a valid start of a range pattern end expression. This is strange tho... in the case of e.g.: the call to in is used successfully to parse but somehow that doesn't work for . cc
Similarly, with: this does not trigger "error: range patterns are not supported" but it should.
Change:
return; } but.onclick = () => { <del> const path = []; onEachLazy(document.querySelectorAll(".rustdoc-breadcrumbs a"), a => { path.push(a.textContent); }); path.push(document.querySelector("title").textContent.split(" ")[0]); </del> <ins> // Most page titles are '<Item> in <path::to::module> - Rust', except // modules (which don't have the first part) and keywords/primitives // (which don't have a module path) const title = document.querySelector("title").textContent.replace(" - Rust", ""); const [item, module] = title.split(" in "); const path = [item]; if (module !== undefined) { path.unshift(module); } </ins> copyContentToClipboard(path.join("::")); copyButtonAnimation(but);

Discussion:
! Compare e..g , where the button correctly produces in the clipboard, with , where it currently gives me instead! I would guess, this is a change that came with the redesign in , though I haven’t checked to confirm that. This only happen with modules; things like structs, macros, type synonyms… als seem to work correctly. cc label +T-rustdoc +T-rustdoc-frontend +A-rustdoc-ui <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Most pages have the title - but modules don't have this, so the title of the page is just appended to . claim
Change:
crate use renderer::{run_format, FormatRenderer}; <del> use crate::clean; </del> <ins> use crate::clean::{self, ItemId}; </ins> /// Specifies whether rendering directly implemented trait items or ones from a certain Deref /// impl.

Discussion:
! All pointing to the same impl: ! label +T-rustdoc
Actually, the never type , the trait and are not needed: It occurs with any type and any parameterized trait. Minimal reproducible example: The number of duplicates depends on the number of public types accessible in the target crate.
Taking a look.
code: Gives: !
Change:
UNUSED_ALLOCATION, UNUSED_DOC_COMMENTS, UNUSED_EXTERN_CRATES, <del> UNUSED_CRATE_DEPENDENCIES, </del> UNUSED_FEATURES, UNUSED_LABELS, UNUSED_PARENS,

Discussion:
lint introduced in causes false positives for . To reproduce: I expected to execute correctly. Instead, this happened: I expect to be ignored by this lint, because they are in fact used in modules. "remove the dependency or add " help message is also unhelpful, because it will cause unresolved imports for and similar commands. : <details<summaryFull verbose build log</summary<p</p</details
cc needs to be removed from the lint group, I didn't notice this when reviewing Otherwise it can be enabled in a blanket way without enabling specifically, which is undesirable given the amount of redundant options passed by Cargo.
Fixed in
Yeah this is the reason it's not on by default. We still need to work out if/how it can be used with cargo in a reasonable way. Adding it to made sense to me but I didn't think through the fallout.
Though TBH I'm a bit confused - what targets is Cargo passing dev-dependencies to aside from tests? I would have thought your case would be OK. Hm, I think there may be another bug that isn't seeing uses in blocks. At the very least it needs a test for that.
As far as I can tell, this issue wasn't fixed, was just removed from the group. The functionality of is still desirable! See
Change:
warning: trailing semicolon in macro used in expression position <del> --> $DIR/semicolon-in-expressions-from-macros.rs:7:13 </del> <ins> --> $DIR/semicolon-in-expressions-from-macros.rs:8:13 </ins> | LL |         true; |             ^

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. --I don't have a minimal example yet, but here's . Sample: The ICE happens on the and macros, which are both from the crate. <!-- 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. --This began with commit . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
FYI, I think that link is only accessible to Googlers: !
Sorry, .
Minimized: Caused by
When we run on the AST, we create a definition for the desugared closure body inside an : As a result, the entry for our macro call will have the of the desugared closure. However, this desugared closure does not actually exist in the AST (it is created during lowering), so we will never check for lints with its when we emit buffered early lints.
Nightly has been broken for 3 days, if there's disagreement on how to fix the issue, can we revert while the fix is being worked on?
This will be fixed by PR
I'm still hitting this bug with the latest nightly.
Change:
use std::fmt; use rustc::hir::def_id::DefId; <ins> use rustc::util::nodemap::FxHashSet; </ins> use rustc_target::spec::abi::Abi; use rustc::hir;

Discussion:
Example: Behavior is observable on stable and nightly. Clearly can be shortened to just .
This is a problem with how the struct is represented when re-exporting from a different crate. For example, : The gets converted into a where clause in the re-export, but i'm not sure what introduces the duplicate lifetime bound.
Current documentation still has evidence of this bug: see e.g. in