jiebi/CodeConvo huggingface dataset:
Change:
// compile-flags: -Z parse-only extern { <del> f(); //~ ERROR expected one of `fn`, `pub`, `static`, `unsafe`, or `}`, found `f` </del> <ins> f(); //~ ERROR expected one of `fn`, `pub`, `static`, or `}`, found `f` </ins> } fn main() {

Discussion:
This code produces "error: expected one of , , , or , found ":
That code sample probably didn't require linking to a playpen, I've made the description and title more useful.
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-67945-1.rs:3:20 | LL | enum Bug<S> { |          - this type parameter LL |     Var = { LL |         let x: S = 0; |                -   ^ expected type parameter `S`, found integer |                | |                expected due to this | = note: expected type parameter `S` found type `{integer}` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
Given this Rust code: A call to generates IR like this on x86_64 Linux: So we have a 12 byte alloca from which we then read 16 bytes.
Isn't this subject to alignment by LLVM?
what do you mean? The alloca is only 12 bytes large. That's also the amount of bytes we write in the , but then we ask to read data for a type that is 16 bytes large. I don't see how alignment is relevant here.
here's a demo: Build without optimizations on x86_64 Linux, and you should be able to observe in the C code, although it hasn't been passed as an argument. The mismatch in the struct type definitions is deliberate to show the problem.
Reading past the end of an alloca has well-defined behavior in LLVM IR. I guess we might end up with false positives if we ever support msan.
are you implying that the generated IR is fine? If so, what is the defined behaviour / where can I read up on that? reads as if it is undefined. Without optimizations, this gives random output: With optimizations, SROA ignores the out-of-bounds read and emits a warning in debug mode, which doesn't seem like it is well-defined behaviour to me either.
Basically, if a pointer points to valid memory, and is sufficiently aligned, you can load bytes up to the alignment... LLVM itself does this at etc. That said, looking a bit more closely, the given testcase performs an "align 8" load from an "align 4" pointer, which is more problematic.
Thanks! That looks like it just assumes that the load won't trap. Part of my concern here is that we might expose additional data this way, like observing in that C code example. Though I guess optimizations might eventually leave the upper 32bits undefined and expose data anyway, so this might be moot. The alignment problem is probably due to bad usage of . Ultimately, we should load and pass the struct elements individually anyway.
This has been fixed, we now only load 12 bytes: instead of . Marking as E-needstest.
Change:
<ins> #[derive(Clone)] struct InGroup<F> { it: It, //~^ ERROR cannot find type `It` in this scope f: F, } fn dates_in_year() -> impl Clone { InGroup { f: |d| d } //~^ ERROR missing field `it` in initializer of `InGroup<_>` } fn main() {} </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. --edit: I reduced some code of a different occurrence and came up with <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --I bisected the regression to / <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Reduced code from another project that also triggers this ICE: `
Cargo-bisetc-rustc points to /
cc and
The error on stable is So it's a case of error-ICE.
After some trying I found out that this will panic for every keyword, that is followed by an unexpected token, in an async function, that returns
Assigning and removing as in the prioritization working group.
I can also reproduce the ICE with the following code:
After investigation, I think I have found the cause of the bug. When we get to the contained in is a , because of the invalid or or any wrong syntax. Then we call which expects a so it panics.
Unless someone gets to it before, but I can get a fix in by if not over the weekend. Though from what I understand about that code it shouldn't be TyKind::Error, it should be Infer/Tuple. interesting...
Potential fix in
A possible duplicate.
Fix in (in progress)
The third time's the charm. More future proof solution:
I was just about to open a new issue when I saw this and it looks like it has been fixed—but since I already typed it out and it might provide further info, here it is: <!-- 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. --or No ICE when: just the return value is omitted just the args are omitted both the return value and args are omitted is replaced with <!-- 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.

--: No ICE on <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I hit a similiar bug... As it is already known and fixed, I won't post a new bug report, but as I already have it, here is my data point: I don't have a minimal example, I just know that I got an error on the following git checkout: <!-- 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 following command triggered the ICE: <details<summary<strongBacktrace</strong</summary<p</p</details
Change:
hir::ImplItemKind::Fn(ref sig, body) => { let mut m = (sig, &self.generics, body, Some(self.defaultness)).clean(cx); if m.header.constness == hir::Constness::Const <del> && !is_min_const_fn(cx.tcx, local_did.to_def_id()) </del> <ins> && is_unstable_const_fn(cx.tcx, local_did.to_def_id()).is_some() </ins> { m.header.constness = hir::Constness::NotConst; }

Discussion:
This is a follow-up on I opened earlier, with the requested minimal reproduction in the form of a simple .
Looks like this is either or cc - do you know what those are doing/why they exist?
It's because of the feature. As long as it's not stable, they don't want the keyword to be displayed, even if the function description is describing a const fn. This is a bit strange.
Yeah, that makes no sense to me at all. I have a crate that is very much nightly-only containing a rather large number of s, and at the moment literally none of them are displayed as such in my documentation because of this, despite the fact that they've never not been and will never not be in the future. I of course cannot disable the flag either as then the crate won't compile, as much of what I'm doing does not fit into the stabilized set of functionality. At the very least, surely there must be some way to make it possible to specifically tell rustdoc to "please always document s as exactly what they are no matter what" without changing this default behaviour if that's not desired?
I think the metric should be 'does this have , not 'is this a function'.
I wonder if this isn't an artifact of the switch when adding support... But in any case, it should be a check over , you're absolutely right.
I wonder if this ever worked ... do you mind trying this with an old version of rustdoc? Preferably before was implemented: cc
I'll try that on my crate later today.
After testing both the example I gave here and my own crate with various nightlies from before was implemented, I can confirm that this problem definitely pre-dates it. There's no difference in how rustdoc behaved.
(apologies to lcnr for the ping)
If this helps at all, whichever version of rustdoc was using on August 1st did document my crate properly, it seems. Only the very latest version, uploaded on September 5th, was documented with the keyword missing. So it's a fairly recent bug, overall.
Ok, so I think I was reading the dates on the PRs a bit wrong when I tested yesterday as far as the timeframe for when was merged.

I just did a whole bunch more one-by-one testing of nightlies from August, and in fact the problem doesn't quite predate which was merged on August 7th. Specifically, the very last nightly to have a rustdoc that documents correctly is . Switching directly from that to from the next day makes the problem appear.
consider using instead which will do it automatically
Well, I already know it's a commit from between the 10th and 11th of August now, at least. Also, doesn't really seem to be designed for scenarios where identifying the problem specifically requires running on a crate and then visually inspecting the generated HTML files...
Change:
opts.error_format, &format!( "Error loading target specification: {}.  <del> Use `--print target-list` for a list of built-in targets", </del> <ins> Run `rustc --print target-list` for a list of built-in targets", </ins> e ), )

Discussion:
<!-- Thanks for filing a bug report ! --Problem <!-- A clear and concise description of what the bug is. --<!-- including what currently happens and what you expected to happen. --It is possible to run tests for various targets using . When given an invalid triple, cargo indicates the user should run for help. However, this is not valid advice. Steps <!-- The steps to reproduce the bug. --the suggested Possible Solution(s) <!-- Not obligatory, but suggest a fix/reason for the bug, --<!-- or ideas how to implement the addition or change --cargo should implement , or the advice should be removed. Notes Output of : cargo 1.40.0 ( 2019-11-22) <!-- Also, any additional context or information you feel may be relevant to the issue. --<!-- (e.g rust version, OS platform/distribution/version, target toolchain(s), release channel.. --$ cargo test --target invalid-target error: failed to run to learn about target-specific information Caused by: process didn't exit successfully: (exit code: 1) --- stderr error: Error loading target specification: Could not find specification for target "invalid-target" | = help: Use for a list of built-in targets $ cargo test --print target-list error: Found argument '--print' which wasn't expected, or isn't valid in this context USAGE: test [OPTIONS] [TESTNAME] [-- <args...] For more information try --help $ ...
This can be confusing but cctually just prints what is saying via :
Yea, this message is printed by , so I have moved this to the rust issue tracker. It seems reasonable to me that it should include before the flag, though maybe the diagnostic people have further thoughts.
Change:
LL | struct Dl<'a, 'b, 'c, T, U, V, M: ThreeWithLifetime<T, 'a, A=(), B=(), U, 'b, C=(), V, 'c>> { |                                                        ^^ | <del> = note: type arguments must be provided before lifetime arguments </del> <ins> = note: lifetime arguments must be provided before type arguments </ins> error: aborting due to 12 previous errors

Discussion:
suggests type parameters should come before lifetime parameters, which is incorrect. The message is emitted here: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I want to try working on this. claim
I've been trying to fix this, but even reversing the arguments to the format didn't seem to do anything. Am I missing something? I also to the error note for testing: And here's the error diff: EDIT: I modified the expected stderr for the test so that it matches how it should look after this is fixed by the way.
I've looked into it a bit more, and it looks like this isn't as simple as I thought at first. I thought it might work if I just reversed the arguments to , but that messes up other things. I think I'll need to rethink this.
Note that I cherry-picked the examples that were incorrect. The diagnostic is correct in other cases. You'll need to investigate a little to work out how best to fix this; one simple solution would be to sort the two with , though I'm not sure if that's the cleanest approach.
Okay, thanks for the info! I'll look into sorting and see if that works :)
I think I've figured out a basic solution. Let me know if there are things I can improve!
Change:
false, ); <del> // HACK: This avoids putting the newly built artifacts in the sysroot if we're using // `download-rustc`, to avoid "multiple candidates for `rmeta`" errors. Technically, that's // not quite right: people can set `download-rustc = true` to download even if there are // changes to the compiler, and in that case ideally we would put the *new* artifacts in the // sysroot, in case there are API changes that should be used by tools.  In practice, // though, that should be very uncommon, and people can still disable download-rustc. if !builder.download_rustc() { let libdir = builder.sysroot_libdir(compiler, target); let hostdir = builder.sysroot_libdir(compiler, compiler.host); add_to_sysroot(&builder, &libdir, &hostdir, &librustc_stamp(builder, compiler, target)); } </del> <ins> let libdir = builder.sysroot_libdir(compiler, target); let hostdir = builder.sysroot_libdir(compiler, compiler.host); add_to_sysroot(&builder, &libdir, &hostdir, &librustc_stamp(builder, compiler, target)); </ins> } }

Discussion:
cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.
Change:
.stdout(Stdio::piped()) .stderr(Stdio::piped()) .env("TARGET", &self.config.target) <del> .env("PYTHON", &self.config.docck_python) </del> <ins> .env("PYTHON", &self.config.python) </ins> .env("S", src_root) .env("RUST_BUILD_STAGE", &self.config.stage_id) .env("RUSTC", cwd.join(&self.config.rustc_path))

Discussion:
Compiletest currently has two different arguments telling it which python to use. Since , both are always the same. We should change it to just one argument to simplify things. Mentoring instructions: Change to be a single argument, then change to use the updated arguments. are you interested in tackling this one too? :) label +A-rustbuild +A-testsuite +E-easy +E-mentor Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
let mut is_valid = true; if let Some(metas) = meta.meta_item_list() { for i_meta in metas { <del> match i_meta.name_or_empty() { sym::attr | sym::no_crate_inject => {} _ => { </del> <ins> match (i_meta.name_or_empty(), i_meta.meta_item()) { (sym::attr | sym::no_crate_inject, _) => {} (_, Some(m)) => { </ins> self.tcx.emit_spanned_lint( INVALID_DOC_ATTRIBUTES, hir_id, i_meta.span(), errors::DocTestUnknown { <del> path: rustc_ast_pretty::pprust::path_to_string( &i_meta.meta_item().unwrap().path, ), </del> <ins> path: rustc_ast_pretty::pprust::path_to_string(&m.path), </ins> }, ); is_valid = false; } <ins> (_, None) => { self.tcx.emit_spanned_lint( INVALID_DOC_ATTRIBUTES, hir_id, i_meta.span(), errors::DocTestLiteral, ); is_valid = false; } </ins> } } } else {

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. --This is a fuzzed test case, found with and minimized with , and did not find any related issues. I was able to reproduce with a compiler I compiled from . <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
label +S-bug-has-mcve
Change:
<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; macro_rules! checker { ($attr_name:ident, $expected:literal) => { #[proc_macro_attribute] pub fn $attr_name(attr: TokenStream, input: TokenStream) -> TokenStream { assert!(attr.to_string().is_empty()); assert_eq!(input.to_string(), $expected); TokenStream::new() } } } checker!(attr_extern, r#"extern "C" { fn ffi(#[a1] arg1: i32, #[a2] ...); }"#); checker!(attr_extern_cvar, r#"unsafe extern "C" fn cvar(arg1: i32, #[a1] mut args: ...) { }"#); checker!(attr_alias, "type Alias = fn(#[a1] u8, #[a2] ...);"); checker!(attr_free, "fn free(#[a1] arg1: u8) { let lam = |#[a2] W(x), #[a3] y| (); }"); checker!(attr_inherent_1, "fn inherent1(#[a1] self, #[a2] arg1: u8) { }"); checker!(attr_inherent_2, "fn inherent2(#[a1] &self, #[a2] arg1: u8) { }"); checker!(attr_inherent_3, "fn inherent3<'a>(#[a1] &'a mut self, #[a2] arg1: u8) { }"); checker!(attr_inherent_4, "fn inherent4<'a>(#[a1] self: Box<Self>, #[a2] arg1: u8) { }"); checker!(attr_trait_1, "fn trait1(#[a1] self, #[a2] arg1: u8);"); checker!(attr_trait_2, "fn trait2(#[a1] &self, #[a2] arg1: u8);"); checker!(attr_trait_3, "fn trait3<'a>(#[a1] &'a mut self, #[a2] arg1: u8);"); checker!(attr_trait_4, "fn trait4<'a>(#[a1] self: Box<Self>, #[a2] arg1: u8, #[a3] Vec<u8>);"); </ins>

Discussion:
As this This is the example proc-macro: This is the test: Run both of result and result are: Formal parameter attributes disappear in proc-macro. Toolchain:
cc
I have a fix in
Change:
error: cannot specialize on trait `Default` <del> --> $DIR/specialization_super_trait.rs:13:1 </del> <ins> --> $DIR/specialization_super_trait.rs:13:9 </ins> | LL | impl<T: Default> SpecMarker for T { <del> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> |         ^^^^^^^ </ins> error: aborting due to previous error

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: <!-- The following is not always necessary. --Ideally the output should not reference the debug format of an internal type <!-- 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. -- modify labels +F-specialization +A-specialization +requires-nightly
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:38:1 | LL | mod a_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)
Change:
<ins> #[track_caller] //~ ERROR `main` function is not allowed to be fn main() { panic!("{}: oh no", std::panic::Location::caller()); } </ins>

Discussion:
Crash occurs in both 1.46.0 beta and in current nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I made the false assumption that this was rustc crashing, but it's actually the binary that crashes upon running it.
Cc We probably just want to ban track caller on main (and maybe any lang item function?)
claim
Same with : results in edit: I think is a more general problem so I won't change that here
Assigning as and removing .
Change:
// Mark all dynamic libraries and executables as compatible with ASLR cmd.arg("-Wl,--dynamicbase"); <ins> // Mark all dynamic libraries and executables as compatible with the larger 4GiB address // space available to x86 Windows binaries on x86_64. if sess.targ_cfg.arch == abi::X86 { cmd.arg("-Wl,--large-address-aware"); } </ins> } if sess.targ_cfg.os == abi::OsAndroid {

Discussion:
This causes them to be restricted to 2GB of address space, even though on 64-bit Windows they could have gotten full 4GB, had they been marked appropriately.