jiebi/CodeConvo huggingface dataset:
Change:
use std::env; use std::process; <del> use rustc_driver::abort_on_err; </del> <ins> use rustc_driver::{abort_on_err, describe_lints}; </ins> use rustc_errors::ErrorReported; use rustc_interface::interface; use rustc_middle::ty::TyCtxt;

Discussion:
I tried this code: I expected to see this happen: Rustdoc prints a list of all lints, the same way rustc does. Instead, this happened: Rustdoc ignored the flag. <!-- 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. --: rustdoc 1.53.0-nightly ( 2021-04-03) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
option is parsed into , but is then ignored: It should be pretty straightforward to instead call when this flag is set. claim
Make sure you call init_lints first, or it will be missing rustdoc's own lints.
Re adding a test for this... is there any way to have check only for whether some substring appears within stderr? Else every time a lint is /removed, or its level modified, the test will need updating—which seems far too brittle to me?
I mean, personally that seems ok to me as long as you can update it with . But if you think it's a hassle you could use .
Change:
<ins> warning: attribute should be applied to a free function, impl method or static --> $DIR/extern-no-mangle.rs:24:5 | LL |     #[no_mangle] |     ^^^^^^^^^^^^ ... LL |     let x = 0_u8; |     ------------- not a free function, impl method or static | note: the lint level is defined here --> $DIR/extern-no-mangle.rs:1:9 | LL | #![warn(unused_attributes)] |         ^^^^^^^^^^^^^^^^^ = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! warning: `#[no_mangle]` has no effect on a foreign static --> $DIR/extern-no-mangle.rs:11:5 | LL |     #[no_mangle] |     ^^^^^^^^^^^^ help: remove this attribute ... LL |     pub static FOO: u8; |     ------------------- foreign static | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: symbol names in extern blocks are not mangled warning: `#[no_mangle]` has no effect on a foreign function --> $DIR/extern-no-mangle.rs:16:5 | LL |     #[no_mangle] |     ^^^^^^^^^^^^ help: remove this attribute ... LL |     pub fn bar(); |     ------------- foreign function | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: symbol names in extern blocks are not mangled warning: 3 warnings emitted </ins>

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: no warning. Instead, this happened: ~The attribute is actually applied correctly, otherwise we would get undefined symbol error.~ Also, the extern variable is clearly declared as static, so the warning does not really make sense. Edit: it seems that the code also works without the attribute. So is the attribute actually not needed? Anyway, the warning about is confusing. This problem occurred in our embedded project , where the static global variables are used to provide references to linker symbols. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.47 stable. Haven't tried newer nightly. : modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
No, this is working correctly. does nothing on extern items, which already do not get mangled, even without the attribute.
OK, sorry for not understanding the behavior of on extern items.
So maybe this should not be marked as regression, this is just a confusing but indeed correct warning message. Is there a way to remove the labels?
claim
Change:
// Run it. match visitor.visit_value(op) { Ok(()) => Ok(()), <del> // We should only get validation errors here. Avoid other errors as // those do not show *where* in the value the issue lies. </del> <ins> // Pass through validation failures. </ins> Err(err) if matches!(err.kind, err_ub!(ValidationFailure { .. })) => Err(err), <ins> // Also pass through InvalidProgram, those just indicate that we could not // validate and each caller will know best what to do with them. Err(err) if matches!(err.kind, InterpError::InvalidProgram(_)) => Err(err), // Avoid other errors as those do not show *where* in the value the issue lies. </ins> Err(err) => bug!("Unexpected error during validation: {}", err), } }

Discussion:
The lint should fire on the following code, but it does not: (This testcase now exists in-tree as a FIXME in .) Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'd like to take this. claim
I have some plans to follow-up on with some cleanup. That might at least partially resolve this issue here. So it's probably best to wait until after that is done.
All right, landed, so what I planned here is done. The remaining issue is about associated consts. The issue there is that fails, or maybe we are hitting an , but I have not tried further. The issue is all yours, :)
Great! I'll start investigating.
Never mind, that one is already fixed on beta.
got reverted in , so we have to reopen this.
Change:
<ins> // Test that `variant_count` only gets evaluated once the type is concrete enough. #![feature(variant_count)] pub struct GetVariantCount<T>(T); impl<T> GetVariantCount<T> { pub const VALUE: usize = std::mem::variant_count::<T>(); } const fn check_variant_count<T>() -> bool { matches!(GetVariantCount::<T>::VALUE, GetVariantCount::<T>::VALUE) //~^ ERROR constant pattern depends on a generic parameter //~| ERROR constant pattern depends on a generic parameter } fn main() { assert!(check_variant_count::<Option<()>>()); } </ins>

Discussion:
For example: Similar to , but with a different intrinsic. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We can probably just put call in front of that if statement. A more precise way to implement this would be to exhaustively match on and forbid , , , , and here. This way we the intrinsic can still be evaluated for which is probably desirable.
claim
Hello, I'm interested in taking the desirable approach. How is the arm for variants like should be handled? Which macro is more appropriate for this situation?
I quickly grepped for and ended up with here. That only works once you know what to search for though.
Change:
.span_to_snippet(self.prev_token.span) .map_or(false, |snippet| snippet == "}") && self.token.kind == token::Semi; <del> let semicolon_span = self.token.span; </del> <ins> let mut semicolon_span = self.token.span; if !is_unnecessary_semicolon { // #105369, Detect spurious `;` before assoc fn body is_unnecessary_semicolon = self.token == token::OpenDelim(Delimiter::Brace) && self.prev_token.kind == token::Semi; semicolon_span = self.prev_token.span; } </ins> // We have to bail or we'll potentially never make progress. let non_item_span = self.token.span; let is_let = self.token.is_keyword(kw::Let);

Discussion:
When copying bounds from a trait assoc item, you can accidentally copy the semicolon. If you forget to remove it, multiple errors are emitted, while the second is: This should be explicitly handled to avoid knock down errors. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
} fn write_code(out: &mut String, src: &str) { <del> Classifier::new(src).highlight(&mut |highlight| { </del> <ins> // This replace allows to fix how the code source with DOS backline characters is displayed. let src = src.replace("rn", "n"); Classifier::new(&src).highlight(&mut |highlight| { </ins> match highlight { Highlight::Token { text, class } => string(out, Escape(text), class), Highlight::EnterSpan { class } => enter_span(out, class),

Discussion:
I tried to document and publish my Windows crate to github pages. Things went pretty smooth until I opened the source code view. As you can see below, a newline is appended to each line doc comment, also no line number for each line: ! Here the render page on gh-pages: Beware that it has no version control for the generated doc. But the link here may work for a limited time before github purge the cache: Also here the the CI script I used: The same code published on is normal: : x86_64-pc-windows-msvc rustc 1.48.0-nightly ( 2020-09-04) modify labels: T-rustdoc
Could be related to normalization depending on the git checkout settings of the runner.
I set before , maybe this is my misconfigure somehow.
Try adding and possibly to make those files end with the right character.
Thanks Andy, I tried as you told but still the issue remains.
Oh, I meant for the source files, you might need to reconfigure git before checking out the source (and that's likely just a workaround, this seems likely to be a bug in rustdoc's handling of in source files).
Thank you, problem is solved in . I am pretty sure this issue is a duplicate of another, but I cannot find it. You could close this issue if you see fit.
(keywords cause I keep failing to search for this: dos line endings)
This is a recent regression, it was introduced sometime between and . I suspect is related, cc
The issue is that is being marked as a doc-comment:
I guess this means is being marked as a ? I don't see why it would.
My test was wrong.
This is not actually correct - it was a blank line in the original source code. The issue is that rustdoc used to strip in newlines, but no longer does. Here's 1.47: and 1.48:
Change:
<ins> error[E0369]: binary operation `==` cannot be applied to type `for<'r> fn(&'r i32) -> &'r i32 {foo}` --> $DIR/issue-77910-2.rs:7:12 | LL |     if foo == y {} |        --- ^^ - _ |        | |        for<'r> fn(&'r i32) -> &'r i32 {foo} error: aborting due to previous error For more information about this error, try `rustc --explain E0369`. </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It also fails for every comparison of and
I found another potentially related weirdness: This fails with: But this (without the argument) fails with a different error, even though there should be no difference as is not used: EDIT: Apparently this is intended behavior, see .
searched nightlies: from nightly-2019-01-01 to nightly-2020-10-13 regressed nightly: nightly-2020-05-03 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Darn, is it really the bitcode commit again? Or did it happen sometime around then? Cc
This bisection is incorrect due to:
Marking this as P-
claim
You have to write if you want to assign this issue.
Thanks bro. claim
Change:
//~| HELP provide a type for the item //~| SUGGESTION C: i32 <ins> const D = &&42; //~^ ERROR missing type for `const` item //~| HELP provide a type for the item //~| SUGGESTION D: &&i32 </ins> static S = Vec::<String>::new(); //~^ ERROR missing type for `static` item //~| HELP provide a type for the item

Discussion:
I'm seeing an internal compiler error on the following input (found by ): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Report from : searched nightlies: from nightly-2020-03-09 to nightly-2020-03-31 regressed nightly: nightly-2020-03-20 searched commits: from to regressed commit:
This is presumably due to -- cc
This was . Tagging it as . Not removing nomination until we can assign this issue.
assign (assigning based on claim that this was injected by PR )
This is the feature where for a with a missing type will look at the body and get the type from there. We should replace all regions in that situation with , just so the code which ICEs here will continue to ICE for legitimate bugs.
Doesn't reproduce with ( ):
Hmmmm, I'm not sure I agree with that assessment, unless -- well -- I guess you're saying that the "correct static type" for any such expression would be anyway?
yes, this is recovery for a guaranteed error, after all. A slightly more aggressive example: Results in this query stack for the ICE: I have no idea why changing to changes anything but they should both ICE IMO (before we switch to replacing erased regions with ). I'm now worried there are other places in which is used to extract some type and "export" it outside of the context of the body, without the necessary precautions.
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/types-mismatch-const-args.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default error[E0308]: mismatched types --> $DIR/types-mismatch-const-args.rs:13:41 | LL |     let _: A<'a, u32, {2u32}, {3u32}> = A::<'a, u32, {4u32}, {3u32}> { data: PhantomData }; |                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `2u32`, found `4u32` | = note: expected type `A<'_, _, 2u32, _>` found type `A<'_, _, 4u32, _>` error[E0308]: mismatched types --> $DIR/types-mismatch-const-args.rs:15:41 | LL |     let _: A<'a, u16, {2u32}, {3u32}> = A::<'b, u32, {2u32}, {3u32}> { data: PhantomData }; |                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected u16, found u32 | = note: expected type `A<'a, u16, _, _>` found type `A<'b, u32, _, _>` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
This code (): results in with missing const arguments in the at the bottom.
Hey guys could I take this on?
Just FYI, same problem with messages involving const generics and matches, e.g. () Also for functions: ()
Interestingly, when I use concrete types for the function example, things display properly: gives ()
you're welcome to look into fixing this! However, I'm not sure what might be causing this problem, so I don't have any suggestions for where to start looking yet.
I spent a few hours doing some digging and I can't find anything yet as well, though I'm as of yet still quite unfamiliar with the code-base. I might have more time tomorrow to look things over again, or maybe the day after.
Change:
<ins> // Check what happens when `fun` is used to define a function, instead of `fn` // edition:2021 #![allow(dead_code)] fun foo() {} //~^ ERROR expected one of `!` or `::`, found `foo` //~^^ HELP write `fn` instead of `fun` to declare a function fn main() {} </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: Ideally the error message should suggest replacing or with . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
New to rustc community and wants to contribute code. there any options to debug rustc which line of which file the error abort happens? can I dump the hierarchy tree for debugging use? C++ we usually use env for compiler debugging. How do rustc often use? Very newbie questions, thank you in advance.
label +E-easy +E-mentor Welcome to Rust! This might be some help -- This issue is very similar to , so take a peek at the diff there. IMO the following tokens are enough to check against function (Julia/JavaScript/etc) func (Go) fun (Kotlin) def (Python) Have fun! <3
Instructions -- Add a check if prevtoken is either ///etc Emit a message, something along the lines of "use instead of <prevtokento make a function" using , there are a few usages of this in the same file so those might be good examples. Add tests for this in -- Ideally each suggestion would have a test. Should be helpful to take as a reference
We can include if necessary.
Hi guys, another rust newbie looking for something easy to get started here. are you still on this or could go with my attempt here?

ypprog does seem to be active and it hasn't been that long, if you'd like you can pick another issue. =) Try going through the E-Easy and/or E-Mentor category for easy issues. However, to clarify, if an issue which is claimed doesn't seem to have any work done for a long period of time (A month or so is a good amount of time) -- Feel free to ping the assignee to confirm and handle it accordingly.
With these changes, I also think it is important to implement improved error messages for when a user puts the return type at the start of the function instead of the end. Given this code: The error output is:
I feel like adding might also be helpful for C++ developers :)
Is this still being worked on?
release-assignment
claim
Change:
<ins> // check-pass // See issue #85526. // This test should produce no warnings. #![deny(missing_docs)] //! Crate docs #[doc(hidden)] pub struct Foo; impl Foo { pub fn bar() {} } fn main() {} </ins>

Discussion:
I tried : I expected to see this happen: no warnings, and its method are not publicly documented. Instead, this happened: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Looks like the context here could give us the information needed to determine 1) if the item is an associated function definition, and 2) if the type on which it is implemented itself has the attribute.
Change:
Some(tcx.closure_base_def_id(def_id)) } Node::Item(item) => match item.kind { <del> ItemKind::OpaqueTy(hir::OpaqueTy { impl_trait_fn, .. }) => impl_trait_fn, </del> <ins> ItemKind::OpaqueTy(hir::OpaqueTy { impl_trait_fn, .. }) => { impl_trait_fn.or_else(|| { let parent_id = tcx.hir().get_parent_item(hir_id); if parent_id != hir_id && parent_id != CRATE_HIR_ID { debug!("generics_of: parent of opaque ty {:?} is {:?}", def_id, parent_id); // If this 'impl Trait' is nested inside another 'impl Trait' // (e.g. `impl Foo<MyType = impl Bar<A>>`), we need to use the 'parent' // 'impl Trait' for its generic parameters, since we can reference them // from the 'child' 'impl Trait' if let Node::Item(hir::Item { kind: ItemKind::OpaqueTy(..), .. }) = tcx.hir().get(parent_id) { Some(tcx.hir().local_def_id(parent_id)) } else { None } } else { None } }) } </ins> _ => None, }, _ => None,

Discussion:
Uncommenting the features and running in Nightly makes the complaints about unstable features go away while the panick stays. ~I’m not sure yet how to make a smaller example out of this.~ smaller examples in comments below This code was a step of me trying out if I could turn into a trait to get method syntax. () Errors:
Minimized:
Ah, neat, so it has nothing to do with closures or Fn traits.
T-compiler triage: I'm going to assume from 's self-assignment that this does not require discussion at T-compiler meeting. Removing I-nominated label.
Are nested type-alias-impl-traits even allowed by the RFC? If not, we should check and emit an error we we construct the type.
They are
any ideas how I can get my original example running though? I was starting with this function (which does compile) and wanted to give a name to its return type. The straightforward approach seems to be But the compiler is still unhappy with lifetimes currently, after your fix. I'm getting the following. At least it works without the lifetimes (i.e. after removing parametrization over 'a and replacing all occurrences of 'a with 'static).
Also I'm now (self-compiled master with the fix) getting a panic on this (admittedly incorrect) program: which didn't panic on the latest nightly (2020-02-13). Edit: I double checked: the behavior changes precisely over your 2 commits. Message is:
Can you open separate issues for each of those problems?
Okay, done ^^ (, )
Change:
// just peeks and looks for that attribute. use crate::session::Session; <ins> use core::num::IntErrorKind; use rustc::bug; </ins> use rustc_span::symbol::{sym, Symbol}; use syntax::ast; use rustc_data_structures::sync::Once; pub fn update_limits(sess: &Session, krate: &ast::Crate) { <del> update_limit(krate, &sess.recursion_limit, sym::recursion_limit, 128); update_limit(krate, &sess.type_length_limit, sym::type_length_limit, 1048576); </del> <ins> update_limit(sess, krate, &sess.recursion_limit, sym::recursion_limit, 128); update_limit(sess, krate, &sess.type_length_limit, sym::type_length_limit, 1048576); </ins> } <del> fn update_limit(krate: &ast::Crate, limit: &Once<usize>, name: Symbol, default: usize) { </del> <ins> fn update_limit( sess: &Session, krate: &ast::Crate, limit: &Once<usize>, name: Symbol, default: usize, ) { </ins> for attr in &krate.attrs { if !attr.check_name(name) { continue; } if let Some(s) = attr.value_str() { <del> if let Some(n) = s.as_str().parse().ok() { limit.set(n); return; </del> <ins> match s.as_str().parse() { Ok(n) => { limit.set(n); return; } Err(e) => { let mut err = sess.struct_span_err( attr.span, "`recursion_limit` must be a non-negative integer", ); let value_span = attr .meta() .and_then(|meta| meta.name_value_literal().cloned()) .map(|lit| lit.span) .unwrap_or(attr.span); let error_str = match e.kind() { IntErrorKind::Overflow => "`recursion_limit` is too large", IntErrorKind::Empty => "`recursion_limit` must be a non-negative integer", IntErrorKind::InvalidDigit => "not a valid integer", IntErrorKind::Underflow => bug!("`recursion_limit` should never underflow"), IntErrorKind::Zero => bug!("zero is a valid `recursion_limit`"), kind => bug!("unimplemented IntErrorKind variant: {:?}", kind), }; err.span_label(value_span, error_str); err.emit(); } </ins> } } }

Discussion:
The following code since it exceeds the default recursion limit. Using as the recursion limit works as expected. This is because we don't check for integer overflow errors when parsing limits: There's a few options here. My preference would be to silently default to when overflow occurs. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi! I'd like to try and handle this. If I understand this correctly, we should check if there is an , and if that error is an overflow. If it's an overflow, we default to ? claim
correct