jiebi/CodeConvo huggingface dataset:
Change:
}, hir::MatchSource::Normal => { <del> span_err!(cx.tcx.sess, pat.span, E0001, "unreachable pattern") </del> <ins> let mut err = struct_span_err!(cx.tcx.sess, pat.span, E0001, "unreachable pattern"); // if we had a catchall pattern, hint at that for row in &seen.0 { if pat_is_catchall(&cx.tcx.def_map.borrow(), row[0]) { span_note!(err, row[0].span, "this pattern matches any value"); } } err.emit(); </ins> }, hir::MatchSource::TryDesugar => {

Discussion:
This simple code fails to compile because is not defined. But the error message is . But is not the cause it just happens to occur after .
I agree that this is confusing, though from the compiler's perspective, the error message makes sense. Since isn't a variant of , becomes the name of a binding that matches all possible values of other than . (See ) Once that happens, the case is indeed unreachable.
Perhaps the error message could point to the match arm that the unreachable arm overlaps with.
Also if you comment out the Bar arm, you get a snake-case warning on Other, but unfortunately the error happens first.
Thanks for your coments. Now at least I understand why the compiler printed this error message.
Related:
Change:
let result = match (&desc.should_panic, task_result) { (&ShouldPanic::No, Ok(())) | (&ShouldPanic::Yes, Err(_)) => TestResult::TrOk, (&ShouldPanic::YesWithMessage(msg), Err(ref err)) => { <del> if err </del> <ins> let maybe_panic_str = err </ins> .downcast_ref::<String>() .map(|e| &**e) <del> .or_else(|| err.downcast_ref::<&'static str>().map(|e| *e)) .map(|e| e.contains(msg)) .unwrap_or(false) { </del> <ins> .or_else(|| err.downcast_ref::<&'static str>().map(|e| *e)); if maybe_panic_str.map(|e| e.contains(msg)).unwrap_or(false) { </ins> TestResult::TrOk <ins> } else if desc.allow_fail { TestResult::TrAllowedFail } else if let Some(panic_str) = maybe_panic_str { TestResult::TrFailedMsg(format!( r#"panic did not contain expected string panic message: `{:?}`, expected substring: `{:?}`"#, panic_str, msg )) </ins> } else { <del> if desc.allow_fail { TestResult::TrAllowedFail } else { TestResult::TrFailedMsg( format!("panic did not include expected string '{}'", msg) ) } </del> <ins> TestResult::TrFailedMsg(format!( r#"expected panic with string value, found non-string value: `{:?}` expected substring: `{:?}`"#, (**err).type_id(), msg )) </ins> } } (&ShouldPanic::Yes, Ok(())) => {

Discussion:
When running this test (): the output is which makes it hard to spot the difference in whitespace characters. Would it be possible to change this to e.g.: This would improve the usability when running into these kinds of test failures and also make it more consistent with which outputs both the left and the right value too.
Agree with having them vertically aligned. I think we do want line endings to create a new line though for multi-line readability. Maybe we should say something like this: (The first difference at char line we might also want to add to assert_eq also?)
The message sounds good, but I am not sure how well it applies to the comparison, as it is not an equality, but a substring comparison. Maybe we could adjust the wording of the error message to e.g.: to make that easier to spot. I think the escaping is essential, take for instance which has no newlines, but contains : On many shells, this will produce this output: which makes it very hard for a user to figure out what's going on (let's assume the happens in a more obscure location). Maybe a more important reason is that escaping would be consistent with the behavior of , which for : outputs: The escaping avoids surprises which could occur depending on the user`s environment.
Ok I'm sold. Do you want to fork rust-lang/rust and submit this as a PR? (If you don't want to I can do the legwork).
Thanks for the offer, I'll try to write a PR and will add you as a reviewer once I have a first version ready.
Change:
// compiler. if !already_has_extern_crate && !opts.no_crate_inject && cratename != Some("std") { if let Some(cratename) = cratename { <del> // Make sure its actually used if not included. </del> <ins> // Don't inject `extern crate` if the crate is never used. // NOTE: this is terribly inaccurate because it doesn't actually // parse the source, but only has false positives, not false // negatives. </ins> if s.contains(cratename) { <del> prog.push_str(&format!("extern crate {};n", cratename)); </del> <ins> prog.push_str(&format!("extern crate r#{};n", cratename)); </ins> line_offset += 1; } }

Discussion:
In I tried to create a new testcase that runs doctests. However having the substring in a doctest comment injected an invalid into the code generated for the doctest. Turns out this here is a bit too aggressive: It looks like compiletest actually gave the crate the name , perhaps because it was defined in a file, and having a doctest such as this triggers the this auto-injection, resulting in a failed doctest run: /// // ^ line 10 /// assert_eq!(1, 1); /// `
I think rustdoc needs to check if the crate name is a keyword and add if so. Actually it's probably enough to unconditionally add since it works for things that aren't keywords.
there is actually two bugs here. not being properly escaped is one thing, the other is probably the way that rustdoc is invoked, or not quite sure. Basically it infers the crate name from the file name if not explicitly given, and then just assumes that a crate with that name exists, which it doesn’t.
that's an issue with compiletest, not rustdoc - it needs to compile the crate itself before running rustdoc on it: I don't know how to fix that, I think compiletest needs to add support for this maybe?
Change:
} } <ins> #[derive(Debug, Copy, Clone, Hash, PartialEq, Eq)] pub struct LldWrapper { pub compiler: Compiler, pub target: TargetSelection, pub flavor_feature: &'static str, } impl Step for LldWrapper { type Output = PathBuf; fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.never() } fn run(self, builder: &Builder<'_>) -> PathBuf { let src_exe = builder .ensure(ToolBuild { compiler: self.compiler, target: self.target, tool: "lld-wrapper", mode: Mode::ToolStd, path: "src/tools/lld-wrapper", is_optional_tool: false, source_type: SourceType::InTree, extra_features: vec![self.flavor_feature.to_owned()], }) .expect("expected to build -- essential tool"); src_exe } } </ins> macro_rules! tool_extended { (($sel:ident, $builder:ident), $($name:ident,

Discussion:
Checked that on target, found duplicates in versions: and <strikeno duplicates</strike2 duplicates (<strikeonly</strike, ) in stable , (bisecting is kinda slow on my connection) there 3 copies of that executable, that gives ~ 187mb label +regression-from-stable-to-beta
Can be found in:
I think they were in and . I believe is also a copy of .
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
claim
Sorry, I only came across this issue just now. The copies are there for a reason, see linked issues. Multiple things to consider: The files in the directory are only used with the unstable option. So they could be removed for beta and stable. They can be replaced with small Rust executables which just exec and respectively. I will be working on that for nightly.
Change:
<ins> error: expected `;`, found `println` --> $DIR/issue-87197-missing-semicolon.rs:6:16 | LL |     let x = 100 |                ^ help: add `;` here LL |     println!("{}", x) |     ------- unexpected token error: expected `;`, found keyword `let` --> $DIR/issue-87197-missing-semicolon.rs:7:22 | LL |     println!("{}", x) |                      ^ help: add `;` here LL |     let y = 200 |     --- unexpected token error: expected `;`, found `println` --> $DIR/issue-87197-missing-semicolon.rs:8:16 | LL |     let y = 200 |                ^ help: add `;` here LL |     println!("{}", y); |     ------- unexpected token error: aborting due to 3 previous errors </ins>

Discussion:
: The current output is: We should detect cases where a semicolon would be appropriate (probe that the current token and maybe limited lookahead confirm that what comes next could be a valid statement on its own) and suggest a semicolon. . We might want to silence one or the other depending on whether the current token might be starting a statement or an item ( vs , etc.). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Sorry, I don't have much time these days. release-assignment
Just a guess: could this be addressed with another block, as in
I think we would need to answer this question: why is the logic here not handling the cases we want to handle?
This seems to be on track given the clue "probe that the current token and maybe limited lookahead confirm that what comes next could be a valid statement on its own"...
claim
release-assignment
That is a great question: as the code is written it looks like it should work. I don't know why it isn't triggering :( It might be that isn't being called in these case. It might be a good idea to uplift most of this method into
I'd like to give this a try. claim
Change:
<ins> // compile-pass // edition:2018 #![feature(async_await)] // This is a regression test to ensure that simple bindings (where replacement arguments aren't // created during async fn lowering) that have their DefId used during HIR lowering (such as impl // trait) are visited during def collection and thus have a DefId. async fn foo(ws: impl Iterator<Item = ()>) {} fn main() {} </ins>

Discussion:
I was using nightly rust extensively for its async/await and specialization feature. After a recent update (nightly-2019-05-02), a new ICE introduced with following logs: After a quick search it seems like is the only in direct cause (stack frame 10). ~I cannot share the code or produce a minimal case because the code base is rather big.~
I've the minimal case for reproducing. Hope that would help!
Thanks! Looks like even this line is enough to trigger the ICE:
: rustc complains you should have variable mut although it is already mut.
That's and should be fixed in the next nightly
cc it looks like the desugaring may have broken in argument-position?
Oops, sorry. I'll take a look.
Denominating since already has a fix
Thanks guys! This is a super fast fix!
Change:
<ins> // aux-build:trait-visibility.rs #![crate_name = "foo"] extern crate trait_visibility; // @has foo/trait.Bar.html '//a[@href="#tymethod.foo"]/..' "fn foo()" pub use trait_visibility::Bar; </ins>

Discussion:
The trait on 1.49.0 (current stable) doesn't contain modifier in function declaration of that trait. ! However, on and nightly, there is modifier. ! This is wrong because you cannot use modifier for each method/function in Trait definition. Why is this important? People copy the method/function declaration in the documentation to their code and see the compiler error: . : cc I think this might relate to some changes in visibility around macros ? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Yes, this needs the same fix as (in particular should work).
Self-assigning because this is a beta regression.
Note that this also occurs for the impl's docs.
Removed since this was fixed.
, trait methods still rendered as : ! Is there something wrong to Rust release or the bug still exists ?
Hmm, maybe it was only fixed for items in the local crate. do you have time to come up with an MCVE? I expect it's related to cross-crate re-exports.
Your guess sounds right. With core link (), things are normal.
I don't think I'll have time to fix this second part soon, so unassigning myself.
Assigning and removing as in the prioritization working group.
Removing E-mentor + E-easy labels since we don't have guides for cross-crate linking: label -E-easy -E-mentor
I think is the cross-crate case.
Fix backported to 1.50.0 and landed in 1.51.0, closing this.
Please reopen. The issue is not entirely fixed for cross-crate trait reexport case.
The cross-crate issue is now on stable. label: +regression-from-stable-to-stable -regression-from-stable-to-beta
claim
Change:
return Err(NoSolution); } <del> // If `Fn`/`FnMut`, we only implement this goal if we // have no captures. let no_borrows = match args.tupled_upvars_ty().kind() { ty::Tuple(tys) => tys.is_empty(), ty::Error(_) => false, _ => bug!("tuple_fields called on non-tuple"), }; if closure_kind != ty::ClosureKind::FnOnce && !no_borrows { </del> <ins> // A coroutine-closure implements `FnOnce` *always*, since it may // always be called once. It additionally implements `Fn`/`FnMut` // only if it has no upvars referencing the closure-env lifetime, // and if the closure kind permits it. if closure_kind != ty::ClosureKind::FnOnce && args.has_self_borrows() { </ins> return Err(NoSolution); }

Discussion:
I've returned to one of my projects after a few months of pause. Before I was using rust nigthly ~1.7x (around November 2023). It also worked through whole 2022 and 2021 IIRC. I've moved to new computer and installed rust nightly 1.80 (latest). After upgrading I noticed that my whole codebase is full of errors around capturing something from environment. . However if I change to it builds and works like previosly. Minimal example below. The error for first method is: i booted my very old PC to check, this is definately not the last version this worked fine: I definately does not work with:
Minimal: This should be possible now to support due to changes in . I'll put up a fix soon.
Change:
} pub fn join(self) { <del> unsafe { c::WaitForSingleObject(self.handle.raw(), c::INFINITE); } </del> <ins> let rc = unsafe { c::WaitForSingleObject(self.handle.raw(), c::INFINITE) }; if rc == c::WAIT_FAILED { panic!("failed to join on thread: {}", io::Error::last_os_error()); } </ins> } pub fn yield_now() {

Discussion:
Considering following snippets: Currently on linux, the spawned thread will just panic at option unwrap which happen inside std library: It makes no sense to call join inside the associated thread, but a meaningless panic is sure not the good way to handle this situation. Maybe we should return an error which contains the join handle, so the caller can recover the failure. If panic is preferred, then a more friendly message should be good for users.
This seems like a reasonable-ish panic, though it would perhaps be better to have the error be returned within the result, though the current behavior is as documented, so I think it's reasonable.

Gives (on playground): There are two problems here: error message is absolutely terrible. the sake of safety, we might need to do something other than panic if this happens. This could affect crates which require that join() never returns early, like crossbeam.
Possibly in or otherwise, but this seems to have since been fixed -- this now deadlocks.
Change:
parser.span_err(span, &msg[..]); let msg = format!("caused by the macro expansion here; the usage  <del> of `{}` is likely invalid in this context", self.macro_ident); </del> <ins> of `{}!` is likely invalid in {} context", self.macro_ident, context); </ins> parser.span_note(self.site_span, &msg[..]); } }

Discussion:
This compiles: I expected this to be rejected, simply because doesn't parse as a type.

afaik, it's because the context where you're using the macro (expr, item, etc.) stopped parsing before that token. We should mention that context.
Is this fixed? I think this was fixed the referenced pull request.
I'd prefer a message like
Change:
on: branch: auto DEPLOY: 1 <ins> max_error_retry: 5 </ins> # This provider is the same as the one above except that it has a slightly # different upload directory and a slightly different trigger

Discussion:
Seen twice now with the failure message: Logs: I'll probably email them about retries and such come next week, wanted to start collecting logs in the meantime.
sigh
We've got enough examples now I've about this.
An has been created for this.
Change:
// except according to those terms. #[derive(Copy)] //~ ERROR E0184 <ins> //~| NOTE Copy not allowed on types with destructors //~| NOTE in this expansion of #[derive(Copy)] </ins> struct Foo; impl Drop for Foo {

Discussion:
From: src/test/compile- Error E0184 needs a span_label, updating it from: To: Bonus: I'm not sure that note is helping, you can probably just remove it.
On it
- I am releasing this one so someone else can take it, but feel free to come grab another one

From: src/test/compile- Error E0165 needs a span_label, updating it from: To:

From: src/test/compile- Error E0164 needs a span_label, updating it from: To:
Change:
<ins> // edition:2018 // aux-build:issue-51798.rs // check-pass extern crate issue_51798; mod server { fn f() { let mut v = issue_51798::vec(); v.clear(); } } fn main() {} </ins>

Discussion:
I'm sorry, I haven't reduced this at all, and I'm sure the code is awful, but the error message said you'd appreciate a bug report. I tried this code: jeremyBanks/0dmg using I expected to see this happen: my program would run, or the compiler would give one of its typical helpful error messages! Instead, this happened: I am using the Windows Linux Subsystem thing with Debian or Ubuntu, I think. : : Backtrace:
If I use cargo doc I get a different stack trace:
The crash stopped occurring in my code when I fixed an invalid import: see jeremyBanks/0dmg
I'm pretty certain this is caused by being directly indexed without being checked here: But, really, it'd be nice to have a reduced test case so we can confirm the bug is fixed afterwards.
Makes sense. I'll try to pare it down to something useful.
I'm failing to reproduce this crash without using multiple crates, so I can't figure out how to put it in a Playground example or doc test, but here's a reduced example ().
Okay, I've got the failure occurring in a compiler test at jeremyBanks/rust Result: If I understand correctly, it will be possible to turn this into a regression test by annotating it with the desired non-panic output, once this issue has been fixed and we know what the fixed output looks like. But since we're not sure what the will look like, there'd be no point trying to get this merged yet.
now that is merged and should be in the next Nightly, could you check your test-case again to see whether it's fixed? I didn't have time to add your test case before it was merged. Thanks!
I think it's fixed. My stand-alone test case produces the same initial error message of "no type-dependent def for method call", but it no longer displays any panic; it seems to exit cleanly. Using built from : Using : (Now running in a normal Debian VM. Sorry for the constantly-changing platform. :P)
Sorry! I didn't mean to submit the post yet, or close the issue, but I mis-clicked. I'm still trying to figure out the appropriate annotations to make this pass as a test.

If I get the test working behaving properly, would it be useful to send a PR to add my regression test, or is this too small of an issue to warrant one?
yes, a regression test would be useful here. Actually, I don't think the behaviour is even correct here — it shouldn't be displaying that error at all, even if it's not actually crashing.
Did a test ever get here?

Compiling this code results in: There is no backtrace. If I disable specialization feature, rustc reports an error: ` Rustc details:
This seems to compile as of the most recent nightly.
Good to hear that! Would it make sense to add this example to the test suite to prevent regressions in the future?
Change:
<ins> // edition:2018 // aux-build:issue-51798.rs // check-pass extern crate issue_51798; mod server { fn f() { let mut v = issue_51798::vec(); v.clear(); } } fn main() {} </ins>

Discussion:
I wanted to test our handling of slices that are "too big" (bigger than the largest possible allocation), so I wrote: I expected an ICE or so, but I got a timeout. On nightly, here's what a stacktrace looks like: looks like the interning could do with a fast path for integer slices similar to what validation does? And maybe it could also check that the reference is dereferencable before walking it, that would avoid finding out later that we are going to produce an error anyway.
This now finishes in milliseconds with an error:

rustc crashes ungracefully when given the following input (found by ): I'm seeing this behavior on stable, beta, and nightly.
cc
Interesting: I'm not familiar with but that's where we are aborting:
cc
If I change the body of to this: then the compiler aborts how you would expect. I caught the panic in gdb (with ). It is coming from . Here's the stack trace: So it seems like this is a "legitimate" panic from the parser that the compiler would normally catch gracefully somewhere... except that assumes the closure it calls never panics and just aborts immediately if so. 's current implementation arose out of . any thoughts on how could let the panic pass through in a memory-safe manner? Or is that not possible?
I think there’s no magic trick here. Afaik the only safe way to do this is to mem::replace t with a dummy value, apply f, and swap the result back, but that requires that t has a dummy value. Does the code break if you add T: Default bound? Also, when suggesting that change I was 80% sure that it’s pure pedantry because, clearly, we don’t panic anywhere :) I am fascinated by how conspicuous and shallow such “benign” problems become in rust!
cc re:macros/ being ky.
Yes. Unfortunately, lots of the involved types lack a bound, and adding one doesn't make sense. wants the commit that introduced to be reverted anyway. Perhaps that's the best path forward, even though it'll be a perf hit. If I'd stuck with the original code that didn't handle panics it would have been a double-free without warning. One of those " is trickier than you might think" moments.
Or we just accept the current behaviour, because it's a benign abort on a very obscure case, and is being phased out anyway...
What's the plan post-? Benign to , but it will kill RLS or any other long lived tool. (Not that I disagree that we can live with this in the medium term.)
Just in case it's useful: here is a variation that causes (what I assume is) the same abort with only the macro:
I am unable to reproduce this crash on the latest releases. I was curious what fixed it, so I tried bisecting with nightlies.

The crash still happens on but no longer happens on . Unfortunately, it looks like nightlies are not available in between those two. In any case, as far as I'm concerned, this issue may be closed now.
Let's close this with a PR containing these repro cases as regression tests.
Change:
Some(did) => did, None => return fallback(box t.clean(cx)), }; <del> let fqn = cx.tcx().sess.cstore.item_path(did); let fqn: Vec<String> = fqn.into_iter().map(|i| { i.to_string() }).collect(); cx.external_paths.borrow_mut().as_mut().unwrap().insert(did, (fqn, TypeStruct)); </del> <ins> inline::record_extern_fqn(cx, did, TypeStruct); </ins> ResolvedPath { typarams: None, did: did,

Discussion:
The [src] link on these pages is broken: The links are also broken in the stable docs version of these pages.
I think this should be fixed by . The links wrongly point to instead of because the crate is linked in std like
I've built the docs locally and the issue somehow persists.