jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: `Bar` is forbidden as the type of a const generic parameter --> $DIR/const_generic_type.rs:7:24 | LL | async fn test<const N: crate::Bar>() { |                        ^^^^^^^^^^ | = note: the only supported types are integers, `bool` and `char` error: aborting due to 1 previous error </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. --(hand-reduced) <details<summary<strong(original)</strong</summary<p</p</details<!-- 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. --: Command: option is to avoid error message (there exists another error at the end of the backtrace) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details- ICE location: Might be related to unsolved ICE Issue- (issue fixed by adding test-case), where the issue points to
Change:
let expected_values = check_cfg .expecteds .entry(ident.name.to_string()) <ins> .and_modify(|expected_values| match expected_values { ExpectedValues::Some(_) => {} ExpectedValues::Any => { // handle the case where names(...) was done // before values by changing to a list *expected_values = ExpectedValues::Some(FxHashSet::default()); } }) </ins> .or_insert_with(|| { ExpectedValues::Some(FxHashSet::default()) }); let ExpectedValues::Some(expected_values) = expected_values else { <del> bug!("shoudn't be possible") </del> <ins> bug!("`expected_values` should be a list a values") </ins> }; for val in values {

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. --Run It works if the order of and is swapped. (e.i., ) <!-- 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. --: The backtrace points to in cc label +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Sorry about that. Will fix it. claim
Change:
}) } <ins> fn emit_newtype_suggestion_for_raw_ptr( full_impl_span: Span, self_ty: Ty<'_>, self_ty_span: Span, ptr_ty: &ty::TypeAndMut<'_>, diag: &mut Diagnostic, ) { if !self_ty.needs_subst() { let mut_key = if ptr_ty.mutbl == rustc_middle::mir::Mutability::Mut { "mut " } else { "" }; let msg_sugg = "consider introducing a new wrapper type".to_owned(); let sugg = vec![ ( full_impl_span.shrink_to_lo(), format!("struct WrapperType(*{}{});nn", mut_key, ptr_ty.ty), ), (self_ty_span, "WrapperType".to_owned()), ]; diag.multipart_suggestion(msg_sugg, sugg, rustc_errors::Applicability::MaybeIncorrect); } } </ins> /// Lint impls of auto traits if they are likely to have /// unsound or surprising effects on auto impls. fn lint_auto_trait_impl<'tcx>(

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This could use some work, too, I think. Maybe "impl mentions type from outside the current crate" might be a sufficient replacement, though we should probably make sure that wording is compatible with current coherence rules. Though, in this case, for a non- self type like , we could then replace that^ message with something even more specific. I'm a bit skeptical of mentioning "try implementing on " when we have , since implementing something for and can have very different meanings depending on the signatures inside the trait.
Let's improve this case! claim
This was actually closer to my original error I got, it uses a type alias to create some extra confusion:
Amazing example :) thanks, I'm on it
This is a reproducible example without serde!
Change:
html_favicon_url = "http://www.rust-lang.org/favicon.ico", html_root_url = "http://static.rust-lang.org/doc/master")]; <del> #[feature(macro_rules, globs, asm, managed_boxes, thread_local, link_args)]; </del> <ins> #[feature(macro_rules, globs, asm, managed_boxes, thread_local, link_args, simd)]; </ins> // Don't link to std. We are std. #[no_std]; #[deny(non_camel_case_types)]; #[deny(missing_doc)]; <ins> #[allow(unknown_features)]; </ins> // When testing libstd, bring in libuv as the I/O backend so tests can print // things and all of the std::io tests have an I/O interface to run on top

Discussion:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this
Change:
<ins> fn L(]{match (; {` //~^^ ERROR mismatched closing delimiter //~^^ ERROR unknown start of token //~ ERROR this file contains an unclosed delimiter </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. --code is from clippy: :warning: you need rustc build with debug assertions :warning: <!-- 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
Run into this while fuzzing, here is a minimized test case: Note that you need rustc with debug assertions enabled. Reproduced in nightly 2022-02-25.
Another test case:
OP and seem to be fixed on latest master (). now outputs "Span must not be empty and have no suggestion" <details<summarybacktrace</summary</details
I can confirm that both of my examples have been fixed on latest master () so this issue can be closed.
Change:
<ins> error[E0308]: mismatched method receiver --> $DIR/issue-27522.rs:16:22 | 16 |     fn handler(self: &SomeType); |                      ^^^^^^^^^ expected Self, found struct `SomeType` | = note: expected type `&Self` = note:    found type `&SomeType` error: aborting due to previous error </ins>

Discussion:
The high end of the span of in is incorrectly set to .
It's seems to be caused by this `hack': (Called here: ) Weirdly enough, the proper span is shown for diagnostics: Any pointers,
Since works in s now, it's probably time to retire that hack and always provide the correct type. appears to hold the type (with its correct span), instead of the argument itself, in this case.
This has been fixed. Can this ticket be closed?
Change:
); probe.is_ok() }); <ins> self.note_internal_mutation_in_method( &mut err, rcvr_expr, expected.to_option(&self), rcvr_ty, ); </ins> } let mut custom_span_label = false;

Discussion:
In long method chains we might inadvertently call a method that is not meant to be chained. When this happens, the most likely error to occur is a type error involving . We should instead look if the rhs expression is a method chain and look at all the chained call's type to find where is introduced. Given Ideally the output would be closer to <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hi, I'd like to try working on this :) claim
Change:
<ins> // exact-check const QUERY = 'true'; const FILTER_CRATE = 'doc_alias_filter'; const EXPECTED = { 'others': [ { 'path': 'doc_alias_filter', 'name': 'Foo', 'alias': 'true', 'href': '../doc_alias_filter/struct.Foo.html', 'is_alias': true }, ], }; </ins>

Discussion:
I loaded the std doc at Firefox 77.0.1, then I typed fast for the word "true" (or click this link: ). I expected to see this happen: The search result appears and includes the "true" keyword link. Instead, this happened: No search result was shown. Also in the Firefox console, this was printed after typing the word "true": Version of std docs: 1.46.0-nightly ( 2020-06-21) cc in case you interest.
The type error happened along this line:
It looks like it fails when you have a crate filter selected. Almost certainly caused by (cc
yeah, that's right. I forgot about that detail.
should fix this.
Change:
<ins> error: lifetime parameter `'b` only used once --> $DIR/issue-117965.rs:9:16 | LL |     pub fn get<'b: 'a>(&'b self) -> &'a str { |                ^^       -- ...is used only here |                | |                this lifetime... | note: the lint level is defined here --> $DIR/issue-117965.rs:1:9 | LL | #![deny(single_use_lifetimes)] |         ^^^^^^^^^^^^^^^^^^^^ error: aborting due to 1 previous error </ins>

Discussion:
This code, as expected, triggers the lint. This is the compiler output: Applying the suggested change, we then get a lifetime error. In this specific instance, must also be changed to . That'll then trigger the lint on , with no ensuing issues. I have not checked this, but I my suspicion is any place where a lifetime bound is also present in the return type (or possibly even a parameter) will result in a similar failure to compile the suggested code. Figuring out which lifetimes to suggest removal of in other parts of the function signature probably isn't straightforward. This example is not theoretical, unfortunately. I ran into this in real-world code and it caused me quite a bit of time to figure out. The example is the minimal reproduction of the bad suggestion.
Should the lint even trigger for ? It's only "used" once directly, but it's also linked to another lifetime through the bound .
cc label +F-lint-singleuselifetimes
Change:
crate fn trait_did(&self) -> Option<DefId> { self.inner_impl().trait_.as_ref().map(|t| t.def_id()) } <ins> /// This function is used to extract a `DefId` to be used as a key for the `Cache::impls` field. /// /// It allows to prevent having duplicated implementations showing up (the biggest issue was /// with blanket impls). /// /// It panics if `self` is a `ItemId::Primitive`. crate fn def_id(&self) -> DefId { match self.impl_item.item_id { ItemId::Blanket { impl_id, .. } => impl_id, ItemId::Auto { trait_, .. } => trait_, ItemId::DefId(def_id) => def_id, ItemId::Primitive(_, _) => { panic!( "Unexpected ItemId::Primitive in expect_def_id: {:?}", self.impl_item.item_id ) } } } </ins> }

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:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Regression test for #24085. Errors were occuring in region // inference due to the requirement that `'a:b'`, which was getting // incorrectly translated in connection with the closure below. #[derive(Copy,Clone)] struct Path<'a:'b, 'b> { x: &'a i32, tail: Option<&'b Path<'a, 'b>> } #[allow(dead_code, unconditional_recursion)] fn foo<'a,'b,F>(p: Path<'a, 'b>, mut f: F) where F: for<'c> FnMut(Path<'a, 'c>) { foo(p, |x| f(x)) } fn main() { } </ins>

Discussion:
Notably, this does not occur with a trait like: This smells like a bug to me, unless a language change introduced special treatment of with regard to lifetimes.
An interesting quirk is that if you replace with just , it compiles fine with the impl.
cc
are you saying this used to work? Just curious what the original was.
(Also it seems difficult if not impossible to satisfy the combination of and ..... well I guess of static would, but I don't know if we can deduce that.
Yes, this used to work. This bug is affecting
It looks like this may have been introduced in . Prior to this, checking for bounds in was done via , which creates a throw-away inference context before calling into trait selection. It now goes through the ; the impl of for uses its own inference context. This causes region constraints introduced during trait selection for to stick around, resulting in a seemingly inappropriate transitive constraint between the free region within the closure body and at the call site of .
hmm good catch, sorry I let this slip through last week :( I'll try to pay it some attention now. The current code does not seem entirely wrong to me, though. I have to think this through a bit.
Change:
#[stable(feature = "future_readiness_fns", since = "1.48.0")] pub use ready::{ready, Ready}; <del> #[unstable(feature = "future_poll_fn", issue = "72302")] </del> <ins> #[stable(feature = "future_poll_fn", since = "1.64.0")] </ins> pub use poll_fn::{poll_fn, PollFn}; /// This type is needed because:

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --The feature gate for the issue is . <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR () [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --- Should this be named instead? <!-- Include a list of all the PRs that were involved in implementing the feature. --- Initial implementation in - closed as it's ambiguous, see the discussion on that PR
This exists in futures-lite, and people use it. It seems worth having available in the standard library. The naming discussion doesn't seem likely to change, and all else being equal there's a history for the name . Shall we stabilize this? merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [ ] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
There are some soundness issues with (not strictly speaking a soundness bug, but we might still want to do a breaking change now before there are too many people relying on this): the fact that is always is a problem. It should require for that. See for details, in particular .
I am proposing to change the impl in
Change:
# stable release's version number. `date` is the date where the release we're # bootstrapping off was released. <del> date: 2021-03-26 </del> <ins> date: 2021-04-07 </ins> rustc: beta # We use a nightly rustfmt to format the source because it solves some

Discussion:
I think it was working yesterday, but is giving a "Not Found" response for me. works fine, however.
Hm, I wonder if this is a similar bug to the one fixed due to link check failure during the bootstrap bump.
FYI, works fine—it seems to just be .
Yeah, almost certainly the bootstrap bump. cc (just a heads up, I plan to submit a patch soon, though haven't written it yet)
My guess without too much investigation is that the symlinkdirforce which intends to share the compiler-doc directory between rustdoc and rustc docs is ending up clobbered. I likely won't get around to a fix tonight but may be able to do so tomorrow, we'll see how much time I have.
I'm also happy to revert the change on beta, if you want, so there isn't a rush to fix things.
Yeah, I think we should do that - there's enough stuff broken in rustbuild that's not really of the too unusual kind (well, really just two cases, but they seem fairly typical). I'd rather we drop it from beta and either pursue resource-suffix as suggested by or at least tackle the bugs in rustbuild on a less urgent timescale before relanding. (Ideally we should figure out what people should do; rustbuild's approach to just building twice seems pretty... suboptimal; I imagine that the fix for this newly found bug will end up similar if I do it quickly).
OK, I have posted I'll push through the changes, though it may take at least a few days to get beta updated and then bump the version.
Yeah. I think I'm not sure there's as easy a fix in this case (unlike the simple add of a double core build), as the clobbering occurs over two different steps I believe. So I think we'll wait for that patch to land and bump beta. (We could also temporarily remove, say, rustdoc or rustc docs - but that doesn't seem like a real benefit).
Thanks for the speedy fix! The docs are back online now (because it's a bit after midnight UTC). I'm glad they're back :)
Change:
// Save the state of the parser before parsing type normally, in case there is a // LessThan comparison after this cast. let parser_snapshot_before_type = self.clone(); <del> match self.parse_ty_no_plus() { Ok(rhs) => Ok(mk_expr(self, rhs)), </del> <ins> let cast_expr = match self.parse_ty_no_plus() { Ok(rhs) => mk_expr(self, rhs), </ins> Err(mut type_err) => { // Rewind to before attempting to parse the type with generics, to recover // from situations like `x as usize < y` in which we first tried to parse

Discussion:
Summary: Parsing leads to the error: It is currently impossible for a cast expression to have a trailing index expression without surrounding the cast expression by parenthesis. This however seems to be a parser limitation, not a grammar limitation. As currently the macro language guarantees that ty/path expressions can be followed by a "[", this seems like a bug in the parser to me, as it seems to be parsing it as which makes no grammatical sense, compared to parsing it as (value as Type)[index] which should be valid if I read the lexical structure specification correctly.
I think it's parsed correctly, but should get a tailored error message to suggest surrounding the cast with parens.
Considering that a trailing "[" is never valid in the type syntax (otherwise macros break) and the fact that and variants are perfectly legal (even which is another symbol that occurs in type syntax). But if a tailored error message will be made instead, then this should also include other postfix operators like which are currently rejected even though technically being legal by the lexical grammar specification. (another one is the proposed "?" operator)
This is still lacking a tailored error message, and as far as I know no movement has been made here.
Submitted a pull request to fix this!
Thanks!
Change:
--legacy-manifest-dirs=rustlib,cargo $$(Q)rm -R tmp/dist/$$(PKG_NAME)-$(1)-image <del> dist-doc-install-dir-$(1): docs compiler-docs </del> <ins> dist-doc-install-dir-$(1): docs </ins> $$(Q)mkdir -p tmp/dist/$$(DOC_PKG_NAME)-$(1)-image/share/doc/rust $$(Q)cp -r doc tmp/dist/$$(DOC_PKG_NAME)-$(1)-image/share/doc/rust/html

Discussion:
I got the message above,how to fix it?
Urgh. This should never have gotten through the CI bots. Some rules must be being built by the install target that aren't under the normal build.
I will try to look into this today while I'm investigating other nightly breakage.
I assume this is being introduced by the doc comment I wrote here: So the two bugs here are: the above doc comment in dropck. (Presumably just replace the indents with nested bullets.) rules do we need to change to synchronize with the CI bots (to catch this kind of case in the future) -- presumably its happening because attempts to build documentation for rust itself ... which sounds a lot like good old: ; see also
I posted a PR to stop building compiler docs. It does not fix the bug in the docs though.
Fixed.
Er, oh yeah, the underlying problem is not fixed, that the docs have broken examples.
Sigh, actually, I'll call this fixed since the title of the bug is about install failure and that works now. Broken examples in the rustc crate are nbd to me atm.

Just downloaded a fresh install from git and ran on a virgin arch linux box running on AWS and getting this error again cfg: using CC=gcc (CFGCC) cfg: disabling valgrind run-pass tests cfg: including prepare rules cfg: including dist rules cfg: including install rules cleaning destination tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/bin prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/lib prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/lib/rustlib/etc prepare: tmp/dist/rustc-1.5.0-dev-x8664-unknown-linux-gnu-image/share/man/man1 rustc: x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-gnu/lib/librustc recipe for target 'x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-' failed make[1]:  [x8664-unknown-linux-gnu/stage0/lib/rustlib/x8664-unknown-linux-] Killed make[1]: Leaving directory '/root/Downloads/rust' recipe for target 'install' failed make:  [install] Error 2 any ideas
Change:
}) } <del> let minimum_input_count = formal_input_tys.len(); </del> for (idx, arg) in provided_args.iter().enumerate() { // Warn only for the first loop (the "no closures" one). // Closure arguments themselves can't be diverging, but

Discussion:
If using format inside a closure (e.g. in iter functions) and the returning String is passed into a function that takes less args, rustc panics. Minimized code snippet: version: 1.60.0-beta.2 and 1.61.0-nightly query: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
playground link:
Probably duplicate of
Actually, not sure if it's a duplicate of . Still failing on master after the fix for that one landed, and failed with the same error (and not a duplicated adjustment bug) on beta. I will look into it! claim
Minimized: