Question: use super::*; <ins> use rustc_span::source_map::DUMMY_SP; fn create_doc_fragment(s: &str) -> Vec<DocFragment> { vec![DocFragment { line: 0, span: DUMMY_SP, parent_module: None, doc: s.to_string(), kind: DocFragmentKind::SugaredDoc, }] } #[track_caller] fn run_test(input: &str, expected: &str) { let mut s = create_doc_fragment(input); unindent_fragments(&mut s); assert_eq!(s[0].doc, expected); } </ins> #[test] fn should_unindent() { <del> let s = "    line1n    line2".to_string(); let r = unindent(&s); assert_eq!(r, "line1nline2"); </del> <ins> run_test("    line1n    line2", "line1nline2"); </ins> } #[test] fn should_unindent_multiple_paragraphs() { <del> let s = "    line1nn    line2".to_string(); let r = unindent(&s); assert_eq!(r, "line1nnline2"); </del> <ins> run_test("    line1nn    line2", "line1nnline2"); </ins> } #[test] fn should_leave_multiple_indent_levels() { // Line 2 is indented another level beyond the // base indentation and should be preserved <del> let s = "    line1nn        line2".to_string(); let r = unindent(&s); assert_eq!(r, "line1nn    line2"); </del> <ins> run_test("    line1nn        line2", "line1nn    line2"); </ins> } #[test] fn should_ignore_first_line_indent() { <del> // The first line of the first paragraph may not be indented as // far due to the way the doc string was written: // // #[doc = "Start way over here //          and continue here"] let s = "line1n    line2".to_string(); let r = unindent(&s); assert_eq!(r, "line1nline2"); </del> <ins> run_test("line1n    line2", "line1n    line2"); </ins> } #[test] fn should_not_ignore_first_line_indent_in_a_single_line_para() { <del> let s = "line1nn    line2".to_string(); let r = unindent(&s); assert_eq!(r, "line1nn    line2"); </del> <ins> run_test("line1nn    line2", "line1nn    line2"); </ins> } #[test] fn should_unindent_tabs() { <del> let s = "tline1ntline2".to_string(); let r = unindent(&s); assert_eq!(r, "line1nline2"); </del> <ins> run_test("tline1ntline2", "line1nline2"); </ins> } #[test] fn should_trim_mixed_indentation() { <del> let s = "t    line1nt    line2".to_string(); let r = unindent(&s); assert_eq!(r, "line1nline2"); let s = "    tline1n    tline2".to_string(); let r = unindent(&s); assert_eq!(r, "line1nline2"); </del> <ins> run_test("t    line1nt    line2", "line1nline2"); run_test("    tline1n    tline2", "line1nline2"); </ins> } #[test] fn should_not_trim() { <del> let s = "t    line1  nt    line2".to_string(); let r = unindent(&s); assert_eq!(r, "line1  nline2"); let s = "    tline1  n    tline2".to_string(); let r = unindent(&s); assert_eq!(r, "line1  nline2"); </del> <ins> run_test("t    line1  nt    line2", "line1  nline2"); run_test("    tline1  n    tline2", "line1  nline2"); </ins> }

(x, "n bar();n"); //!
They are not supposed to be applied to a doc comment I do not think that. Your example would make sense for which I also consider to be wrong, but I am talking about which should insert the attribute conditionally but that is not the point. It might help to illustrate my thought process; We have some kind of documented item: rust /// let example = Example::new() /// .first() /// .build(); /// and each of those is turned into a doc attribute rust"] #[doc = "let example = Example::new()"] #[doc = " .first()"] #[doc = " .build();"] #[doc = " In a later step those attributes would then be concatenated and parsed as markdown or whatever. I want to use this behavior to document items conditionally, depending on which features the crate user has enabled. One way to do this would be to do rust let example = Example::new() .first() .build(); rust let example = Example::new() .first() .second() .build(); but that would blow up the source code with many duplicate lines, where only some minor things were changed. So I thought that it might make more sense to conditionally include a doc comment like this: rust /// let example = Example::new() /// .first() #[cfgattr(feature = "one", doc = " .second()")] /// .build(); /// which would turn into rust"] #[doc = "let example = Example::new()"] #[doc = " .first()"] #[doc = " .second()"] #[doc = " .build();"] #[doc = " or rust"] #[doc = "let example = Example::new()"] #[doc = " .first()"] #[doc = " .build();"] #[doc = " depending on whether the feature is enabled. So the attribute should not be inserted and not applied to the following doc comment. The weird thing is that the manually expanded version is working as expected. rust"] #[doc = "let example = Example::new()"] #[doc = " .first()"] #[cfg_attr(feature = "one", doc = " .second()")] #[doc = " .build();"] #[doc = " but this is very unhandy to work with :/
I was randomly looking at passes for another reason and noticed what is likely the source of this issue.


Question: use super::*; <ins> use rustc_span::source_map::DUMMY_SP; fn create_doc_fragment(s: &str) -> Vec<DocFragment> { vec![DocFragment { line: 0, span: DUMMY_SP, parent_module: None, doc: s.to_string(), kind: DocFragmentKind::SugaredDoc, }] } #[track_caller] fn run_test(input: &str, expected: &str) { let mut s = create_doc_fragment(input); unindent_fragments(&mut s); assert_eq!(s[0].doc, expected); } </ins> #[test] fn should_unindent() { <del> let s = "    line1n    line2".to_string(); let r = unindent(&s); assert_eq!(r, "line1nline2"); </del> <ins> run_test("    line1n    line2", "line1nline2"); </ins> } #[test] fn should_unindent_multiple_paragraphs() { <del> let s = "    line1nn    line2".to_string(); let r = unindent(&s); assert_eq!(r, "line1nnline2"); </del> <ins> run_test("    line1nn    line2", "line1nnline2"); </ins> } #[test] fn should_leave_multiple_indent_levels() { // Line 2 is indented another level beyond the // base indentation and should be preserved <del> let s = "    line1nn        line2".to_string(); let r = unindent(&s); assert_eq!(r, "line1nn    line2"); </del> <ins> run_test("    line1nn        line2", "line1nn    line2"); </ins> } #[test] fn should_ignore_first_line_indent() { <del> // The first line of the first paragraph may not be indented as // far due to the way the doc string was written: // // #[doc = "Start way over here //          and continue here"] let s = "line1n    line2".to_string(); let r = unindent(&s); assert_eq!(r, "line1nline2"); </del> <ins> run_test("line1n    line2", "line1n    line2"); </ins> } #[test] fn should_not_ignore_first_line_indent_in_a_single_line_para() { <del> let s = "line1nn    line2".to_string(); let r = unindent(&s); assert_eq!(r, "line1nn    line2"); </del> <ins> run_test("line1nn    line2", "line1nn    line2"); </ins> } #[test] fn should_unindent_tabs() { <del> let s = "tline1ntline2".to_string(); let r = unindent(&s); assert_eq!(r, "line1nline2"); </del> <ins> run_test("tline1ntline2", "line1nline2"); </ins> } #[test] fn should_trim_mixed_indentation() { <del> let s = "t    line1nt    line2".to_string(); let r = unindent(&s); assert_eq!(r, "line1nline2"); let s = "    tline1n    tline2".to_string(); let r = unindent(&s); assert_eq!(r, "line1nline2"); </del> <ins> run_test("t    line1nt    line2", "line1nline2"); run_test("    tline1n    tline2", "line1nline2"); </ins> } #[test] fn should_not_trim() { <del> let s = "t    line1  nt    line2".to_string(); let r = unindent(&s); assert_eq!(r, "line1  nline2"); let s = "    tline1  n    tline2".to_string(); let r = unindent(&s); assert_eq!(r, "line1  nline2"); </del> <ins> run_test("t    line1  nt    line2", "line1  nline2"); run_test("    tline1  n    tline2", "line1  nline2"); </ins> }

There are two relevant passes: runs second and removes leading columns of whitespace from the docs. This runs on a single "doc fragment" at a time, because of merging that normally means the entire documentation string, but since sugared and raw docs aren't merged they remain as separate fragments and use their own widths of leading whitespace to strip.
That also matches up with first released in 1.24 which introduced this distinction between doc kinds in order to fix , which IMO was user error in not matching the indent depth.


Question: <ins> error[E0261]: use of undeclared lifetime name `'missing` --> $DIR/missing-lt-outlives-in-rpitit-114274.rs:8:55 | LL |     fn iter(&self) -> impl Iterator<Item = Self::Item<'missing>>; |                                                       ^^^^^^^^ undeclared lifetime | = note: for more information on higher-ranked polymorphism, visit https://doc.rust-lang.org/nomicon/hrtb.html help: consider making the bound lifetime-generic with a new `'missing` lifetime | LL |     fn iter(&self) -> impl for<'missing> Iterator<Item = Self::Item<'missing>>; |                            +++++++++++++ help: consider introducing lifetime `'missing` here | LL |     fn iter<'missing>(&self) -> impl Iterator<Item = Self::Item<'missing>>; |            ++++++++++ help: consider introducing lifetime `'missing` here | LL | trait Iterable<'missing> { |               ++++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0261`. </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details


Question: | PathSource::Struct | PathSource::TupleStruct(..) => false, }; <del> let mut error = false; </del> <ins> let mut res = LifetimeRes::Error; </ins> for rib in self.lifetime_ribs.iter().rev() { match rib.kind { // In create-parameter mode we error here because we don't want to support

I tried this code: I expected to see this happen: it compile Instead, this happened: it didnt It most recently worked on Rust 1.60 and this nighty: : searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29 regressed nightly: nightly-2022-04-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Slightly simplified reproduction: In other words, this isn't specific to .
Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested , but that appears not to have been correct.


Question: let lo = self.token.span; if !self.eat(&token::OpenDelim(token::Brace)) { <del> let sp = self.token.span; let tok = self.this_token_descr(); let mut e = self.span_fatal(sp, &format!("expected `{{`, found {}", tok)); let do_not_suggest_help = self.token.is_keyword(kw::In) || self.token == token::Colon; if self.token.is_ident_named(sym::and) { e.span_suggestion_short( self.token.span, "use `&&` instead of `and` for the boolean operator", "&&".to_string(), Applicability::MaybeIncorrect, ); } if self.token.is_ident_named(sym::or) { e.span_suggestion_short( self.token.span, "use `||` instead of `or` for the boolean operator", "||".to_string(), Applicability::MaybeIncorrect, ); } </del> <ins> return self.error_block_no_opening_brace(); } </ins> <del> // Check to see if the user has written something like // //    if (cond) //      bar; // // which is valid in other languages, but not Rust. match self.parse_stmt_without_recovery(false) { Ok(Some(stmt)) => { if self.look_ahead(1, |t| t == &token::OpenDelim(token::Brace)) || do_not_suggest_help { // If the next token is an open brace (e.g., `if a b {`), the place- // inside-a-block suggestion would be more likely wrong than right. e.span_label(sp, "expected `{`"); return Err(e); } let mut stmt_span = stmt.span; // Expand the span to include the semicolon, if it exists. if self.eat(&token::Semi) { stmt_span = stmt_span.with_hi(self.prev_span.hi()); } if let Ok(snippet) = self.span_to_snippet(stmt_span) { e.span_suggestion( stmt_span, "try placing this code inside a block", format!("{{ {} }}", snippet), // Speculative; has been misleading in the past (#46836). Applicability::MaybeIncorrect, ); } </del> <ins> self.parse_block_tail(lo, BlockCheckMode::Default) } fn error_block_no_opening_brace<T>(&mut self) -> PResult<'a, T> { let sp = self.token.span; let tok = self.this_token_descr(); let mut e = self.span_fatal(sp, &format!("expected `{{`, found {}", tok)); let do_not_suggest_help = self.token.is_keyword(kw::In) || self.token == token::Colon; if self.token.is_ident_named(sym::and) { e.span_suggestion_short( self.token.span, "use `&&` instead of `and` for the boolean operator", "&&".to_string(), Applicability::MaybeIncorrect, ); } if self.token.is_ident_named(sym::or) { e.span_suggestion_short( self.token.span, "use `||` instead of `or` for the boolean operator", "||".to_string(), Applicability::MaybeIncorrect, ); } // Check to see if the user has written something like // //    if (cond) //      bar; // // which is valid in other languages, but not Rust. match self.parse_stmt_without_recovery(false) { Ok(Some(stmt)) => { if self.look_ahead(1, |t| t == &token::OpenDelim(token::Brace)) || do_not_suggest_help { // If the next token is an open brace (e.g., `if a b {`), the place- // inside-a-block suggestion would be more likely wrong than right. e.span_label(sp, "expected `{`"); return Err(e); </ins> } <del> Err(mut e) => { self.recover_stmt_(SemiColonMode::Break, BlockMode::Ignore); e.cancel(); </del> <ins> let stmt_span = if self.eat(&token::Semi) { // Expand the span to include the semicolon. stmt.span.with_hi(self.prev_span.hi()) } else { stmt.span }; if let Ok(snippet) = self.span_to_snippet(stmt_span) { e.span_suggestion( stmt_span, "try placing this code inside a block", format!("{{ {} }}", snippet), // Speculative; has been misleading in the past (#46836). Applicability::MaybeIncorrect, ); </ins> } <del> _ => () </del> } <del> e.span_label(sp, "expected `{`"); return Err(e); </del> <ins> Err(mut e) => { self.recover_stmt_(SemiColonMode::Break, BlockMode::Ignore); e.cancel(); } _ => {} </ins> } <del> self.parse_block_tail(lo, BlockCheckMode::Default) </del> <ins> e.span_label(sp, "expected `{`"); return Err(e); </ins> } /// Parses a block. Inner attributes are allowed.

The idea of shortening to has been discussed many times before, and the general consensus always ends up being that it is not a good idea. I would like to propose something a bit different, so please hear me out. I propose that instead of aliasing to , we instead just make expand into when in the context of a variable declaration. For example: This solves the problems (readability, more concise) that people have with , whilst not causing the issues that people have (pattern matching and consistancy). The most common issue people have with aliasing to is that it doesn't fit well with patterns, like . However, gets rid of this problem, because you wouldn't write if you were trying to pattern match, so why would someone want to write ? You wouldn't do that, and it wouldn't compile. This would be optional, of course. would still work fine, and people would just have to option of removing the to let it be implied. There are a lot of other abbreviations used in rust (, , ) that all serve the purpose of writing less. It just doesn't feel right that one of the most commonly used keywords is so long. :heart::crab: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Rust wants to make to make you think when you try and use mutation, even if only a little bit, because mutation can be difficult to reason about. Shortening to doesn't fit this philosophy. Also, this makes mutation just as easy as no mutation. This will lead people to choose mutation because it will give them less compiler errors in the short term, and in doing so open themselves up to some weird bugs that could have been prevented with the syntactic salt that is . tldr: wasn't rejected because of the name , but because it allowed easy mutation, which runs counter to Rust's philosophy.
I politely disagree. In fact, it is actually the other way around. Using unnecessarily will cause compiler warnings, discouraging the use of unneeded mutability. The compiler doesn't warn when the use of is actually needed.
The fact that people will choose in the face of compiler warnings has been shown in practice, across many projects.


Question: let lo = self.token.span; if !self.eat(&token::OpenDelim(token::Brace)) { <del> let sp = self.token.span; let tok = self.this_token_descr(); let mut e = self.span_fatal(sp, &format!("expected `{{`, found {}", tok)); let do_not_suggest_help = self.token.is_keyword(kw::In) || self.token == token::Colon; if self.token.is_ident_named(sym::and) { e.span_suggestion_short( self.token.span, "use `&&` instead of `and` for the boolean operator", "&&".to_string(), Applicability::MaybeIncorrect, ); } if self.token.is_ident_named(sym::or) { e.span_suggestion_short( self.token.span, "use `||` instead of `or` for the boolean operator", "||".to_string(), Applicability::MaybeIncorrect, ); } </del> <ins> return self.error_block_no_opening_brace(); } </ins> <del> // Check to see if the user has written something like // //    if (cond) //      bar; // // which is valid in other languages, but not Rust. match self.parse_stmt_without_recovery(false) { Ok(Some(stmt)) => { if self.look_ahead(1, |t| t == &token::OpenDelim(token::Brace)) || do_not_suggest_help { // If the next token is an open brace (e.g., `if a b {`), the place- // inside-a-block suggestion would be more likely wrong than right. e.span_label(sp, "expected `{`"); return Err(e); } let mut stmt_span = stmt.span; // Expand the span to include the semicolon, if it exists. if self.eat(&token::Semi) { stmt_span = stmt_span.with_hi(self.prev_span.hi()); } if let Ok(snippet) = self.span_to_snippet(stmt_span) { e.span_suggestion( stmt_span, "try placing this code inside a block", format!("{{ {} }}", snippet), // Speculative; has been misleading in the past (#46836). Applicability::MaybeIncorrect, ); } </del> <ins> self.parse_block_tail(lo, BlockCheckMode::Default) } fn error_block_no_opening_brace<T>(&mut self) -> PResult<'a, T> { let sp = self.token.span; let tok = self.this_token_descr(); let mut e = self.span_fatal(sp, &format!("expected `{{`, found {}", tok)); let do_not_suggest_help = self.token.is_keyword(kw::In) || self.token == token::Colon; if self.token.is_ident_named(sym::and) { e.span_suggestion_short( self.token.span, "use `&&` instead of `and` for the boolean operator", "&&".to_string(), Applicability::MaybeIncorrect, ); } if self.token.is_ident_named(sym::or) { e.span_suggestion_short( self.token.span, "use `||` instead of `or` for the boolean operator", "||".to_string(), Applicability::MaybeIncorrect, ); } // Check to see if the user has written something like // //    if (cond) //      bar; // // which is valid in other languages, but not Rust. match self.parse_stmt_without_recovery(false) { Ok(Some(stmt)) => { if self.look_ahead(1, |t| t == &token::OpenDelim(token::Brace)) || do_not_suggest_help { // If the next token is an open brace (e.g., `if a b {`), the place- // inside-a-block suggestion would be more likely wrong than right. e.span_label(sp, "expected `{`"); return Err(e); </ins> } <del> Err(mut e) => { self.recover_stmt_(SemiColonMode::Break, BlockMode::Ignore); e.cancel(); </del> <ins> let stmt_span = if self.eat(&token::Semi) { // Expand the span to include the semicolon. stmt.span.with_hi(self.prev_span.hi()) } else { stmt.span }; if let Ok(snippet) = self.span_to_snippet(stmt_span) { e.span_suggestion( stmt_span, "try placing this code inside a block", format!("{{ {} }}", snippet), // Speculative; has been misleading in the past (#46836). Applicability::MaybeIncorrect, ); </ins> } <del> _ => () </del> } <del> e.span_label(sp, "expected `{`"); return Err(e); </del> <ins> Err(mut e) => { self.recover_stmt_(SemiColonMode::Break, BlockMode::Ignore); e.cancel(); } _ => {} </ins> } <del> self.parse_block_tail(lo, BlockCheckMode::Default) </del> <ins> e.span_label(sp, "expected `{`"); return Err(e); </ins> } /// Parses a block. Inner attributes are allowed.

Also, the problem isn't that people may choose to put just for the heck of it, but that they will unintentionally mutate something that was supposed to be immutable. And because it is being mutated, there is no warning, and they used because it is their default, it is their default because it gets rid of compiler errors that say they were trying to mutate things that are immutable even though they weren't supposed to mutate them in the first place. They will use because it is just as easy as making it immutable. So the problem is a bit more subtle than you seem to think.
Incorrect. Extreme brevity harms readability. See Perl. lol Readers would ignore the vs distinction far more often that vs , partially due to length difference, but works even better than say . It's true boilerplate often harms readability, but boilerplate requires some complexity be repeated, not merely the in . It harms readability even further if also works for , especially when you consider code readers need not actually know Rust. Rust syntax was designed largely to reduce cognitive load, not to reduce typing. We use , , and , not any shorter alternatives. And delegation RFCs have kinda given up the short syntaxes. I think Rust's omission of is now considered a mistake, but presumably helps C programmers. Rust has short keywords only really for fundamental "items" used repeatedly by basically every module. It's similar cognitive load if you write , , or , but actually just writing the shorter bare increases cognitive load. I think invokes the minor linguistic subtlety that variable means mutable binding, while acts like a common term for binding, which makes very slightly clearer.
The statement would be orthogonal to the current language in some sense though. is not a special syntax, but is composed of statement + pattern. It is in line with other places expects a pattern, where you can write , , or .
It seems unlikely to me that we would support as a short-hand. I'm personally opposed to it both because it adds unnecessary compiler complexity, stylistic schisms, and for the reasons outlined by However, I've taken the liberty of reusing this issue towards improved diagnostics: The idea here is to check . The idea here is to check: The relevant code is here: cc
claim
Error: Parsing assign command in failed: claim :)... Please let know if you're having trouble with this bot.


Question: let lo = self.token.span; if !self.eat(&token::OpenDelim(token::Brace)) { <del> let sp = self.token.span; let tok = self.this_token_descr(); let mut e = self.span_fatal(sp, &format!("expected `{{`, found {}", tok)); let do_not_suggest_help = self.token.is_keyword(kw::In) || self.token == token::Colon; if self.token.is_ident_named(sym::and) { e.span_suggestion_short( self.token.span, "use `&&` instead of `and` for the boolean operator", "&&".to_string(), Applicability::MaybeIncorrect, ); } if self.token.is_ident_named(sym::or) { e.span_suggestion_short( self.token.span, "use `||` instead of `or` for the boolean operator", "||".to_string(), Applicability::MaybeIncorrect, ); } </del> <ins> return self.error_block_no_opening_brace(); } </ins> <del> // Check to see if the user has written something like // //    if (cond) //      bar; // // which is valid in other languages, but not Rust. match self.parse_stmt_without_recovery(false) { Ok(Some(stmt)) => { if self.look_ahead(1, |t| t == &token::OpenDelim(token::Brace)) || do_not_suggest_help { // If the next token is an open brace (e.g., `if a b {`), the place- // inside-a-block suggestion would be more likely wrong than right. e.span_label(sp, "expected `{`"); return Err(e); } let mut stmt_span = stmt.span; // Expand the span to include the semicolon, if it exists. if self.eat(&token::Semi) { stmt_span = stmt_span.with_hi(self.prev_span.hi()); } if let Ok(snippet) = self.span_to_snippet(stmt_span) { e.span_suggestion( stmt_span, "try placing this code inside a block", format!("{{ {} }}", snippet), // Speculative; has been misleading in the past (#46836). Applicability::MaybeIncorrect, ); } </del> <ins> self.parse_block_tail(lo, BlockCheckMode::Default) } fn error_block_no_opening_brace<T>(&mut self) -> PResult<'a, T> { let sp = self.token.span; let tok = self.this_token_descr(); let mut e = self.span_fatal(sp, &format!("expected `{{`, found {}", tok)); let do_not_suggest_help = self.token.is_keyword(kw::In) || self.token == token::Colon; if self.token.is_ident_named(sym::and) { e.span_suggestion_short( self.token.span, "use `&&` instead of `and` for the boolean operator", "&&".to_string(), Applicability::MaybeIncorrect, ); } if self.token.is_ident_named(sym::or) { e.span_suggestion_short( self.token.span, "use `||` instead of `or` for the boolean operator", "||".to_string(), Applicability::MaybeIncorrect, ); } // Check to see if the user has written something like // //    if (cond) //      bar; // // which is valid in other languages, but not Rust. match self.parse_stmt_without_recovery(false) { Ok(Some(stmt)) => { if self.look_ahead(1, |t| t == &token::OpenDelim(token::Brace)) || do_not_suggest_help { // If the next token is an open brace (e.g., `if a b {`), the place- // inside-a-block suggestion would be more likely wrong than right. e.span_label(sp, "expected `{`"); return Err(e); </ins> } <del> Err(mut e) => { self.recover_stmt_(SemiColonMode::Break, BlockMode::Ignore); e.cancel(); </del> <ins> let stmt_span = if self.eat(&token::Semi) { // Expand the span to include the semicolon. stmt.span.with_hi(self.prev_span.hi()) } else { stmt.span }; if let Ok(snippet) = self.span_to_snippet(stmt_span) { e.span_suggestion( stmt_span, "try placing this code inside a block", format!("{{ {} }}", snippet), // Speculative; has been misleading in the past (#46836). Applicability::MaybeIncorrect, ); </ins> } <del> _ => () </del> } <del> e.span_label(sp, "expected `{`"); return Err(e); </del> <ins> Err(mut e) => { self.recover_stmt_(SemiColonMode::Break, BlockMode::Ignore); e.cancel(); } _ => {} </ins> } <del> self.parse_block_tail(lo, BlockCheckMode::Default) </del> <ins> e.span_label(sp, "expected `{`"); return Err(e); </ins> } /// Parses a block. Inner attributes are allowed.

Although I would also guess that the initial idea is very unlikely to end up accepted, it feels premature to unilaterally hijack the thread in your very first comment and make it have a different (and in a way opposite) purpose. Teams of the Rust project are designed to make decisions collectively. Improving diagnostics sounds good, but issue numbers are cheap.
Implementing something as a diagnostic actually brings you closer to a working implementation -- I think more proposals should start out as diagnostics. I will not bother the other language team members with not-fully-formed proposals that we will not accept in either case. I converted the issue into the most actionable and productive thing it could be. The place for ephemeral discussions is either on Discord or on internals. If you want to discuss this further, I'm available at Discord (but will not respond to it further here). wasting everyone's time with things that will go nowhere (because it won't be accepted and because it is not important enough to be raised at the team) is not.
IMHO, the original thing this issue was opened for should be an RFC, not an issue. I'd have closed this, pointed the OP to the RFCs repo, and opened a new issue for the diagnostic issue.
This issue was literally in the RFCs repo initially, transferred it from there.
Language bashing is not welcome here
Wait, so should I unassign here, and assign to the new issue?
Nah, just use this one.
Yeah, thats fine. You can just change this issue to be for diagnostics instead.
I'm sorry, I've been pretty busy with coursework, and I'm still fighting my Python installation to even build the compiler, let alone make progress on this. Sorry :(
I'll assign this to myself to work on when I have time. If you want to work on it however, feel free to work-steal it from me!
I would like to help with this
Sorry; should have updated this issue...! There's a PR at the moment. Feel free to leave suggestions on it if you like. :)


Question: let lo = self.token.span; if !self.eat(&token::OpenDelim(token::Brace)) { <del> let sp = self.token.span; let tok = self.this_token_descr(); let mut e = self.span_fatal(sp, &format!("expected `{{`, found {}", tok)); let do_not_suggest_help = self.token.is_keyword(kw::In) || self.token == token::Colon; if self.token.is_ident_named(sym::and) { e.span_suggestion_short( self.token.span, "use `&&` instead of `and` for the boolean operator", "&&".to_string(), Applicability::MaybeIncorrect, ); } if self.token.is_ident_named(sym::or) { e.span_suggestion_short( self.token.span, "use `||` instead of `or` for the boolean operator", "||".to_string(), Applicability::MaybeIncorrect, ); } </del> <ins> return self.error_block_no_opening_brace(); } </ins> <del> // Check to see if the user has written something like // //    if (cond) //      bar; // // which is valid in other languages, but not Rust. match self.parse_stmt_without_recovery(false) { Ok(Some(stmt)) => { if self.look_ahead(1, |t| t == &token::OpenDelim(token::Brace)) || do_not_suggest_help { // If the next token is an open brace (e.g., `if a b {`), the place- // inside-a-block suggestion would be more likely wrong than right. e.span_label(sp, "expected `{`"); return Err(e); } let mut stmt_span = stmt.span; // Expand the span to include the semicolon, if it exists. if self.eat(&token::Semi) { stmt_span = stmt_span.with_hi(self.prev_span.hi()); } if let Ok(snippet) = self.span_to_snippet(stmt_span) { e.span_suggestion( stmt_span, "try placing this code inside a block", format!("{{ {} }}", snippet), // Speculative; has been misleading in the past (#46836). Applicability::MaybeIncorrect, ); } </del> <ins> self.parse_block_tail(lo, BlockCheckMode::Default) } fn error_block_no_opening_brace<T>(&mut self) -> PResult<'a, T> { let sp = self.token.span; let tok = self.this_token_descr(); let mut e = self.span_fatal(sp, &format!("expected `{{`, found {}", tok)); let do_not_suggest_help = self.token.is_keyword(kw::In) || self.token == token::Colon; if self.token.is_ident_named(sym::and) { e.span_suggestion_short( self.token.span, "use `&&` instead of `and` for the boolean operator", "&&".to_string(), Applicability::MaybeIncorrect, ); } if self.token.is_ident_named(sym::or) { e.span_suggestion_short( self.token.span, "use `||` instead of `or` for the boolean operator", "||".to_string(), Applicability::MaybeIncorrect, ); } // Check to see if the user has written something like // //    if (cond) //      bar; // // which is valid in other languages, but not Rust. match self.parse_stmt_without_recovery(false) { Ok(Some(stmt)) => { if self.look_ahead(1, |t| t == &token::OpenDelim(token::Brace)) || do_not_suggest_help { // If the next token is an open brace (e.g., `if a b {`), the place- // inside-a-block suggestion would be more likely wrong than right. e.span_label(sp, "expected `{`"); return Err(e); </ins> } <del> Err(mut e) => { self.recover_stmt_(SemiColonMode::Break, BlockMode::Ignore); e.cancel(); </del> <ins> let stmt_span = if self.eat(&token::Semi) { // Expand the span to include the semicolon. stmt.span.with_hi(self.prev_span.hi()) } else { stmt.span }; if let Ok(snippet) = self.span_to_snippet(stmt_span) { e.span_suggestion( stmt_span, "try placing this code inside a block", format!("{{ {} }}", snippet), // Speculative; has been misleading in the past (#46836). Applicability::MaybeIncorrect, ); </ins> } <del> _ => () </del> } <del> e.span_label(sp, "expected `{`"); return Err(e); </del> <ins> Err(mut e) => { self.recover_stmt_(SemiColonMode::Break, BlockMode::Ignore); e.cancel(); } _ => {} </ins> } <del> self.parse_block_tail(lo, BlockCheckMode::Default) </del> <ins> e.span_label(sp, "expected `{`"); return Err(e); </ins> } /// Parses a block. Inner attributes are allowed.

From The following code should be using the common list parsing utilities: CC
What/where are the common list parsing utilties? Edit: never mind, I've got it. , , etc. for anyone who's wondering.


Question: <ins> // revisions: imported unimported //[imported] check-pass </ins> mod private { pub trait Future { <ins> //[unimported]~^^ HELP perhaps add a `use` for it </ins> fn wait(&self) where Self: Sized; }

<!-- 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: <!-- Please provide a link to --The current output is: <!-- The following is not always necessary. --Ideally the output should suggest -ing the out-of-scope trait, similar to E0599: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --Someone tried to do dynamic dispatch between two underlying used a boxed trait object (with the type spelled , so wasn't in scope) and call the method on the boxed reader, and it was unclear from the error why the method wasn't accessible: <!-- 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. --This is reproducible on nightly (rustc 1.67.0-nightly ( 2022-12-01)).
Note: A sign there may be a problem worth fixing here is the code I wrote is a near copypaste of a top stack overflow answer for a :)
So, after some investigating, this appears to be a regression of , which essentially the same suggestion I proposed here: adding a for the trait object's trait. When generating the error when the lookup fails, the trait is initially included in the list of candidates, but it's filtered out by this (because the callee is the trait method, and so the parent of the callee is the trait, which is the candidate): This was introduced in by which also removed the corresponding suggestion from the test's expected output. It's not immediately clear to me from the PR () why this change was necessary. If the call is removed, the only UI test that fails is the one. Reverting that change would fix this issue, but I'm not sure if there are other cases I'm missing.


Question: <ins> // revisions: imported unimported //[imported] check-pass </ins> mod private { pub trait Future { <ins> //[unimported]~^^ HELP perhaps add a `use` for it </ins> fn wait(&self) where Self: Sized; }

(cc with whom I was discussing this on Mastodon)
Haven't look at this yet, maybe I misinterpreted what was achieving, and that commit just needs a revert -- can't recall why I did that.
Yeah, lol, I totally overlooked that the would be load-bearing due to the way we treat trait methods on as inherent. I'll revert , modify the test, etc.


Question: { // When the suggested binding change would be from `x` to `_x`, suggest changing the // original binding definition instead. (#60164) <del> (span, snippet, ", consider changing it") </del> <ins> let post = format!(", consider renaming `{}` into `{snippet}`", suggestion.candidate); (span, snippet, post) </ins> } else { <del> (span, suggestion.candidate.to_string(), "") </del> <ins> (span, suggestion.candidate.to_string(), String::new()) </ins> }; let msg = match suggestion.target { SuggestionTarget::SimilarlyNamed => format!(

I tried on Rust 1.76.0: I got the following error: Note that the suggestion has stripped the leading character from the enum's name.
Can confirm this is still present in nightly.
Sounds like fun. Taking a look.
So it is intended this way from what I can see in the source code: Improving the wording would be become to clear the confusion though I think.


Question: <ins> error: this operation will panic at runtime --> $DIR/unconditional_panic_98444.rs:6:13 | LL |     let _ = xs[7]; |             ^^^^^ index out of bounds: the length is 5 but the index is 7 | = note: `#[deny(unconditional_panic)]` on by default error: aborting due to previous error </ins>

<!-- 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. --I tried this code: I expected to see this happen: Instead, this happened: Apparently, taking a shared reference of will suppress the lint. This seems like a false negative. While false negatives can't be avoided entirely, this case seems to be avoidable as taking a shared reference shouldn't change the type of (which is ) or modify any data in this example. Note that will trigger the lint properly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
See also .
claim
Note this is a problem because which is supposed to fail to compile but this bug makes it fail at runtime instead
In case no one has dug into it yet, the error is suppressed in but not in and before:
label +regression-from-stable-to-stable
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This is caused by . It only ever worked because the lint ran after optimizations. I made a fix . It specializes the length of arrays as constant, even if the array isn't. I'm going to open a PR when I have time, probably tomorrow. In the long term, I'd like to implement some more extensive tracking of "what parts of a value are constant". For example, the compiler currently assumes that anything that had its reference taken can change, but actually, this can only happen inside (as I understand it).
Labels from the closed duplicate , label A-diagnostics, A-lint, A-mir-opt, T-compiler.
Fixed on stable label E-needs-test
I claim the add test part
This lint only appears on full builds (not check), but this will be fixed once lands.
Reopening because I feel this is not yet solved, see on . As per the , should nail down this issue?
MRE: Also, duplicate of
Another variant of this same issue:


Question: <ins> // run-pass // Makes sure we don't propagate generic instances of `Self: ?Sized` blanket impls. // This is relevant when we have an overlapping impl and builtin dyn instance. // See <https://github.com/rust-lang/rust/pull/114941> for more context. trait Trait { fn foo(&self) -> &'static str; } impl<T: ?Sized> Trait for T { fn foo(&self) -> &'static str { std::any::type_name::<T>() } } const fn bar<T: ?Sized>() -> fn(&T) -> &'static str { Trait::foo // If const prop were to propagate the instance } fn main() { assert_eq!("i32", bar::<dyn Trait>()(&1i32)); } </ins>

<!-- 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. --I tried this code: I expected to see this happen: The three printed TypeIds should be identical, as with the behavior in Rust <=1.70 Instead, this happened: switch between rust versions. I could not find reference in the that could explain such behavioral changes.
if my bisection is correct, this surfaced in commit cc (makes sense?)
I do not believe that is the correct PR to point at. Bisecting anything related to MIR opts can be tricky because you need to stabilize the MIR opt pipeline against changes like in that PR which don't actually implement any new behavior, they just change the meaning of MIR opt levels. Try bisecting with ? The above PR just changes the opt level 3 inliner behavior to be the default.
Reproduces since before with
This has to do with the fact that this impl: ... applies even when . Therefore in a polymorphic function like , we're eagerly inlining from that impl even though during monomorphization we'd prefer the built-in candidate instead. This seems problematic.
WG-prioritization assigning priority (). label -I-prioritize +P-high


Question: let snippet = cx .sess() .source_map() <del> .span_to_snippet(span_of_attrs(attrs)) </del> <ins> .span_to_snippet(span_of_attrs(attrs)?) </ins> .ok()?; let starting_line = markdown[..md_range.start].matches('n').count();

crashes on nightly () and also on stable () with "nightly" features turned on via . It does not trigger on stable without flag. Here is the output I'm getting: I created a small repro case + here: (it only happens when there is a certain combination of procedural macros, so I cannot make it a single file).
The source code is: with crate being a procedural macro crate with:
Couple of things that are important here: only happens with two procedural macros. macro has to do that . attribute has to be , does not reproduce with anything else.
Just a heads-up: AFAIK if a bug only occurs on stable with (I understand that it is not the case here), then it should probably be disregarded, because isn't supposed to be used when not bootstrapping the compiler.
The bug itself reminds me of
it happens on nightly as well. That detail was included to give context that evidently the ICE has been present for longer than 12 weeks, I believe.
With the following patch in the linked repo, the output is not ideal, but preferable to the ICE: I'll take a look to see if we can somehow keep the span for the entire attr doc, or at worst pointing at the correct macro.
Changing the patch to be gives us which makes more sense but is missing a primary span. Edit: I see no way to recover the original span after its has been modified. I guess we already rely on proc macro writers to be nice when it comes to spans, so this is acceptable as well.


Question: let pred = trait_ref.without_const().to_predicate(tcx).to_string(); let pred = pred.replace(&impl_trait_str, &type_param_name); let mut sugg = vec![ <ins> // Find the last of the generic parameters contained within the span of // the generics </ins> match generics .params .iter() <del> .filter(|p| match p.kind { hir::GenericParamKind::Type { synthetic: Some(hir::SyntheticTyParamKind::ImplTrait), .. } => false, _ => true, }) .last() </del> <ins> .map(|p| p.bounds_span().unwrap_or(p.span)) .filter(|&span| generics.span.contains(span) && span.desugaring_kind().is_none()) .max_by_key(|span| span.hi()) </ins> { // `fn foo(t: impl Trait)` //        ^ suggest `<T: Trait>` here None => (generics.span, format!("<{}>", type_param)), // `fn foo<A>(t: impl Trait)` //        ^^^ suggest `<A, T: Trait>` here <del> Some(param) => ( param.bounds_span().unwrap_or(param.span).shrink_to_hi(), format!(", {}", type_param), ), </del> <ins> Some(span) => (span.shrink_to_hi(), format!(", {}", type_param)), </ins> }, // `fn foo(t: impl Trait)` //                       ^ suggest `where <T as Trait>::A: Bound`

(Edit: Actually, being an inherent fn doesn't matter. It happens with top-level fns too.) This prints the diagnostic: The suggestion in the last line is not valid syntax (). It also emits malformed syntax if the first parameter is a or parameter. The diagnostic becomes well-formed if any of the following is done: The first parameter is changed to instead ofThe fn is not an async fn. In either case, the diagnostic correctly says: Happens on both nightly: ... and stable:
This should hopefully be a fairly straightforward patch to the diagnostics code that generates the suggestion.


Question: <ins> //! Regression test for #74400: Type mismatch in function arguments E0631, E0271 are falsely //! recognized as E0308 mismatched types. use std::convert::identity; fn main() {} fn f<T, S>(data: &[T], key: impl Fn(&T) -> S) { } fn g<T>(data: &[T]) { f(data, identity) //~ ERROR implementation of `FnOnce` is not general } </ins>

Regression from to . The following code yields an incorrect error: On beta, this gives: On nightly, this:
would you be so kind to label this issue? It's sliding down the list while being hard to search.
Regression occurred between nightly-2020-06-23 and nightly-2020-06-24, I suspect is related (it's ?).
It would be great to find the culprit PR. 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
searched nightlies: from nightly-2020-06-23 to nightly-2020-06-24 regressed nightly: nightly-2020-06-24 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsIf we rule out document changes then we have
Bisection seems to confirm this, cc
With a little more git bisect it seems is the first bad commit And I guess the change to the test case also shows that
Assigning as and removing .
Well, I can certainly imagine how this could come about as a result of the leak-check moving, since the same error can now be detected at a different point during type-checking. What's happening in that confusing error, I imagine, is that we are now winding up with a "universe error" that comes out from region checking. The identity function was inferred to take an argument for some ... Well, in short, I imagine that the solution here is to improve the error reporting for the new point where the error occurs, but it'll take a bit more digging to give good mentoring instructions into how to go about doing that.
This is now a stable regression.
Discussed in T-compiler meeting. Seems related to (or potential duplicate of) ?
On today's nightly, the error is now: That seems correct, and with the extra lifetime, the snippet compiles:


Question: LL - fn f2<X: ?Sized, Y: ?Sized>(x: &X) { LL + fn f2<X, Y: ?Sized>(x: &X) { | <ins> help: consider borrowing here | LL |     let y: &X; |            + </ins> error[E0277]: the size for values of type `Y` cannot be known at compilation time --> $DIR/unsized6.rs:17:12

I tried compiling this code: which resulted in the following output of rustc: So the compiler says So I tried adding a borrow and recompiling the code: which resulted in: so the compiler says and so I'm stuck in a loop. The compiler can't decide whether I should borrow or not. As a newbie to Rust, this is very frustrating and the opposite of helpful, it just confuses me further. Please fix this indecisiveness :) :
For reference, what you likely want to do is one of the following which means they cannot be the type of a local binding. You can give a binding a slice type (), because that's morally equivalent to a pointer (with sizing info), which has a compile time determined size, as all borrows are .
Current output: After :


Question: // The lifetime was defined on node that doesn't own a body, // which in practice can only mean a trait or an impl, that // is the parent of a method, and that is enforced below. <del> assert_eq!(Some(param_owner_id), self.root_parent, "free_scope: {:?} not recognized by the  region scope tree for {:?} / {:?}", param_owner, self.root_parent.map(|id| tcx.hir().local_def_id_from_hir_id(id)), self.root_body.map(|hir_id| DefId::local(hir_id.owner))); </del> <ins> if Some(param_owner_id) != self.root_parent { tcx.sess.delay_span_bug( DUMMY_SP, &format!("free_scope: {:?} not recognized by the  region scope tree for {:?} / {:?}", param_owner, self.root_parent.map(|id| tcx.hir().local_def_id_from_hir_id(id)), self.root_body.map(|hir_id| DefId::local(hir_id.owner)))); } </ins> // The trait/impl lifetime is in scope for the method's body. self.root_body.unwrap().local_id

The following minimal example causes an internal compiler error. Error in question: rustc version: This error was encountered on stable, but I can confirm that it also occurs on the latest nightly ().
Hasn't the feature gate issue been fixed? :|
I've removed the nomination and this to the tracking issue for GATs . The current impl is highly incomplete and ICEs are, sadly, expected. Also, I verified that a feature gate is indeed required.
triage: P-medium
I don't know if I get you wrong, but the example above ICEs on stable, beta and nightly without feature gate
oops, looks like I accidentally left the feature gate in there when I tried it out, but it produces the same ICE when it is omitted as well.
No, niko edited your question. ping I think you got something wrong there. Can you please clarify that?
Oh, I guess I was indeed incorreect. I tried it on play but didn't notice that, after the "correct" error, it goes on to print an ICE.
What about adding the I-nominated tag again?
I'm not sure why we would nominate this for discussion. Yes, it is an ICE (and an ICE that occurs without the user adding a feature gate), but the message pretty clearly states that you're using an unstable feature. It would be great to fix it so that it issues the error diagnostic without ICEing, but I wouldn't re-prioritize that work above P-medium.
assigning to self since its a clear annoyance
triage: P-medium. (dupe of )
(the remaining bug, when the feature gate is enabled, is tracked in issue )


Question: Value(int), Missing, } <del> fn main() { let x = Value(5); let y = Missing; match x { Value(n) => println!("x is {}", n), Missing  => println!("x is missing!"), } match y { Value(n) => println!("y is {}", n), Missing  => println!("y is missing!"), } } </del> ``` This enum represents an `int` that we may or may not have. In the `Missing`

See: The keyword hasn't been introduced until that point but it's used in the code example which is confusing. I believe an if/else solution would be more explanatory, especially because the reader probably wants to see how to unpack the variant of . The same enum could then be used with the keyword in the beginning of the next chapter ().
You are correct. Nice catch!
Are you ok with simply reordering them ? Because introducing sum type without precedent knowledge of pattern matching is a bit pointles (or at least misses the fact that they are juste AWESOME for pattern matching). If you're ok with this I'll PR in a few hours :)
Maybe, if it flows okay, yeah. I do want to put SOME kind of mention of it first.
It's probably easy to find out what is doing by simply looking at it. This part of the tutorial is just a bit confusing and should be fixed. However, my main concern here is that the reader is left clueless on how to solve this problem with if/else: In fact, I really don't know how the equivalent code without would look like. I've briefly tried to figure it out and gave up.
With an Option you coul unwrap I guess. By the way why did you write a fake option enum ? Because that's basically what is done with this, it might be better to give out the real name
Because we haven't talked about generics yet.
Nicely done. However, my other concern, how this example could be done without , remains unresolved. I'm certain that I'm not the only one who wants to know how it works with before continue reading about . Should I open another issue for that matter?
I'm honestly not sure that it is possible with an arbitrary enum... You can test for some arbitrary values but i guess but that's it. Bt it's more an issue of sum types in general rather than a Rust issue (I can't find ways to do that in haskell nor in scala)
Alright, I expected something like this as I was unable to figure out how to write it without . I don't have much experience with statically typed languages, therefore the concept was new to me. If you are right, could we mention in the tutorial that it is actually not possible to write an equivalent solution with ? Certainly, I can't be the only one who was a bit puzzled.


Question: Value(int), Missing, } <del> fn main() { let x = Value(5); let y = Missing; match x { Value(n) => println!("x is {}", n), Missing  => println!("x is missing!"), } match y { Value(n) => println!("y is {}", n), Missing  => println!("y is missing!"), } } </del> ``` This enum represents an `int` that we may or may not have. In the `Missing`

Cheers.
Thanks a lot for the remark, it's exactly the kind of comment needed, if you see others don't hesitate to open new issues :) I'll try to add this tonight or tomorrow.


Question: span } = *self; <del> hcx.hash_hir_item_like(attrs, |hcx| { </del> <ins> let is_const = match *node { hir::TraitItemKind::Const(..) | hir::TraitItemKind::Type(..) => true, hir::TraitItemKind::Method(hir::MethodSig { constness, .. }, _) => { constness == hir::Constness::Const } }; hcx.hash_hir_item_like(attrs, is_const, |hcx| { </ins> name.hash_stable(hcx, hasher); attrs.hash_stable(hcx, hasher); generics.hash_stable(hcx, hasher);

Found via rust-icci: https://travis- The commit history of the regex crate contains on changeset that only adds a comment which in turn leads to the body of a function being moved. This results in the update of the source location pointed to by a potential overflow panic message. This message is not updated properly in incremental mode: I have not found out yet why the change is not detected. HIR fingerprinting has special treatment of operations that can trigger overflows: There must be some kind of mismatch between when HIR fingerprinting thinks that an operation can panic and when we actually emit panic messages. This is another span-related papercut cc
Full IR files for reference:


Question: <ins> error[E0277]: the `?` operator can only be applied to values that implement `std::ops::Try` --> $DIR/issue-72766.rs:14:5 | LL |     SadGirl {}.call()?; |     ^^^^^^^^^^^^^^^^^^ |     | |     the `?` operator cannot be applied to type `impl std::future::Future` |     help: consider using `.await` here: `SadGirl {}.call().await?` | = help: the trait `std::ops::Try` is not implemented for `impl std::future::Future` = note: required by `std::ops::Try::into_result` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

<!-- 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 may be related, but I don't think this is the same bug because the above ICEs with nightly-2020-05-29.
cc


Question: --> $DIR/invalid-const-arg-for-type-param.rs:6:23 | LL |     let _: u32 = 5i32.try_into::<32>().unwrap(); <del> |                       ^^^^^^^^------ help: remove these generics |                       | |                       expected 0 generic arguments </del> <ins> |                       ^^^^^^^^ expected 0 generic arguments </ins> | note: associated function defined here, with 0 generic parameters --> $SRC_DIR/core/src/convert/mod.rs:LL:COL | LL |     fn try_into(self) -> Result<T, Self::Error>; |        ^^^^^^^^ <ins> help: consider moving this generic argument to the `TryInto` trait, which takes up to 1 argument | LL |     let _: u32 = TryInto::<32>::try_into(5i32).unwrap(); |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ help: remove these generics | LL -     let _: u32 = 5i32.try_into::<32>().unwrap(); LL +     let _: u32 = 5i32.try_into().unwrap(); | </ins> error[E0599]: no method named `f` found for struct `S` in the current scope --> $DIR/invalid-const-arg-for-type-param.rs:9:7

<!-- 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: When a user called with an annotation, it's helpful to suggest too. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
If it's ok, I would like to give a shot. If you plan to work on it, please go ahead.
It's yours :)
claim
Hi, I would like to ask a question... I'm reading the code now and am thinking of extending the error messages by adding to . My plan is that start adding some fields (like ty::TraitRef) to and dbg! the output to get the value of trait information like for a new error message. Is my approach out of line or is there a better approach for that.
You don't have to hold information of in because we can get the info on-demand by the combination of and . Say you'd add a method of , the code will be something like this: For getting the name of the trait in question, or will be handy for you.
I appreciate your answer.
are you still working on this? :)


Question: <ins> error[E0310]: the associated type `<impl Iterator as Iterator>::Item` may not live long enough --> $DIR/closure-in-projection-issue-97405.rs:24:5 | LL |     assert_static(opaque(async move { t; }).next()); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: consider adding an explicit lifetime bound `<impl Iterator as Iterator>::Item: 'static`... = note: ...so that the type `<impl Iterator as Iterator>::Item` will meet its required lifetime bounds error[E0310]: the associated type `<impl Iterator as Iterator>::Item` may not live long enough --> $DIR/closure-in-projection-issue-97405.rs:26:5 | LL |     assert_static(opaque(move || { t; }).next()); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: consider adding an explicit lifetime bound `<impl Iterator as Iterator>::Item: 'static`... = note: ...so that the type `<impl Iterator as Iterator>::Item` will meet its required lifetime bounds error[E0310]: the associated type `<impl Iterator as Iterator>::Item` may not live long enough --> $DIR/closure-in-projection-issue-97405.rs:28:5 | LL |     assert_static(opaque(opaque(async move { t; }).next()).next()); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: consider adding an explicit lifetime bound `<impl Iterator as Iterator>::Item: 'static`... = note: ...so that the type `<impl Iterator as Iterator>::Item` will meet its required lifetime bounds error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0310`. </ins>

<!-- 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. --I tried this code: Both asserts don't pass. Adding bound on makes it compile. We are requiring all the for closures and generators to outlive here: This is wrong and inconsistent with the logic in <!-- 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. --Build using the Nightly version: 1.63.0-nightly (2022-05-24 ) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details label T-compiler A-lifetimes A-closures A-generators claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Error: Parsing assign command in failed: ...'bot assign' ''... Please let know if you're having trouble with this bot.


Question: use core::mem; use core::ops::{CoerceUnsized, Deref, DerefMut}; use core::ops::{Placer, Boxed, Place, InPlace, BoxPlace}; <del> use core::ptr::Unique; </del> <ins> use core::ptr::{self, Unique}; </ins> use core::raw::{TraitObject}; /// A value that represents the heap. This is the default place that the `box`

We need to find a way to implement Clone for where . In user code, "cloning" such a box manually is simple: will do it with a short roundtrip through which should be unproblematic. In the rust distribution, we can't impl Clone easily since the tools to do so are in libcollections but the Box type lives in liballoc.
You do not need vec for the implementation. Something like the following would work: Note that because can panic it is required to keep track of the partial result so the correct stuff is dropped.
Yes, that's nice that it can be carefully solved by essentially extracting the needed parts from what Vec does. But the Box code is otherwise so clean, it doesn't feel like the right way to do it.
You're welcome to suggest an alternative but I doubt it can be done in a manner that is both correct and significantly cleaner :)
Your fundamental analysis is great: just isn't an exception safe representation while filling it with elements. It needs to keep track of the fill level, so a representation like Vec or BoxBuild is needed...
Clone is also wanted for , but that can be much simpler: There is no panic issue, and it can use a simple memcpy of the data.


Question: // Create the intermediate directories let mut cur = self.dst.clone(); let mut root_path = String::from_str("../../"); <del> clean_srcpath(&self.cx.src_root, &p, |component| { </del> <ins> clean_srcpath(&self.cx.src_root, &p, false, |component| { </ins> cur.push(component); mkdir(&cur).unwrap(); root_path.push_str("../");

When visiting a page such as or the link src (for the source code) no longer works. Instead a 404 is returned. This seems to have been broken for several days now.
even before this, many but not all were broken. there may be multiple issues with this symptom.
The links link in the form but it seems like the actual source is being placed in a location in the form For example here's a link from the current docs which will 404: But the following will resolve:
Really annoyed by this. :<


Question: <ins> pub trait Foo { type Type; } pub struct Bar<T>(<Self as Foo>::Type) where Self: ; //~^ ERROR the trait bound `Bar<T>: Foo` is not satisfied fn main() {} </ins>

Internal compiler error when missing bound on struct. Reproducible on stable/beta/nightly on . Also, not sure if it already has it's own issue, but is causing an illegal instruction error when you run it with on this code as well, which is also reproducible on playground if you turn the backtrace setting on. I tried this code: () I expected to see this happen: Instead, this happened: rustc versions (from playground): <details<summaryBacktrace (note the SIGILL at the end)</summary<p</p</details
cc
triage: P-high, removing nomination label (has PR).


Question: HTML_DEPS := endif <del> # Check for the various external utilities for the EPUB/PDF docs: ifeq ($(CFG_LUALATEX),) $(info cfg: no lualatex found, deferring to xelatex) ifeq ($(CFG_XELATEX),) $(info cfg: no xelatex found, deferring to pdflatex) ifeq ($(CFG_PDFLATEX),) $(info cfg: no pdflatex found, disabling LaTeX docs) NO_PDF_DOCS = 1 else CFG_LATEX := $(CFG_PDFLATEX) endif else </del> <ins> # Check for xelatex ifeq ($(CFG_XELATEX),) </ins> CFG_LATEX := $(CFG_XELATEX) XELATEX = 1 <del> endif else CFG_LATEX := $(CFG_LUALATEX) </del> <ins> else $(info cfg: no xelatex found, disabling LaTeX docs) NO_PDF_DOCS = 1 </ins> endif ifeq ($(CFG_PANDOC),) $(info cfg: no pandoc found, omitting PDF and EPUB docs) ONLY_HTML_DOCS = 1

Same error, with the last github version.
Also getting this, I'm running the Yosemite GM 1. Not sure if it's related.
I also getting this on MacOs
Still getting this make error, like many others did. Anyone want to fix this?
I have no idea how to fix this, other than just installing xetex or however it's spelled
The configure(or make) did find LuaTeX.
Sadly I don't have time to work on this right now. A simple fix would be to disable pdf generation unless specified in configure, or to require xetex.
I don't think that LaTeX should be a dependency to build a programming language like Rust.
it seems reasonable to have the option to not build PDF docs if you don't want to
I think I'm getting the same error, which is strange because I believe I was able to a couple days ago. In the log, the complaint is that is not found. As suggested above, is included with MacPorts' package and installing that allowed compilation of docs to go through.
will build without building the PDF docs


Question: Some(ns @ TypeNS) => { match self.resolve( path_str, <ins> disambiguator, </ins> ns, &current_item, base_node,

I tried to document this code: I expected to see this happen: charstd::char` points to module page of char type points to char primitive page Instead, this happened: type points to module page of char :
I think the problem is that modules are in the type namespace, so is doing exactly what you are asking it for (the module, since it has higher priority). Since the built-in types scope is the lowest precedence, perhaps there needs to be a way to access it directly? Maybe something like or ? Or maybe should skip over modules, and keep looking deeper in the scope hierarchy? (cc )
Oh hmm I see what you mean. There are : Types, values, and macros. Since modules and types are in the same namespace, it uses the first one it finds. Maybe we could work around this by first resolving in an empty module (so it has nothing in scope), then only falling back to the current scope if we don't find something there?
I'm surprised this hasn't caused trouble before now. Does the root of never use the primitive?
I don't know how it works, but the resolver is smart enough to know that in a type context won't match a module (like , the won't match a module named "char". Maybe it has something to do with late-resolution  which has a to give it some context?
Adding that would be more of area ... I can give it a shot though.
It looks like doesn't even return a resolution and only records it for later use ... I'm going to go with the empty module workaround and we can fix it later if it turns out to cause issues.
The double resolve seems hacky. We could probably make type@ specifically not resolve to a module, perhaps? Also, note that modules are in all namespaces
How would that work? We could skip any module resolutions, but since modules have precedence over types I don't know how we'd get the primitive type to resolve afterwards.
Oh hold on we have a function already. We can look at directly.
This doesn't have anything to do with primitives, this has to do with glob imports vs non-glob imports. You can get the same issue with the following:
This also doesn't have to do with modules being "resolved first" or anything. Things that are non-glob in-scope are resolved first.


Question: Some(ns @ TypeNS) => { match self.resolve( path_str, <ins> disambiguator, </ins> ns, &current_item, base_node,

Actually, my bad: This does have to do with primitives in the sense that primitives are the only thing that still work when shadowed because of some special code in checking the primitive tables. I think when the string matches one of the primitive table entries for TypeNS lookups that were explicitly annotated with type@ and resolve to a module we can hack this in. In the future we might want to tighten up this code so that e.g. can't resolve to an enum, etc.
do you mind if I fix at the same time and resolve primitives even before modules? That seems like the less surprising behavior to me, the module can still be disambiguated with .
I'm a bit wary of doing this because having the char module in scope is not a common situation, and it will get weirder for people who have a different char module. I think we should resolve to whatever is in scope, but if is explicitly mentioned we can then force resolve to the primitive.


Question: | KeywordItem => [].iter(), } } <ins> /// Returns `true` if this item does not appear inside an impl block. pub(crate) fn is_non_assoc(&self) -> bool { matches!( self, StructItem(_) | UnionItem(_) | EnumItem(_) | TraitItem(_) | ModuleItem(_) | ExternCrateItem { .. } | FunctionItem(_) | TypedefItem(_) | OpaqueTyItem(_) | StaticItem(_) | ConstantItem(_) | TraitAliasItem(_) | ForeignFunctionItem(_) | ForeignStaticItem(_) | ForeignTypeItem | MacroItem(_) | ProcMacroItem(_) | PrimitiveItem(_) ) } </ins> } #[derive(Clone, Debug)]

From Given the following Rust code with in-line annotations of the expected behaviour: On: does not seem to be able to generate feature requirement labels on types in private modules () that are publicly reexported (). The labels do not show up on the module overview nor page, but do propagate into items like functions for the given type. This renders the type without any feature requirement, neither in the module overview: ! Nor on the page: ! Note that the label is propagated onto (does not have an explicit ), at least understood that! It is supposed to render the feature requirement for like , both in the module overview above as on the page: ! It seems tricky to combine feature requirements on the and reexport. In the case above they are the same, but what if: The type is only publicly available when and are specified. Specifying is fine but makes the contents of unreachable through the current module, specifying only should result in a "module not found" error. CC
This also affects re-exports of entire crates. Unfortunately there the fix is not clear at all, since the "parent" crate is obviously not guaranteed to have the same features as the crate being re-exported.
Within the same crate as well; it's not about the features that are enabled (though it is relevant which are available) but about the combined restrictions that are placed on the definition and reexport. Simplest I can think of is a union of all features (but gets complicated quick when inversions and vs is used) and later perhaps simplifying based on feature relations (if implies there is no need to display as requirement, if either definition or reexport requires ). That's necessary to cleanly solve crate reexports, since you effectively want to ensure that the top-level crate feature implies feature and hide it. If the whole resolver is made smart enough (perhaps this already exists, I'm not too familiar with Cargo) it could even throw warnings when there exist feature combinations that would lead to a compiler error (ie. explicitly reexporting a symbol that is not available for a certain set of features).
I wonder if this is just an ordering issue of the passes: The private modules have disappeared by the point where we pass all the data down so we don't see them.


Question: | KeywordItem => [].iter(), } } <ins> /// Returns `true` if this item does not appear inside an impl block. pub(crate) fn is_non_assoc(&self) -> bool { matches!( self, StructItem(_) | UnionItem(_) | EnumItem(_) | TraitItem(_) | ModuleItem(_) | ExternCrateItem { .. } | FunctionItem(_) | TypedefItem(_) | OpaqueTyItem(_) | StaticItem(_) | ConstantItem(_) | TraitAliasItem(_) | ForeignFunctionItem(_) | ForeignStaticItem(_) | ForeignTypeItem | MacroItem(_) | ProcMacroItem(_) | PrimitiveItem(_) ) } </ins> } #[derive(Clone, Debug)]

Thanks for the suggestion - I moved before and (I've never built rustc/rustdoc from source, pleasantly surprised that only took just under 7min on a ThreadRipper :partyingface:) but it doesn't change anything to the generated output unfortunately :(
I observe this on public items as well: Does not show the badge at re-exports.
So from the following code: is stripped and then inlined. The stripped version contains all the correct information but the inlined one doesn't. Checking what's the best course here: either cloning the stripped item or propagating when inlining.


Question: # Find out where the pretty printer Python module is RUSTC_SYSROOT="$("$RUSTC" --print=sysroot)" GDB_PYTHON_MODULE_DIRECTORY="$RUSTC_SYSROOT/lib/rustlib/etc" <ins> # Get the commit hash for path remapping RUSTC_COMMIT_HASH="$("$RUSTC" -vV | sed -n 's/commit-hash: (w*)/1/p')" </ins> # Set the environment variable `RUST_GDB` to overwrite the call to a # different/specific command (defaults to `gdb`).

I'm trying to use on project generated by and looks like the source code path is not configured:
Visited during wg-debugging's triage meeting. We think this is most likely still an issue but probably not a high priority one. If someone wants to work on this, the first thing they should do is retest and verify this is still broken (but we think it most likely is). There may be a fairly simple resolution to modify rust-gdb to detect which toolchain it's being invoked from and then run the set substitute-path path with the appropriate paths. I'm willing to help mentor someone in fixing this
Hi, I'm looking for a first issue, would love the mentoring!
can't reproduce it, it works just fine nearly 4 yrs later, has this perhaps already been fixed ?
Past should have included a sample test case.
No, I can still reproduce it. are you maybe using a distro-packaged toolchain? Crashing program: output: To make work, don't use in the replacement.


Question: padding: 5px 10px; } h5, h6 { <del> color: black; </del> text-decoration: underline; }

When running , this file is opened for me . I thought I'd use that file in my note taking application, which I have set to a dark theme. However for in that documentation is set to have the and the background uses the default color. This leads to the text becoming hard to read. ! I would prefer the text color not to be explicitly set, or if you insist on the dark gray text, making sure that the background color is also set to something light.
Transferred to rust-lang/rust. The CSS for this lives at
It's not rustdoc so to speak. I'll fix the issue.


Question: fn output_filename(&mut self, path: &Path) { self.cmd.arg("-o").arg(path); } fn add_object(&mut self, path: &Path) { self.cmd.arg(path); } fn position_independent_executable(&mut self) { self.cmd.arg("-pie"); } <ins> fn no_position_independent_executable(&mut self) { self.cmd.arg("-no-pie"); } </ins> fn partial_relro(&mut self) { self.linker_arg("-z,relro"); } fn full_relro(&mut self) { self.linker_arg("-z,relro,-z,now"); } fn build_static_executable(&mut self) { self.cmd.arg("-static"); }

I'm having trouble linking a Rust program to a non-position-independent C library. When I manually remove the flag from the ld step that rustc runs, everything works correctly. I think that should remove the flag for me, but it doesn't. Here's what I think is going on: When I run It runs ld with the flag: But when I read the rustc code , it seems like the intention is that should only be passed to ld when . That is, if we're not compiling a position independent executable, then we should not pass the position independent executable flag to ld. I think what may be happening here is that somehow the defaults from are overriding the command line options I'm setting. This happens with stable and also the nightly I tried:
and are two distinct things. is also unrelated to the option. Interestingly, I do not remember us having an option to disable PIE; we should have one.
I did a bit of reading and here's what I figured out, please correct me if any of this is wrong. Linkers are new to me! Rust builds position independent executables by default on platforms that support it. These platforms have a relocation model of pic in their target config. The is what sets that linker option, except if it's disallowed by . The correct solution to this is to add a codegen flag, or something like that. Does this sound right?
Hi, I am having the same issue. I am trying to link against non-position-independent C library, build process ends without error but results returned by Rust bindings are different (and incorrect) than those returned from clean C implementation. In order to overcome that issue currently I am setting RUSTFLAGS="-C relocation-model=dynamic-no-pic -C linker=./linker" where linker is bash script that wraps cc and filter -pie flags:
I'm also having this problem. I assumed that passing when doing a build would suppress on the linker command line. (cc:
I'm still seeing this issue. Not sure if it's a regression or I'm doing something wrong. I have a "hello world" program in , and when I run , the resulting call to includes . I'm using nightly rust on Ubuntu: .
So, the problem here isn't with rust, but with the linker.


Question: fn output_filename(&mut self, path: &Path) { self.cmd.arg("-o").arg(path); } fn add_object(&mut self, path: &Path) { self.cmd.arg(path); } fn position_independent_executable(&mut self) { self.cmd.arg("-pie"); } <ins> fn no_position_independent_executable(&mut self) { self.cmd.arg("-no-pie"); } </ins> fn partial_relro(&mut self) { self.linker_arg("-z,relro"); } fn full_relro(&mut self) { self.linker_arg("-z,relro,-z,now"); } fn build_static_executable(&mut self) { self.cmd.arg("-static"); }

In Ubuntu 15.10 and later the default GCC toolchain installed has been compiled with which causes and to be passed to during code generation and to during linking. Now, the linking part is what is important here as rust on most platforms uses as the linker for most targets. So, though no PIC or PIE code may have been generated by , the linker will still try to link as with PIE in mind, breaking when trying to compile with and the like. To work around this will need to see that the linker has been compiled with PIE as the default and pass to the linker if using GCC or something similar for other linkers. Code to do this can be seen in for Tarpaulin though it is only meant for Linux in that state and can be improved greatly if in tree. EDIT: Don't know why Github isn't linking cross-project PRs correctly right now.
Can this issue be resolved by always passing , except when compiling with ?
Sadly, no. In testing I have seen that any build of GCC that was not built with rejects the option and fails to run. This is why in the PR that I linked the linker was queried to see if it was compiled with before tacking on .
So it's came out from the discussion on an issue related to this in tarpaulin that passing -no-pie before -shared (and maybe then -static if it exists for static linkages as well) resolves the issue. I'm going to test this tarpaulin side and I can report back but I feel it would be best if this could be solved rustc side as it can affect any user in a similar situation.


Question: // We errored. Signal that in the pattern, so that follow up errors can be silenced. let kind = PatKind::Error(e); return Box::new(Pat { span: self.span, ty: cv.ty(), kind }); <ins> } else if let ty::Adt(..) = cv.ty().kind() && matches!(cv, mir::Const::Val(..)) { // This branch is only entered when the current `cv` is `mir::Const::Val`. // This is because `mir::Const::ty` has already been handled by `Self::recur` // and the invalid types may be ignored. let err = TypeNotStructural { span: self.span, non_sm_ty }; let e = self.tcx().sess.emit_err(err); let kind = PatKind::Error(e); return Box::new(Pat { span: self.span, ty: cv.ty(), kind }); </ins> } else if !self.saw_const_match_lint.get() { if let Some(mir_structural_match_violation) = mir_structural_match_violation { match non_sm_ty.kind() {

<!-- 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. --: This bug was also reproduced in the stable version(1.72) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Hmm this was caused by cc
claim


Question: <ins> // Copyright 2015 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. #![allow(dead_code)] struct Foo; impl Foo { fn new() -> Self { Foo } fn bar() { Self::new(); } } fn main() {} </ins>

The following code will fail to compile at "Self::new()" with the message, "error: failed to resolve. Use of undeclared type or module " While either of the following will work: The first example should compile as-is.


Question: <ins> use crate::infer::outlives::components::{compute_components_recursive, Component}; </ins> use crate::infer::outlives::env::RegionBoundPairs; use crate::infer::region_constraints::VerifyIfEq; use crate::infer::{GenericKind, VerifyBound}; use rustc_data_structures::captures::Captures; use rustc_data_structures::sso::SsoHashSet; use rustc_hir::def_id::DefId; <del> use rustc_middle::ty::subst::{GenericArg, GenericArgKind, Subst}; </del> <ins> use rustc_middle::ty::subst::{GenericArg, Subst}; </ins> use rustc_middle::ty::{self, EarlyBinder, Ty, TyCtxt}; <ins> use smallvec::smallvec; </ins> /// The `TypeOutlives` struct has the job of "lowering" a `T: 'a` /// obligation into a series of `'a: 'b` constraints and "verifys", as /// described on the module comment. The final constraints are emitted


Question: fn outer(self) { fn inner(_: Self) { //~^ ERROR can't use type parameters from outer function <del> //~^^ ERROR use of undeclared type name `Self` </del> <ins> //~^^ ERROR use of `Self` outside of an impl or trait </ins> } } }

is a keyword, this error message indicates that it can be used to define type, which is misleading.
There is a similar issue: file.
No, that's a different issue. At the time that issue was filed, was not a keyword, just a confusing type. That said, at the time that issue was reported, it's fine to say the compiler was implemented properly. But my issue is about wrong error message, not bad(confusing) error message.
Do you mean is not a special ident now? I found the example code can be compiled, and there is excluding self type code
My point is that we are in different situation now. See and notice that it happened after the time the issue we discuss was filed.
Actually, IIRC we're moving towards a direction where can be used everywhere in a trait or impl context. I'm not sure though. any idea?
Yes we can use it in traits or impls. is totally legal for instance. But inside global functions can not be explained if I understand correctly.
Oh, sorry, this was a global fn. Makes sense.


Question: <ins> // Copyright 2015 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. trait Foo: Sized { fn foo(self) {} } trait Bar: Sized { fn bar(self) {} } struct S; impl<'l> Foo for &'l S {} impl<T: Foo> Bar for T {} fn main() { let s = S; s.foo(); (&s).bar(); s.bar(); } </ins>

Consider this code: The error is: It'd be nice if the explicit ref wasn't required in this case.
cc
This has now been fixed.
I believe this is covered by


Question: use rustc::hir::def::{Res, DefKind}; use rustc::hir::def_id::DefId; use rustc::lint; <del> use rustc::ty; </del> <ins> use rustc::ty::{self, Ty}; </ins> use rustc::ty::adjustment; use rustc_data_structures::fx::FxHashMap; use lint::{LateContext, EarlyContext, LintContext, LintArray};

gives a warning, but does not.
suggested that we test this out with crater to see if this would generate much substantial noise and how common it would be.
I'd expect it'd be a pretty substantial source of warnings, but that's exactly why I think we should introduce it. People compiling with are asking for these sorts of bugs to be caught, and we should serve them appropriately ;) In any case, running crater would require having an implementation to do a crater run on, so let's do it!
Let's do it. (I'd personally even like an attribute to allow people to opt-in to this for , for example, when T is itself . That way if I make a , I'll get a warning on that I normally wouldn't want but plausibly do now that I'm getting s in the s.)
I've opened a pull request to try this out:
We discussed this on the language team meeting; folks felt generally positive, but we'd like to do a crater run to see what the impact would be like and if there would be many false positives.
I tried this using but it does not seemed to complain when the part of is not used, is the the correct behavior? I hit this when doing where I didn't use part of the tuple which cause it to not work, which I did not know is required to be used.
putting it into a binding, even an unused one, is considered a use, like how doesn't lint. With just calling it lints:


Question: #[primary_span] pub item_span: Span, #[suggestion(code = "unsafe ", applicability = "machine-applicable", style = "verbose")] <del> pub block: Span, </del> <ins> pub block: Option<Span>, </ins> } #[derive(Diagnostic)]

With the following code: We get this error: Making the block then gives: cc
:+1:, this should error in both cases but the diagnostics are misleading. Going to fix it. r?


Question: <ins> error: prefix `world` is unknown --> $DIR/lex-bad-str-literal-as-char-3.rs:5:21 | LL |     println!('hello world'); |                     ^^^^^ unknown prefix | = note: prefixed identifiers and literals are reserved since Rust 2021 help: if you meant to write a string literal, use double quotes | LL |     println!("hello world"); |              ~           ~ </ins> error[E0762]: unterminated character literal --> $DIR/lex-bad-str-literal-as-char-3.rs:5:26 |

<!-- ICE: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
:thinking: this bisects to cc
very plausible :+1:
Reduced


Question: <ins> error[E0631]: type mismatch in closure arguments --> $DIR/issue-41366.rs:10:5 | LL |     (&|_|()) as &dyn for<'x> Fn(<u32 as T<'x>>::V); |     ^^-----^ |     | | |     | found signature of `fn(_) -> _` |     expected signature of `for<'x> fn(<u32 as T<'x>>::V) -> _` | = note: required for the cast to the object type `dyn for<'x> std::ops::Fn(<u32 as T<'x>>::V)` error[E0271]: type mismatch resolving `for<'x> <[closure@$DIR/issue-41366.rs:10:7: 10:12] as std::ops::FnOnce<(<u32 as T<'x>>::V,)>>::Output == ()` --> $DIR/issue-41366.rs:10:5 | LL |     (&|_|()) as &dyn for<'x> Fn(<u32 as T<'x>>::V); |     ^^^^^^^^ expected bound lifetime parameter 'x, found concrete lifetime | = note: required for the cast to the object type `dyn for<'x> std::ops::Fn(<u32 as T<'x>>::V)` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0271`. </ins>

Binder(<[type error] as ToBytes) This only happens if there are two erroneous functions, if I take out it works fine. It seems like I was trying to do this wrong in the first place since the first function gives an error . Not sure what the right way to do this is. <details<summaryTraceback</summary</details
Tried to reduce it and found a similar case with the same ICE:
Compiler triage: Seems likely to be caused by the need for lazy norm. Marking as p-medium for now.
The ICE doesn't appear on the latest nightly, marked as E-needstest


Question: <ins> // Copyright 2016 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. // @has issue_31899/index.html // @has - 'Make this line a bit longer.' // @!has - 'rust rust-example-rendered' // @!has - 'use ndarray::arr2' // @!has - 'prohibited' /// A tuple or fixed size array that can be used to index an array. /// Make this line a bit longer. /// /// ``` /// use ndarray::arr2; /// /// let mut a = arr2(&[[0, 1], [0, 0]]); /// a[[1, 1]] = 1; /// assert_eq!(a[[0, 1]], 1); /// assert_eq!(a[[1, 1]], 1); /// ``` /// /// **Note** the blanket implementation that's not visible in rustdoc: /// `impl<D> NdIndex for D where D: Dimension { ... }` pub fn bar() {} /// Some line /// /// # prohibited pub fn foo() {} /// Some line /// /// 1. prohibited /// 2. bar pub fn baz() {} /// Some line /// /// - prohibited /// - bar pub fn qux() {} /// Some line /// /// * prohibited /// * bar pub fn quz() {} /// Some line /// /// > prohibited /// > bar pub fn qur() {} /// Some line /// /// prohibited /// ===== /// /// Second /// ------ pub fn qut() {} </ins>

A documentation comment like the one cited verbatim below, produces a main page summary that includes the first line of the code in the example. This is very surprising since there's an empty line in between, and the code example inserts a large colored box in the overview page (the parent module). cc since it's probably related to PR /// A tuple or fixed size array that can be used to index an array. /// /// /// /// Note the blanket implementation that's not visible in rustdoc: /// !


Question: <ins> error[E0277]: the trait bound `T: Clone` is not satisfied --> $DIR/global-cache-and-parallel-frontend.rs:15:17 | LL | #[derive(Clone, Eq)] |                 ^^ the trait `Clone` is not implemented for `T`, which is required by `Struct<T>: PartialEq` | note: required for `Struct<T>` to implement `PartialEq` --> $DIR/global-cache-and-parallel-frontend.rs:18:19 | LL | impl<T: Clone, U> PartialEq<U> for Struct<T> |         -----     ^^^^^^^^^^^^     ^^^^^^^^^ |         | |         unsatisfied trait bound introduced here note: required by a bound in `Eq` --> $SRC_DIR/core/src/cmp.rs:LL:COL = note: this error originates in the derive macro `Eq` (in Nightly builds, run with -Z macro-backtrace for more info) help: consider restricting type parameter `T` | LL | pub struct Struct<T: std::clone::Clone>(T); |                    +++++++++++++++++++ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0277`. </ins>

<!-- 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. --After adding to , I get the ICE. The resulting : The full project: <!-- 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. . --
Looks like another label: +T-types +WG-trait-system-refactor +regression-from-stable-to-nightly
Stable passes, beta passes. Nightly passes with either or Discovered with It does sporadically succeed, thus needing to clean and rerun the build to make sure. Either something is up with or it only barely exercises these conditions in the parallel frontend, even after cleaning and running the build 100 times. Meanwhile, fails something like ~50% of the time on my machine.
stable passes obviously, as -Zthreads this is a unstable nightly-only flag?
Hm, not actually obvious given that works, though I suppose that does mean it isn't a regression per se. :^)
oh I thought you knew by now that this is the forbidden env flag that should only ever be used for bootstrapping and nothing else and we should not even tell users about it. If you set the flag, your "stable" will also eat nightly-only features, but why would that make a "to-stable" regression if you explicitly tell the compiler "please act like you are NOT a stable release"? I don't think it make sense to backport fixes for untable nightly features into stable lol
who mentioned backports?
The label is used to gather regressions between release channels, which are then discussed whether they are backport-worthy or not. Is that not how the label is used?
I don't really think regression-from-stable-to-nightly nor regression-from-stable-to-stable are used for that at all? Probably regression-from-stable-to-beta is?


Question: <ins> error[E0277]: the trait bound `T: Clone` is not satisfied --> $DIR/global-cache-and-parallel-frontend.rs:15:17 | LL | #[derive(Clone, Eq)] |                 ^^ the trait `Clone` is not implemented for `T`, which is required by `Struct<T>: PartialEq` | note: required for `Struct<T>` to implement `PartialEq` --> $DIR/global-cache-and-parallel-frontend.rs:18:19 | LL | impl<T: Clone, U> PartialEq<U> for Struct<T> |         -----     ^^^^^^^^^^^^     ^^^^^^^^^ |         | |         unsatisfied trait bound introduced here note: required by a bound in `Eq` --> $SRC_DIR/core/src/cmp.rs:LL:COL = note: this error originates in the derive macro `Eq` (in Nightly builds, run with -Z macro-backtrace for more info) help: consider restricting type parameter `T` | LL | pub struct Struct<T: std::clone::Clone>(T); |                    +++++++++++++++++++ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0277`. </ins>

Pretty much what the title says, I've narrowed it down to and today's nightly with the following: I've attached some backtraces.
probably duplicate of but made more prevalent by next solver
Is it possible to provide a link to or a snippet of a reproducer? I know it probably happens to various crates, but it still would be nice to have something that reproduces.
See for an attached repro.
The repro case is basically the same as , but with other crates mentioned in the ICE logs from the issue comment.


Question: <ins> error[E0277]: the trait bound `T: Clone` is not satisfied --> $DIR/global-cache-and-parallel-frontend.rs:15:17 | LL | #[derive(Clone, Eq)] |                 ^^ the trait `Clone` is not implemented for `T`, which is required by `Struct<T>: PartialEq` | note: required for `Struct<T>` to implement `PartialEq` --> $DIR/global-cache-and-parallel-frontend.rs:18:19 | LL | impl<T: Clone, U> PartialEq<U> for Struct<T> |         -----     ^^^^^^^^^^^^     ^^^^^^^^^ |         | |         unsatisfied trait bound introduced here note: required by a bound in `Eq` --> $SRC_DIR/core/src/cmp.rs:LL:COL = note: this error originates in the derive macro `Eq` (in Nightly builds, run with -Z macro-backtrace for more info) help: consider restricting type parameter `T` | LL | pub struct Struct<T: std::clone::Clone>(T); |                    +++++++++++++++++++ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0277`. </ins>

Compile with latest Nightly got ICE like below: when compiling in code OS: x86_64-apple-darwin
cc
Wyvern, could you provide some sort of reproducer? A link to some commit in some repository or better yet a smaller stripped down version of it?
Can you provide an example which triggers this behavior?
I'm not sure which commit/PR of lead to this crash, sometimes it compiled successfully, sometimes it not. Add this info to original post, hope to help investigation.
are you running with greater than 1? The cache is broken when used with more than 1 thread (which we should fix)
Sorry, I wasn't clear. I meant a link to your project (the project you are trying to compile) if publicly accessible / not proprietary.
I can hit plenty of these while fuzzing with -Zthreads so yeah its probably that.
Yeah, I think was the culprit. Comment out this option crashes disappears.
the easiest fix to rustc is to just disable this assert when we're using more than 1 thread. I've only it for debugging purposes to detect cases where we unnecessarily recompute cache entries
just hit this while trying to bootstrap with Zthreads :sweat_smile:
cc as this also showed up in your ci test run ^^
When I just disable this assert, all relevant UI tests passed with no other bugs or ICE
samle code that triggers this in around 5 of 6 cases with -Zthreads=16


Question: ("thread_local", Whitelisted, Gated(Stability::Unstable, "thread_local", "`#[thread_local]` is an experimental feature, and does  <del> not currently handle destructors. There is no  corresponding `#[task_local]` mapping to the task  model", </del> <ins> not currently handle destructors.", </ins> cfg_fn!(thread_local))), ("rustc_on_unimplemented", Normal, Gated(Stability::Unstable,

I will like to fix this. What should be the better warning message here? Or I just need to remove the last sentence?
It seems fine to just remove the sentence.
Fixed by


Question: <ins> trait Foo {} impl<T> Foo for T {} fn main() { let array = [(); { loop {} }]; //~ ERROR constant evaluation is taking a long time let tup = (7,); let x: &dyn Foo = &tup.0; } </ins>

<!-- ICE: Rustc '' 'error: internal compiler error: named field access on non-ADT', 'error: internal compiler error: named field access on non-ADT' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: 22 | let buf: &mut [*const dyn Foo] = &mut [&u8, &u8.0, &u32, &u32.0]; [livesymbolsandignoredderivedtraits] finding live symbols in crate [checkmod_deathness] checking deathness of variables in top-level module [analysis] running analysis passes on this crate --
mmh this bisects to cc


Question: // want to keep their span info to improve diagnostics in these cases in a later stage. (true, Some(AssocOp::Multiply)) | // `{ 42 } *foo = bar;` or `{ 42 } * 3` (true, Some(AssocOp::Subtract)) | // `{ 42 } -5` <del> (true, Some(AssocOp::Add)) => { // `{ 42 } + 42 </del> <ins> (true, Some(AssocOp::LAnd)) | // `{ 42 } &&x` (#61475) (true, Some(AssocOp::Add)) // `{ 42 } + 42 // If the next token is a keyword, then the tokens above *are* unambiguously incorrect: // `if x { a } else { b } && if y { c } else { d }` if !self.look_ahead(1, |t| t.is_reserved_ident()) => { </ins> // These cases are ambiguous and can't be identified in the parser alone let sp = self.sess.source_map().start_point(self.span); self.sess.ambiguous_block_expr_parse.borrow_mut().insert(sp, lhs.span);

root: yup-oauth2 - 360 detected crates which regressed due to this; cc <details</details
I think this might have been caused by
I can confirm that is the cause. Patch coming shortly.