jiebi/CodeConvo huggingface dataset:
Change:
| LL | fn baz<T: Foo>(_: T) {} |           ^^^ <ins> help: consider specifying the type of the closure parameters | LL |     baz(|_: &_| ()); |         ~~~~~~~ error: implementation of `FnOnce` is not general enough --> $DIR/closure-mismatch.rs:11:5 | LL |     baz(|x| ()); |     ^^^^^^^^^^^ implementation of `FnOnce` is not general enough | = note: closure with signature `fn(&'2 ())` must implement `FnOnce<(&'1 (),)>`, for any lifetime `'1`... = note: ...but it actually implements `FnOnce<(&'2 (),)>`, for some specific lifetime `'2` error[E0308]: mismatched types --> $DIR/closure-mismatch.rs:11:5 | LL |     baz(|x| ()); |     ^^^^^^^^^^^ one type is more general than the other | = note: expected trait `for<'a> Fn<(&'a (),)>` found trait `Fn<(&(),)>` note: this closure does not fulfill the lifetime requirements --> $DIR/closure-mismatch.rs:11:9 | LL |     baz(|x| ()); |         ^^^ note: the lifetime requirement is introduced here --> $DIR/closure-mismatch.rs:5:11 | LL | fn baz<T: Foo>(_: T) {} |           ^^^ help: consider specifying the type of the closure parameters | LL |     baz(|x: &_| ()); |         ~~~~~~~ </ins> <del> error: aborting due to 2 previous errors </del> <ins> error: aborting due to 4 previous errors </ins> For more information about this error, try `rustc --explain E0308`.

Discussion:
a new project with (in my case, it used pathfinding version 4.0.0 or 4.0.1) with: produces the following output: For the two closures ( and ), if I add a type for the parameter by changing to , it builds without any errors. If it had told me that it needed type annotations, I would have understood the problem and been able to fix it right away. (I assumed that there was enough type information for it to infer the correct types.) The first confusing bit is that both errors highlight the entire call to , including all parameters. This makes it harder to figure out which one it is complaining about (though the second note contains the line number). Does the first argument have something to do with the lifetimes it is complaining about? I found this part of the message hard to understand: The type parameters look almost identical, and the didn't make sense to me. Could it somehow indicate the bounds of that lifetime (2), or better explain why that lifetime doesn't last long enough? FYI: found as part of solving Advent of Code 2022, Day 12. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A smaller MCVE:
I'm thinking whether we should fix this as a compiler bug (i.e., make it compile) or suggesting people write explicit type here
maybe related:
Also if we move the closure to the parameter: This will also compile. Combined with , I guess something is wrong with propagating lifetime of closures when we store it in a variable...
claim
Change:
self.insert_field_names_local(def_id, vdata); } <del> ItemKind::Impl(.., ref impl_items) => { for impl_item in impl_items { self.resolve_visibility(&impl_item.vis); } } </del> ItemKind::Trait(..) => { let def_id = self.r.definitions.local_def_id(item.id);

Discussion:
<short summary of the bugI tried this code: Running on a project that has as its direct or indirect dependency. I expected to see this happen: All packages documented. Instead, this happened: — also fails on . : Does also happen for older nightlies, though I forgot to capture the versions before updating in hope it'd fix the issue. There are more ICE issues pointing at , but none on this line here. Backtrace:
I can confirm that this ICE does not occur on Rust 1.37.0 stable, as shown in This might be a regression that slipped through the stable release somehow.
This still happens on 1.39 stable.
cc
It also does it when documenting a project with on nightly. I had no trouble documenting all deps more than 2 weeks ago though.
This happened on our recent build rust 1.39.0 as well.
cc please triage regressions! If anyone would like to help out here: This is in need of a minimal example that reproduces the issue, as well as a bisection to pinpoint the PR that introduced this regression.
Sorry for not getting to this earlier. I've reduced down to: The is coming from the path inside which is messed up somehow by the macro. Bisecting this pointed to which almost certainly means it was caused by (cc. This is an issue in rustc as well because if you try to use the method from another crate like this for example: rather than the expected new` error since it now produces an ICE: <details<summarybacktrace</summary</detailsAnother interesting case comes from removing the inner module: This compile before but now somehow. Also the regressions in and are a similar but newer regression which I've made a new issue for: .
I guess I'll take a look since it's been a week. Thanks for the minimal code case!
Was this not fixed by ?
I don't know. If so then we're all good?
No, I can confirm there's still an ICE.
Is the nonrustdoc example from still ICEing or is it just the rustdoc issue left?
I'll see what happens.
Similarly to the case in this ICE in rustdoc may mean that a bug or error is silently ignored in rustc. So hiding it like does is not a good idea.
Fixed in
Change:
"checksum ammonia 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "a8b93ecb80665873703bf3b0a77f369c96b183d8e0afaf30a3ff5ff07dfc6409" "checksum ammonia 2.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "c799ecf1ad77acb48b643e2f45b12d60ee41576287fc575031aa020de88b8f45" "checksum annotate-snippets 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)" = "e8bcdcd5b291ce85a78f2b9d082a8de9676c12b1840d386d67bc5eea6f9d2b4e" <ins> "checksum annotate-snippets 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)" = "c7021ce4924a3f25f802b2cccd1af585e39ea1a363a1aa2e72afe54b67a3a7a7" </ins> "checksum ansi_term 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)" = "ee49baf6cb617b853aa8d93bf420db2383fab46d314482ca2803b40d5fde979b" "checksum arc-swap 0.3.7 (registry+https://github.com/rust-lang/crates.io-index)" = "1025aeae2b664ca0ea726a89d574fe8f4e77dd712d443236ad1de00379450cf6" "checksum argon2rs 0.2.5 (registry+https://github.com/rust-lang/crates.io-index)" = "3f67b0b6a86dae6e67ff4ca2b6201396074996379fba2b92ff649126f37cb392"

Discussion:
Part of To support lines in the first column of UI test output, we have to make use of the flag and update the library. Relevant : The relevant PR in the annotate-snippet library and a new version needs to be released. Once that's done, we have to pass as a second argument to . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
modify labels: A-diagnostics E-help-wanted
claim
Change:
} PatKind::Range(ref e1, ref e2, Spanned { node: ref end, .. }) => { break hir::PatKind::Range( <del> e1.as_deref().map(|e| self.lower_expr(e)), e2.as_deref().map(|e| self.lower_expr(e)), </del> <ins> e1.as_deref().map(|e| self.lower_expr_within_pat(e, true)), e2.as_deref().map(|e| self.lower_expr_within_pat(e, true)), </ins> self.lower_range_end(end, e2.is_some()), ); }

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. --Note: this only occurs when the type of the code block is a result. Removing the line and swapping for does not yield the ICE. //! use rustice::sub; //! //! let x = sub::makestruct()?; //! //! assert!(matches!(x, sub::En::A(sub::B { inner: vec![], .. }))); //! Ok::<(), &'static str(()) //! <!-- 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. --: and after a rustup, (still getting the same ICE): <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Here's a reproduction without rustdoc involved:
Minimized:
Change:
prog.push_str(&everything_else); } else { prog.push_str("fn main() {n    "); <del> prog.push_str(&everything_else.replace("n", "n    ")); </del> <ins> prog.push_str(&everything_else); </ins> prog = prog.trim().into(); prog.push_str("n}"); }

Discussion:
When using multiline string literal in doctest, rustdoc pads spaces after the newline. The doc renders perfectly fine: ! I tried this code: //! Hello world. //! //! # Examples //! //! //! //! fn main() { println!("hello world!"); } I expected to see this happen: The test should pass. Instead, this happened: The test failed. Did you notice it? : : Backtrace (I don't know if it'd be useful, but):
I hit this issue today as well with a similar case
Triaging: This is still happening on
Change:
/// Additionally, this function will also check if the item is deprecated. If so, and `id` is /// not `None`, a deprecated lint attached to `id` will be emitted. pub fn check_stability(self, def_id: DefId, id: Option<HirId>, span: Span) { <ins> let soft_handler = |lint, span, msg: &_| self.lint_hir(lint, id.unwrap_or(hir::CRATE_HIR_ID), span, msg); </ins> match self.eval_stability(def_id, id, span) { EvalResult::Allow => {} EvalResult::Deny { feature, reason, issue, is_soft } => <del> report_unstable(self.sess, feature, reason, issue, is_soft, span), </del> <ins> report_unstable(self.sess, feature, reason, issue, is_soft, span, soft_handler), </ins> EvalResult::Unmarked => { // The API could be uncallable for other reasons, for example when a private module // was referenced.

Discussion:
Hi there, I'm updating rust-sgx-sdk (solving rust-sgx-sdk ) to use latest rust nightly compiler to help the error info more ergonomic by the help of . However, the compiler always panics. Your help would be very much helpful. The current code is at . To reproduce this bug, please checkout branch and build sgxtstd as follows: And the reproducible failure info is: : rustc 1.40.0-nightly ( 2019-10-03) binary: rustc commit-hash: commit-date: 2019-10-03 host: x8664-unknown-linux-gnu release: 1.40.0-nightly LLVM version: 9.0 Backtrace:
It'd be helpful to have a more minimal example here I suspect -- for example, at least reducing to a single crate. cc since this deals with diagnostic machinery
It seems like this was introduced a month ago in , CC
I think I find the solution on my side: the removal of .
A working branch is baidu/rust-sgx-sdk : test-2019-10. Failing branch is librustc-bug-report. After I enable , the compiler starts to fail.
The minimum sample is as follows: and compile by
Fixed in
Cool!
Change:
fn deref_mut<'a>(&'a mut self) -> &'a mut Result; } <ins> #[cfg(not(stage0))] impl<'a, Sized? T> DerefMut<T> for &'a mut T { fn deref_mut(&mut self) -> &mut T { *self } } </ins> /// A version of the call operator that takes an immutable receiver. #[lang="fn"] pub trait Fn<Args,Result> {

Discussion:
As titled. Add the following trait implementations: This allows generic code that accepts smart pointer can take references too, e.g.
cc
yes I want this :+1:
This would also allow code to be polymorphic over &T and &mut T by accepting . A huge win imho.
The branch creates some .
Change:
<ins> error[E0207]: the lifetime parameter `'a` is not constrained by the impl trait, self type, or predicates --> $DIR/issue-74761.rs:8:6 | LL | impl<'a, 'b> A for () { |      ^^ unconstrained lifetime parameter error[E0207]: the lifetime parameter `'b` is not constrained by the impl trait, self type, or predicates --> $DIR/issue-74761.rs:8:10 | LL | impl<'a, 'b> A for () { |          ^^ unconstrained lifetime parameter error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0207`. </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: I had first seen: Removing the second lifetime () gives the correct error, Additionally, disabling either or still panics (and prompts to enable those features), except in stable where it prompts to enable the features, but does not panic. Perhaps similar to <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The ICE is fixed in the latest nightly, marking as .
Change:
let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, tx, Concurrent::No); let (_, res, _, _) = rx.recv().unwrap(); <del> assert!(res == TrFailed); </del> <ins> assert!(res == TrFailedMsg("test did not panic as expected".to_string())); </ins> } fn report_time_test_template(report_time: bool) -> Option<TestExecTime> {

Discussion:
When a fails because there was no panic it should produce an error message to that effect. For example, the following test: when run with produces the following output: There is no indication why it failed. Which can be problematic if the test itself is created by a macro. Example:
I'm not familiar with the code, but I'd guess that you just need to change in here: to . (And add a test to make sure it works.)
Thanks.I would like to work on this.
go ahead! If you have any questions, feel free to ask them here.
Hi.I've the in and trying to write a test but is this right approach?
actually, I think you can get away with just changing this line: to update it to your , because such a test already exists for this case.
Thanks
The previous fix was closed, so this issue is open again. The contains detailed instructions.
I'd like to finish this out if is no longer working on it.
Change:
match def { cstore::DlImpl(did) => build_impl(cx, tcx, did, impls), cstore::DlDef(Def::Mod(did)) => { <ins> // Don't recurse if this is a #[doc(hidden)] module if load_attrs(cx, tcx, did).iter().any(|a| is_doc_hidden(a)) { return; } </ins> for item in tcx.sess.cstore.item_children(did) { populate_impls(cx, tcx, item.def, impls) }

Discussion:
The link to "FullOps" on this page is broken:
Background for anyone who wants to tackle this: is an unstable trait defined in a module of (specifically in ). It is an implementation detail that should not leak out. Because of the above, the fix is to not list the trait on the implementing type's page, not to generate a doc page for . Other examples of such traits are and on and , which are also listed on the respective pages with dead links.
I want to give it a try, however i don't know what is the right way to test changes. How can i build only the related docs? Make docs rebuilds everything, so it takes a while (even with the flag). How can i quickly test the html output for the docs without rebuilding everything? I tried rustdoc 'path/to/file' too, but it is not able to compile the doc for that given file
Unfortunately, this kind of change is just going to take forever to test. :/ You have to point it at a crate root, not just any rust file.
:( I will give a try to rustdoc once more. Compilations on my machine take around 1 hour, so i don't know if i can fix something that way.
I believe I have an explanation. The annotation on the modules ensures no documentation is created for the module or any traits or similar contained within it. However, when assessing whether s should be hidden on other pages the documentation compiler considers only the hiddenness of the itself, not its containing module. I suspect the existing behaviour is working as intended—consider the case of someone putting their (given public types Foo and Bar) in a doc-hidden module and then wondering where the went. I recommend the simple fix of putting on the s of the public-not-public traits.
Thanka for tracking this down! You are right that impls in private modules should generally be displayed since they are public in a sense. But I think the current state of affairs is very unsatisfying, since Rustdoc generates broken docs for perfectly valid code. Shouldn't it at the very least somit links that will wind up dead? And if both trait and implementing type are dic(hidden), as is the case here, it seems like a reasonable heuristic to treat the impl as hidden too.

I'm less sure about hidden traits in public types (e.g., RawFloat and f64) but if it's overridable it also seems sensible.
Putting my real-world-concerns hat on, I think this is really just a corner case where and “public” don't coincide. The Right Thing is to propagate from traits to s of those traits; I don't know how difficult that is to do, so I opted for recommending a simple fix which I'd confirmed to work.
Change:
--> $DIR/feature-gate-negate-unsigned.rs:10:23 | LL |     let _max: usize = -1; <del> |                       ^^ cannot apply unary operator `-` </del> <ins> |                       ^^ |                       | |                       cannot apply unary operator `-` |                       help: you may have meant the maximum value of `usize`: `usize::MAX` </ins> | = note: unsigned values cannot be negated

Discussion:
Code: Playground: Error message: Somehow, in one case this in the expression is unsigned, but in the other case it is signed and everything is fine. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
For the compiler has to suggest to replace it with . The compiler should also suggest to replace with , to remove some hard "as" casts from the code.
claim
I think this is more appropriate as a clippy lint, opened
Change:
match label { Some((true, err_help_span, suggested_code)) => { <del> err.span_suggestion( err_help_span, &format!( "consider changing this to be a mutable {}", pointer_desc ), suggested_code, Applicability::MachineApplicable, ); </del> <ins> let (is_trait_sig, local_trait) = self.is_error_in_trait(local); if !is_trait_sig { err.span_suggestion( err_help_span, &format!( "consider changing this to be a mutable {}", pointer_desc ), suggested_code, Applicability::MachineApplicable, ); } else if let Some(x) = local_trait { err.span_suggestion( x, &format!( "consider changing that to be a mutable {}", pointer_desc ), suggested_code, Applicability::MachineApplicable, ); } </ins> } Some((false, err_label_span, message)) => { err.span_label(err_label_span, &message);

Discussion:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///
Change:
let Some(dbg_var) = var.dbg_var else { continue }; let Some(dbg_loc) = self.dbg_loc(var.source_info) else { continue }; <del> let mut direct_offset = Size::ZERO; // FIXME(eddyb) use smallvec here. let mut indirect_offsets = vec![]; let mut place = base; for elem in &var.projection[..] { match *elem { mir::ProjectionElem::Deref => { indirect_offsets.push(Size::ZERO); place = bx.load_operand(place).deref(bx.cx()); } mir::ProjectionElem::Field(field, _) => { let i = field.index(); let offset = indirect_offsets.last_mut().unwrap_or(&mut direct_offset); *offset += place.layout.fields.offset(i); place = place.project_field(bx, i); } mir::ProjectionElem::Downcast(_, variant) => { place = place.project_downcast(bx, variant); } _ => span_bug!( var.source_info.span, "unsupported var debuginfo place `{:?}`", mir::Place { local, projection: var.projection }, ), } } </del> <ins> let DebugInfoOffset { direct_offset, indirect_offsets, result: _ } = calculate_debuginfo_offset(bx, local, &var, base.layout); </ins> // When targeting MSVC, create extra allocas for arguments instead of pointing multiple // dbg_var_addr() calls into the same alloca with offsets. MSVC uses CodeView records

Discussion:
When generating a variable debuginfo, rustc emits an expression describing the address of a source variable. Since , rustc also evaluates this expression. The expression can contain indirections, and it is not always valid to evaluate it. Consider a source variable that is described indirectly in terms of a base local. The source variable will be introduced at the beginning of a function, but at this point the base local might be uninitialized. For example: Note that has and metadata but loaded value is uninitialized. (This leads to end-to-end miscompilation with -Cdebuginfo=2). cc
A variant that demonstrates complete end-to-end miscompilation can be found in
Even without the metadata, this load could violate constraints. So just removing the metadata is not a proper fix. EDIT: Or does this always load from an that doesn't have any other pointers to it yet? Then it should be fine in terms of aliasing.
Change:
<ins> error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types --> $DIR/infer-return-ty-for-fn-sig-issue-125488.rs:8:24 | LL |     fn f1(s: S<'_>) -> _ { |                        ^ |                        | |                        not allowed in type signatures |                        help: replace with the correct return type: `S<'_>` error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types --> $DIR/infer-return-ty-for-fn-sig-issue-125488.rs:13:24 | LL |     fn f2(s: S<'_>) -> _ { |                        ^ |                        | |                        not allowed in type signatures |                        help: replace with the correct return type: `S<'_>` error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types --> $DIR/infer-return-ty-for-fn-sig-issue-125488.rs:23:24 | LL |     fn f3(s: S<'_>) -> _ { |                        ^ |                        | |                        not allowed in type signatures |                        help: replace with the correct return type: `S<'_>` error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types --> $DIR/infer-return-ty-for-fn-sig-issue-125488.rs:28:24 | LL |     fn f4(s: S<'_>) -> _ { |                        ^ |                        | |                        not allowed in type signatures |                        help: replace with the correct return type: `S<'_>` error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0121`. </ins>

Discussion:
The code Emits this diagnostic, which is wrong in this case. It should say cc: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Cannot reproduce: the code snippet as given produces on stable 1.78.0
Did you mean to write this code snippet instead?
Ooops yes :sweat_smile:, edited
claim
Change:
// when the unstable no_sync feature is turned on. // See https://github.com/rust-lang/rust/pull/84266 <del> use run_make_support::rustc; </del> <ins> use run_make_support::{rustc, source_root}; </ins> fn main() { rustc() .edition("2021") .arg("-Dwarnings") .crate_type("rlib") <del> .input("../../../library/alloc/src/lib.rs") </del> <ins> .input(source_root().join("library/alloc/src/lib.rs")) </ins> .cfg("no_sync") .run(); }

Discussion:
Some run-make tests refer to stdlib sources with which seems not ideal. suggested that we should introduce a helper to make this less fragile.
There is already the env var set by compiletest for the source root.
I'm actually dumb, we even already have in the support library:
That's a very descriptive environment variable name, lol