jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: unsizing casts are not allowed in const fn --> $DIR/cast_errors.rs:3:41 | LL | const fn unsize(x: &[u8; 3]) -> &[u8] { x } |                                         ^ error: function pointers in const fn are unstable --> $DIR/cast_errors.rs:5:23 | LL | const fn closure() -> fn() { || {} } |                       ^^^^ error: function pointers in const fn are unstable --> $DIR/cast_errors.rs:8:5 | LL |     (|| {}) as fn(); |     ^^^^^^^^^^^^^^^ error: function pointers in const fn are unstable --> $DIR/cast_errors.rs:11:28 | LL | const fn reify(f: fn()) -> unsafe fn() { f } |                            ^^^^^^^^^^^ error: function pointers in const fn are unstable --> $DIR/cast_errors.rs:13:21 | LL | const fn reify2() { main as unsafe fn(); } |                     ^^^^^^^^^^^^^^^^^^^ error: aborting due to 5 previous errors </ins>

Discussion:
<short summary of the bugReturning from a const fn causes internal compiler error, with the message 'bad input type for cast'. I tried this code: Minimal example Original example I expected to see this happen: program compiles and prints 'Hello 1' or I get a compiler error. Instead, this happened: ICE
that gives the exact backtrace above.
Relavent code: The types here are and .
The actual bug would be here then, right?
Not quite sure, but the real bug is that we allow the keyword in const fn XD I already have a fix since yesterday, but the german bahn didn't give me electricity so my notebook died while tests were running
no ICE fix from the ICE? :p
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-66596-impl-trait-for-str-const-arg.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>

Discussion:
The code: It produced error: Although RFC not yet implemented, this code must work already. Or I'm wrong and this syntax does not supported by const-generics?
Not sure where you see the ICE, removing that.
This is glitch after the previous 2 issues.. It is not ICE.
To Minimal code: produce error: The variant also give this error.
Now it is ICE:
It's back to the original error.
Now it produce this errors:
The behaviour is now as expected. We just need a test now.
Const Generic RFC leads the code as possible: Is there another issue that is tracking it?
Yes, there are some subtle issues about making sure that constants in types are well-formed. The tracking issue for this is
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-66596-impl-trait-for-str-const-arg.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>

Discussion:
This code ran in the latest nightly(2019-11-19) does not compile: And it prints this error message
Reduced:
that gives a different error, because isn't defined. Perhaps you meant something like:
This appears to be working now.
Change:
<ins> error[E0277]: the trait bound `*mut std::ops::Fn() + 'static: std::marker::Sync` is not satisfied in `[std::fmt::ArgumentV1<'_>]` --> $DIR/send-sync.rs:18:5 | 18 |     send(format_args!("{:?}", c)); |     ^^^^ `*mut std::ops::Fn() + 'static` cannot be shared between threads safely | = help: within `[std::fmt::ArgumentV1<'_>]`, the trait `std::marker::Sync` is not implemented for `*mut std::ops::Fn() + 'static` = note: required because it appears within the type `std::marker::PhantomData<*mut std::ops::Fn() + 'static>` = note: required because it appears within the type `core::fmt::Void` = note: required because it appears within the type `&core::fmt::Void` = note: required because it appears within the type `std::fmt::ArgumentV1<'_>` = note: required because it appears within the type `[std::fmt::ArgumentV1<'_>]` = note: required because of the requirements on the impl of `std::marker::Send` for `&[std::fmt::ArgumentV1<'_>]` = note: required because it appears within the type `std::fmt::Arguments<'_>` = note: required by `send` error[E0277]: the trait bound `*mut std::ops::Fn() + 'static: std::marker::Sync` is not satisfied in `std::fmt::Arguments<'_>` --> $DIR/send-sync.rs:19:5 | 19 |     sync(format_args!("{:?}", c)); |     ^^^^ `*mut std::ops::Fn() + 'static` cannot be shared between threads safely | = help: within `std::fmt::Arguments<'_>`, the trait `std::marker::Sync` is not implemented for `*mut std::ops::Fn() + 'static` = note: required because it appears within the type `std::marker::PhantomData<*mut std::ops::Fn() + 'static>` = note: required because it appears within the type `core::fmt::Void` = note: required because it appears within the type `&core::fmt::Void` = note: required because it appears within the type `std::fmt::ArgumentV1<'_>` = note: required because it appears within the type `[std::fmt::ArgumentV1<'_>]` = note: required because it appears within the type `&[std::fmt::ArgumentV1<'_>]` = note: required because it appears within the type `std::fmt::Arguments<'_>` = note: required by `sync` error: aborting due to 2 previous errors </ins>

Discussion:
is only parameterized on lifetime. The types of the captured arguments are erased in the contained . Nothing restricts the aggregate from being or , so by OIBIT it's both. Thus this compiles: I'm not sure if there are any realistic ways to accidentally abuse this, but here's a deliberate example. The spawned thread will read the through the arguments, even while the main thread modifies it.
Change:
LL |     use super::a; |         ^^^^^^^^ | <del> help: consider adding a `#[cfg(test)]` to the containing module </del> <ins> help: if this is a test module, consider adding a `#[cfg(test)]` to the containing module </ins> --> $DIR/unused-imports-in-test-module.rs:58:1 | LL | mod a_tests {

Discussion:
This help message seems weird. I'd expect the help to be more like: Consider adding if you want to silent the lint on the unused import Consider removing the unused import Suggesting to add to the module is the least expected option, and it seems too assertive in its current wording. No response Perhaps the detection for triggering on the module could be smarter and only consider a module as a potential test module if it contains at least one annotated function? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
How can i proceed to solve this any suggestions on how can it be done changes to which file will make it happen since i am new to this repo
Hi thank you for your interest. For now, I think making the help message less assertive would be sufficient. Here are some tips to get you started: will need to find where this help message is emitted. You can identify where this help message is coming from by grepping the repo, i.e. this case, it might be as simple as changing this string to make it sound less assertive. can reformat your changes via . the UI test suite to make sure at least one test fails -- this means at least one test is actually testing this diagnostic. you're happy with the stderr output from your change, re-bless the UI test suite and now make sure the UI test suite passes. to make sure tidy checks passes locally. a PR and wait for review. Your reviewer will discuss with you to see if any further changes are desirable. <https://rustc-dev- the more in-depth reference. If you are stuck, feel free to ask here, or make a new thread in .
claim
(Unless already submitted a change and I didn't find it, I should be able to create a PR soon)
Change:
use rustc::mir::{BasicBlock, Location, Mir}; use rustc::mir::Local; use rustc::ty::{self, Ty, TyCtxt, TypeFoldable}; <ins> use rustc::traits; use rustc::infer::InferOk; </ins> use rustc::util::common::ErrorReported; <ins> use borrow_check::nll::type_check::AtLocation; </ins> use rustc_data_structures::fx::FxHashSet; use syntax::codemap::DUMMY_SP; use util::liveness::LivenessResults;

Discussion:
I'd like to work on this.
This appears to be a regular error, not an ICE.
Change:
let (tx, rx) = channel(); run_test(&TestOpts::new(), false, desc, RunStrategy::InProcess, tx, Concurrent::No); let result = rx.recv().unwrap().result; <del> assert!(result == TrIgnored); </del> <ins> assert_eq!(result, TrIgnored); </ins> } // FIXME: Re-enable emscripten once it can catch panics again (introduced by #65251)

Discussion:
When running this test (): the output is which makes it hard to spot the difference in whitespace characters. Would it be possible to change this to e.g.: This would improve the usability when running into these kinds of test failures and also make it more consistent with which outputs both the left and the right value too.
Agree with having them vertically aligned. I think we do want line endings to create a new line though for multi-line readability. Maybe we should say something like this: (The first difference at char line we might also want to add to assert_eq also?)
The message sounds good, but I am not sure how well it applies to the comparison, as it is not an equality, but a substring comparison. Maybe we could adjust the wording of the error message to e.g.: to make that easier to spot. I think the escaping is essential, take for instance which has no newlines, but contains : On many shells, this will produce this output: which makes it very hard for a user to figure out what's going on (let's assume the happens in a more obscure location). Maybe a more important reason is that escaping would be consistent with the behavior of , which for : outputs: The escaping avoids surprises which could occur depending on the user`s environment.
Ok I'm sold. Do you want to fork rust-lang/rust and submit this as a PR? (If you don't want to I can do the legwork).
Thanks for the offer, I'll try to write a PR and will add you as a reviewer once I have a first version ready.
Change:
scrape_examples_extension: !call_locations.is_empty(), }; let mut issue_tracker_base_url = None; <del> let mut include_sources = true; </del> <ins> let mut include_sources = !html_no_source; </ins> // Crawl the crate attributes looking for attributes which control how we're // going to emit HTML

Discussion:
Kind of related to and the  attribute. The behaviour would be the same as the latter but wouldn't require any source code changes. My use-case here is to generate docs on the CI and reduce the size (400MB just for docs for each version is a bit much), but if people want to generate docs locally they should still be able to get the source code pages if they want. suggested to create an issue for this.
To reduce the global documentation size, I suggested in to group items that don't have impls by kinds. Would require an RFC though. In any case, I think it's a good idea to add an option to have this done in the command line.
Change:
} }, TypeError::Traits(ref exp_found) => { <del> self.tcx.sess.note("errrr0"); </del> report_path_match(exp_found.expected, exp_found.found); }, _ => () // FIXME(#22750) handle traits and stuff

Discussion:
has strange error text: this in , but I'm guessing it was placeholder text that got overlooked during review.
I'm happy to fix this, but not quite clear what it should say ^_^. Not sure if explaining or fixing it would be easier...
We should just remove that line. That's debugging code which should go away. Sorry about that :smiley_cat:
(fixed in )
Change:
<ins> #![crate_type = "lib"] struct S; fn f() { S::A::<f> {} //~^ ERROR ambiguous associated type } </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
Output on 1.46: modify labels: +regression-from-stable-to-stable
Assigning and removing as in the prioritization working group.
Change:
let args = args.as_coroutine(); let yield_ty = args.yield_ty(); let return_ty = args.return_ty(); <del> let self_ty = Ty::new_adt( tcx, tcx.adt_def(tcx.lang_items().pin_type().unwrap()), tcx.mk_args(&[Ty::new_mut_ref(tcx, tcx.lifetimes.re_erased, coroutine_ty).into()]), ); let coroutine_state = Ty::new_adt( tcx, tcx.adt_def(tcx.lang_items().coroutine_state().unwrap()), tcx.mk_args(&[yield_ty.into(), return_ty.into()]), ); (vec![self_ty, args.resume_ty()], coroutine_state, Some(yield_ty)) </del> <ins> (vec![coroutine_ty, args.resume_ty()], return_ty, Some(yield_ty)) </ins> } dk => bug!("{:?} is not a body: {:?}", def_id, dk), };

Discussion:
<!-- ICE: Rustc '' 'error: internal compiler error: unexpected coroutine type Pin<&mut {async fn 3:2}', 'error: internal compiler error: unexpected coroutine type Pin<&mut {async fn 3:2}' 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
regression in ping
Change:
<ins> // See https://github.com/rust-lang/rust/issues/88442 // run-rustfix // edition:2018 // check-pass #![allow(unused)] #![warn(rust_2021_prelude_collisions)] trait AnnotatableTryInto { fn try_into<T>(self) -> Result<T, Self::Error> where Self: std::convert::TryInto<T> { std::convert::TryInto::try_into(self) } } impl<T> AnnotatableTryInto for T where T: From<u8> {} fn main() -> Result<(), &'static str> { let x: u64 = 1; x.try_into::<usize>().or(Err("foo"))?.checked_sub(1); //~^ WARNING trait method `try_into` will become ambiguous in Rust 2021 //~| WARNING this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021! x.try_into::<usize>().or(Err("foo"))?; //~^ WARNING trait method `try_into` will become ambiguous in Rust 2021 //~| WARNING this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021! Ok(()) } </ins>

Discussion:
Given the following code: The lint provides two suggestions, both of which fail with different errors. The first: fails with "type annotations needed" because the generics in the path are lost. The second: fails with "the trait bound is not satisfied". Ideally I think the suggestions should be: Found in the 2021 crate run migrating https://crater-
Looks like the turbofishes are swimming away! grabs turbofish food
Change:
.unwrap_or(Ty::new_misc_error(self.tcx)), ); <del> // FIXME: `probe_for_name_many` searches for methods in inherent implementations, // so it may return a candidate that doesn't belong to this `revr_ty`. We need to // check whether the instantiated type matches the received one. for _matched_method in self.probe_for_name_many( </del> <ins> let Ok(candidates) = self.probe_for_name_many( </ins> Mode::MethodCall, item_name, None,

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'called on an value: NoMatch(NoMatchData { staticcandidates: [], unsatisfiedpredicates: [], outofscopetraits: [], similarcandidate: None, mode: MethodCall })'', 'thread 'rustc' panicked at 'called on an value: NoMatch(NoMatchData { staticcandidates: [], unsatisfiedpredicates: [], outofscopetraits: [], similarcandidate: None, mode: MethodCall })'' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc ^^
claim
Change:
push: &mut dyn FnMut(Annotatable), _is_const: bool, ) { <ins> item.visit_with(&mut DetectNonGenericPointeeAttr { cx }); </ins> let (name_ident, generics) = if let Annotatable::Item(aitem) = item && let ItemKind::Struct(struct_data, g) = &aitem.kind {

Discussion:
I tried this code: I expected to see this happen: compilation failure Instead, this happened: compilation succeeded <!-- 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. --: cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Oops sorry. You can continue with your PR.
Change:
## Input format <del> Rust input is interpreted as a sequence of Unicode codepoints encoded in UTF-8, normalized to Unicode normalization form NFKC. </del> <ins> Rust input is interpreted as a sequence of Unicode codepoints encoded in UTF-8. </ins> Most Rust grammar rules are defined in terms of printable ASCII-range codepoints, but a small number are defined in terms of Unicode properties or explicit codepoint lists. [^inputformat]

Discussion:
From The Rust Reference Manual; However, NFKC requires to transform some characters into different ones even in strings or comments and then we will get different results on such cases. Even NFC have some problems if we have to preserve a text strictly. (yes, the word different is ambiguous; in NFKC, they are treated as the same, but the glyphs of them are different... sometimes depends on the font, though) I'd suggest to remove the "normalized to NFKC" clause and leave the input, like golang. From The Go Programming Language Specification:
We actually don't do any normalization of source input right now, the manual is just plain wrong in claiming it. A PR removing that sentence would probably be welcomed.
the text requires that we, programmers, must normalize our source code before the compilation IMHO, so I would ask whether it is really needed.
That's not what the manual is saying, the manual is saying that it normalizes input. We haven't decided if normalizing input is the correct thing to do yet, though. , OGINO Masanori :
Thank you for clarifying. Why is the spec saying so?
probably because there is precedent in other languages for doing such normalization, at least for identifiers. (Though if the spec implies doing it in string constants, then that is probably just sloppiness in the writing of the spec.) Related bug: update: To clarify, graydon originally wanted to do NFKC normalization in the lexer (as noted in the bug above), but he changed his mind and so we have been in a bit of a state of limbo ever since. But as I said above, the scope of that normalization was, I think, intended to be restricted to identifiers, not all lexical syntax (i.e. not the interior of string constants).
Thank you. I agree on the normalization for identifiers. I think it is acceptable. Certainly some similar but different identifiers treated as the same ones, but we should not do such cheat. (NFKC vs. NFC problem remains, though) I think it is good to update the spec to specify that we may normalize identifiers for ease of comparison/collation.
Change:
/// Iterates over all the stability attributes in the given crate. pub fn get_lib_features(&self) -> Vec<(ast::Name, Option<ast::Name>)> { <ins> // FIXME: For a proc macro crate, not sure whether we should return the "host" // features or an empty Vec. Both don't cause ICEs. </ins> self.root .lib_features .decode(self)

Discussion:
: : Steps to reproduce: This is failing when the crate attempts to import the crate (which is a crate). That is, if I modify 's file to only contain: rustc will ICE. <details<summaryBacktrace:</summary</details
I suspect this is a duplicate of , but I only count 2 #[procmacro] and 1 #[procmacro_attribute] in the repository.
The crate only has 1 and 1 . If I comment both of them out, the compiler still ICEs. The crate used to compile a couple weeks ago, so this was a fairly recent change.
To give some bounds on this: the crate compiles with . It fails with . I would bisect this with rustup to determine which nightly the issue started with, but .
Derp, I just remembered I could remove the component. Okay, doing that, I was able to bisect the nightlies: Last working version: First failing version:
I just did a git bisect, and it looks like commit (from PR ) is the source of the breakage. cc
visited for triage. Going to try to followup with . Assigning to self to keep myself honest about that claim.
also, P-high
Am looking at this.
Minified: // #[allow(unused)] // enum ProcMacroHack { // Input = (stringify!(ARGS), 0).1, // } // The problem is caused by containing "host" defids and being used in [trans]. I don't think that this field has any business containing host libraries when compiling a proc macro, but I'll ask for confirmation. [trans]:
visited for triage. Seems like PR handles this. Leaving as P-high
Change:
LL |     use super::a; |         ^^^^^^^^ | <del> help: consider adding a `#[cfg(test)]` to the containing module </del> <ins> help: if this is a test module, consider adding a `#[cfg(test)]` to the containing module </ins> --> $DIR/unused-imports-in-test-module.rs:8:1 | LL | mod test {

Discussion:
This help message seems weird. I'd expect the help to be more like: Consider adding if you want to silent the lint on the unused import Consider removing the unused import Suggesting to add to the module is the least expected option, and it seems too assertive in its current wording. No response Perhaps the detection for triggering on the module could be smarter and only consider a module as a potential test module if it contains at least one annotated function? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
How can i proceed to solve this any suggestions on how can it be done changes to which file will make it happen since i am new to this repo
Hi thank you for your interest. For now, I think making the help message less assertive would be sufficient. Here are some tips to get you started: will need to find where this help message is emitted. You can identify where this help message is coming from by grepping the repo, i.e. this case, it might be as simple as changing this string to make it sound less assertive. can reformat your changes via . the UI test suite to make sure at least one test fails -- this means at least one test is actually testing this diagnostic. you're happy with the stderr output from your change, re-bless the UI test suite and now make sure the UI test suite passes. to make sure tidy checks passes locally. a PR and wait for review. Your reviewer will discuss with you to see if any further changes are desirable. <https://rustc-dev- the more in-depth reference. If you are stuck, feel free to ask here, or make a new thread in .
claim
(Unless already submitted a change and I didn't find it, I should be able to create a PR soon)