jiebi/CodeConvo huggingface dataset:
Change:
<del> // check-pass trait A { type Assoc; } impl A for () { // FIXME: it would be nice for this to at least cause a warning. type Assoc = Foo<()>; } struct Foo<T: A>(T::Assoc); fn main() {} </del>

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</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium
Change:
<ins> // This test checks that the union keyword // is accepted as the name of an enum variant // when not followed by an identifier // This special case exists because `union` is a contextual keyword. #![allow(warnings)] // check-pass enum A { union } enum B { union {} } enum C { union() } fn main(){} </ins>

Discussion:
Initially reported in and then My best guess is ; cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Interesting note: this does not apply to when in mode.
Regression introduced in . My bad... should have remembered that is contextual! The fix should be to make changes around here: You'll want to use look-ahead to ensure that an identifier follows . Also, add a regression test for , , and .
claim
Error: Parsing assign command in failed: claim Please let know if you're having trouble with this bot.
assign
You'll need to change to something along the lines of
Change:
<ins> // compile-flags: --test // normalize-stdout-test: "src/test/rustdoc-ui" -> "$$DIR" // failure-status: 101 // rustc-env: RUST_BACKTRACE=0 /// ```rust /// let x = 7; /// "unterminated /// ``` pub fn foo() {} </ins>

Discussion:
Doc test with missing closing back quotes fail without any explanation. rust /// let x = 7; /// asserteq!(x, a()); /// // <- HERE /// fn a() -i32 { 7 } rustc 1.35.0-nightly ( 2019-03-22) binary: rustc commit-hash: commit-date: 2019-03-22 host: x8664-unknown-linux-gnu release: 1.35.0-nightly LLVM version: 8.0 rustc 1.33.0 ( 2019-02-28) binary: rustc commit-hash: commit-date: 2019-02-28 host: x86_64-unknown-linux-gnu release: 1.33.0 LLVM version: 8.0
~I believe this is related to . The second <coderust</codeline is unable to be lexed, so the lexer bails with an unbuffered fatal error.~ I was wrong. I have a fix incoming.
Oh hey, this looks to be related to and , cc
Change:
// compile-flags: -O <ins> // FIXME(wesleywiser): Ideally, we could const-prop away all of this and just be left with // `let x = 42` but that doesn't work because const-prop doesn't support `Operand::Indirect` // and `InterpCx::eval_place()` always forces an allocation which creates the `Indirect`. // Fixing either of those will allow us to const-prop this away. </ins> // EMIT_MIR_FOR_EACH_BIT_WIDTH // EMIT_MIR rustc.main.ConstProp.diff fn main() {

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from ./src/test/ui/consts/constconstructor/const-construct- <!-- 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. --rustc @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Might be caused by That should have reduced the number of ICEs, not increased it, but who knows.^^

<!-- 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. --core reduced 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. --: repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This does not reproduce with though, so it's a very recent regression.
` produces the same error it seems.
Change:
match actual.kind() { Uint(_) if op == hir::UnOp::UnNeg => { err.note("unsigned values cannot be negated"); <ins> if let hir::ExprKind::Unary( _, hir::Expr { kind: hir::ExprKind::Lit(Spanned { node: ast::LitKind::Int(1, _), .. }), .. }, ) = ex.kind { err.span_suggestion( ex.span, &format!( "you may have meant the maximum value of `{}`", actual ), format!("{}::MAX", actual), Applicability::MaybeIncorrect, ); } </ins> } Str | Never | Char | Tuple(_) | Array(_, _) => {} Ref(_, ref lty, _) if *lty.kind() == Str => {}

Discussion:
Code: Playground: Error message: Somehow, in one case this in the expression is unsigned, but in the other case it is signed and everything is fine. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
For the compiler has to suggest to replace it with . The compiler should also suggest to replace with , to remove some hard "as" casts from the code.
claim
I think this is more appropriate as a clippy lint, opened
Change:
return } <del> // For the wasm32 target statics with #[link_section] are placed into custom </del> <ins> // For the wasm32 target statics with `#[link_section]` are placed into custom </ins> // sections of the final output file, but this isn't link custom sections of // other executable formats. Namely we can only embed a list of bytes, // nothing with pointers to anything else or relocations. If any relocation // show up, reject them here. <ins> // `#[link_section]` may contain arbitrary, or even undefined bytes, but it is // the consumer's responsibility to ensure all bytes that have been read // have defined values. </ins> let instance = ty::Instance::mono(tcx, id); let cid = GlobalId { instance,

Discussion:
only checks that the link section contains no pointers, but there may be arbitrary bytes in the data, even undefined bytes (e.g. due to padding). cc is that ok? llvm may insert whereever there are undefined bytes. Or should we lint/error on such statics? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
that should be ok yeah, I think that's what happens on all other platforms and it's up to the consumer to ensure that all bytes they read have defined values if they want.
Ok, I guess we should probably just document that in the code segment that I linked above.
claim
Change:
<ins> // normalize-stderr-test: "couldn't read.*" -> "couldn't read the file" #![feature(extended_key_value_attributes)] #![doc = include_str!("../not_existing_file.md")] struct Documented {} //~^^ ERROR couldn't read fn main() {} </ins>

Discussion:
Note that must not exist in order to reproduce this error: The first error is what I would expect, but the second is a bit confusing and weird: Perhaps instead of emitting (/ERROR/)delayspanbug` since an error should have already occurred. If for some reason an error had not already been emitted, the compiler would crash; otherwise, it would just show the original error. Originally posted by in
Note that is stable now (though it hasn't reached the stable channel yet), so this no longer requires a feature flag.
Mentoring instructions: in , check if the token is a and the expression is an error; if so, use instead of .
Hi I was searching for a first issue and i have a question : What does ? Because the function that you pin must return a but has return type Sorry if i misread something
delayspanbug means "if the compiler finishes running without first reporting another error, panic". It's useful here because error tokens should always report in an error being reported. I think anything you return is probably fine as long as it doesn't cause further cascading errors :)
i fixed it but for adding a test case : i run into an edge case the output message of the macro : include_str! is not normalized with $DIR the ui test is working only for me. Have you a tip or i have to create an issue ? Thanks
you can use : https://rustc-dev- But I'm surprised $DIR doesn't work :/ that does seem like a bug.
Sorry I was not clear : the $DIR is working for the But the path is not replace for the error comment in the because the path read by include_str is in the error message
don't put the whole name in the .rs file - you just need to put a substring. Something like .
Change:
<ins> // check-pass trait Zoo { type X; } impl Zoo for u16 { type X = usize; } fn foo(abc: <u16 as Zoo>::X) {} fn main() { let x: *const u8 = foo as _; } </ins>

Discussion:
() Errors: Seems like this should work.
The following works: Switching to be of type itself. Adding , and then switching to be of type
Huh, what if you cast it to ? That works, right?
Adding an intermediate cast to does make it work.
So having a projection in the type, blocks the cast from happening? That's a bit weird. cc
The fnsig function on fn item types is returning unnormalized types directly from the tcx. Defined in The relevant call-site is at
Change:
let dst_bindir = image.join("bin"); t!(fs::create_dir_all(&dst_bindir)); <del> let exe = builder.llvm_out(target).join("bin").join(exe("llvm-config", target)); builder.install(&exe, &dst_bindir, 0o755); </del> <ins> let src_bindir = builder.llvm_out(target).join("bin"); let install_bin = |name| builder.install(&src_bindir.join(exe(name, target)), &dst_bindir, 0o755); install_bin("llvm-config"); install_bin("llvm-ar"); install_bin("llvm-objdump"); install_bin("llvm-profdata"); install_bin("llvm-bcanalyzer"); install_bin("llvm-cov"); </ins> builder.install(&builder.llvm_filecheck(target), &dst_bindir, 0o755); // Copy the include directory as well; needed mostly to build

Discussion:
I recently to in my local repository. In particular, this enables: When running the full test suite with I get three errors similar to this: Maybe the packaging of LLVM downloaded from CI needs to be fixed to include ?
Cc since you're the one who implemented this :)
Yes, that seems right. I did not know we relied on the LLVM tooling -- probably there's a few more tools we need too, will need to check. I imagine it's mostly a matter of just adding them to this section: , they should already be built. I would be happy to take a PR for this.
I can make a patch adding a couple lines for like the ones there for , but can I test it without landing it and waiting for the next Nightly? (I assume testing locally involves compiling LLVM, so I might wait to do that until I have access again to a many-cores desktop rather than just my laptop.)
Hm, sort of. So you will need to post a PR, but then bors try will generate sufficient artifacts to test. You will want to replace with the sha of the try build that bors posts.
might also be necessary but I'm not sure.
I’ll find out! I’ve already started a try build with just : I can temporarily hard-code in for the purpose of testing, but for everyone else the logic is still picking the last commit that touched the submodule, which after lands will still be some commit that does not include Would it make sense to have a "timestamp-ish" file, and pick the last commit that touched either the submodule or that file? That would only be useful until the next LLVM update, though. (Unless we need to tweak thepackaging of the component again.)
Change:
} #[derive(Subdiagnostic)] <del> #[multipart_suggestion(passes_suggestion, applicability = "machine-applicable")] </del> <ins> #[multipart_suggestion(passes_suggestion, applicability = "maybe-incorrect")] </ins> pub struct UnusedVarTryIgnoreSugg { #[suggestion_part(code = "{name}: _")] pub shorthands: Vec<Span>,

Discussion:
For example: I don't like that refactor because I might end up with local variables that do nothing. I think should just ignore unused local variables all together. If just renames local variables to hide the warnings from the compiler, then the compiler lint is a bit pointless. Renaming unused function parameters seems fine.
To get a better understanding of your thought process, why do you feel should treat local variables and function parameters differently here?
For example Now at one point you remove , and then cargo fix will rename to Now you have you might never find this in your code base. You really wanted to remove it, or maybe it was a bug in the first place that you are not using it anymore. Just renaming it for the sake of removing the warning seems wrong. Maybe it should also not rename parameters for free standing functions. I think that there are some cases in functions were you just want to rely on type inference and then the parameter should always be , but I think that decision should come from the programmer. It seems reasonable to rename parameters for trait impls because you can't just change the function signature, and you might not always want to use the parameter.
I think I'm persuaded? Here's where the lint is issued: We just need to change to to tell not to auto-apply the suggestion. We have access to the HIR here, so setting the applicability conditionally based on whether it's a binding or a method argument should be doable, although potentially slightly tricky.
I think you are right, this is misleading in your use case. Just wondering: At which points in your workflow are you running cargo fix? I also think this is one of the cases where we need to differentiate between "cargo fix should fix it" and "get a lightbulb with auto-fix suggestions in your editor". Just because it might be auto-fixable doesn't mean we should automatically fix it. This is a discussion for a higher level issue, though.
I only ran once for a project where I had a few warnings after I did some refactoring.
Is anyone against changing this suggestion to simply be instead of ? Prepending an underscore to variable names is saying to the compiler "yes, I intentionally won't use this value", which should very much be a manual action. I'm hesitant to use , since it might silently hide a bunch of leftover variables from an in-process refactoring. I mostly want it to remove unnecessary parenthesis and fix my imports, this is overreaching a bit.
Change:
<ins> error[E0229]: associated type bindings are not allowed here --> $DIR/no-gat-position.rs:8:56 | LL |     fn next<'a>(&'a mut self) -> Option<Self::Item<'a, As1: Copy>>; |                                                        ^^^^^^^^^ associated type not allowed here error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0229`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: expect 1 RPITITs in call to '', 'thread 'rustc' panicked at 'assertion failed: expect 1 RPITITs in call to '' File: --auto-reduced (treereduce-rust): original: Version information ` <!-- query stack: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of [checkmodimplwf] checking that impls are well-formed in top-level module [analysis] running analysis passes on this crate --
Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details

<!-- 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
Regression in nightly-2023-05-04 commit[0] 2023-05-02: Auto merge of - compiler-errors:attr-query-no-caching, r=cjgillot commit[1] 2023-05-02: Auto merge of - fortanix:raoul/bugfixlibtestjson_synchronization, r=pietroalbini commit[2] 2023-05-03: Auto merge of - nnethercote:restrict-From-for-Diagnostics, r=davidtwco commit[3] 2023-05-03: Auto merge of - weihanglo:update-cargo, r=weihanglo commit[4] 2023-05-03: Auto merge of - jdno:reduce-builder-sizes, r=pietroalbini commit[5] 2023-05-03: Auto merge of - cuviper:ct-ng-1.25, r=pietroalbini commit[6] 2023-05-03: Auto merge of - Dylan-DPC:rollup-0pq0hh3, r=Dylan-DPC
Minimized:
Above example bisects to :thinking:
Change:
<del> warning: `extern` block uses type `*const A<()>`, which is not FFI-safe --> $DIR/improper-types-stack-overflow-130310.rs:16:13 | LL |     fn f(a: *const A<()>); |             ^^^^^^^^^^^^ not FFI-safe | = note: type is infinitely recursive = note: `#[warn(improper_ctypes)]` on by default warning: 1 warning emitted </del>

Discussion:
The windows-rs crate is getting a whole bunch of spurious FFI-safe warnings: See: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc which introduced the recursion limit.
Repro:
Anyways I'll put up a revert PR claim
Change:
// except according to those terms. use super::{Target, TargetOptions}; <ins> use super::emscripten_base::{cmd}; </ins> pub fn target() -> Result<Target, String> { let opts = TargetOptions { <del> linker: "emcc".to_string(), ar: "emar".to_string(), </del> <ins> linker: cmd("emcc"), ar: cmd("emar"), </ins> dynamic_linking: false, executables: true,

Discussion:
After following the steps in the , running gives the following output: See for discussion. believes it to be an issue with invoking without enabling shell expansion.
Invoking fixes the error above, but another error pops up (see below).
Here is a workaround: instead of invoking , invoke . (Wow, it takes a long time—90 seconds until it fails in optimisation for a very basic thing seems inordinate!)
Same, when trying to invoke given command directly, getting instead:
Ah, this seems to be rather related to
Indeed. PR is work in progress. Also emscripten 1.35.0 (latest pre-build binary) does not work (see llvm assertion above). I haven't had the chance to try out emscripten 1.37.0 ()
Yep, that's what was suggested in that other issue and I can confirm it works.
For the sake of completeness, I finally had the time to test everything. This works for windows: Get emscripten 1.37.0: VS 2013 Community (required by emscripten) Rewire rustc to : Workaround for rust 1.14: Fix: PR I guess should check for a minimal required emscripten version, but this is probably out of scope.
Thanks for the investigations and the patch
Looks like the fix is merged.
I get the same error. Unless I run rustc from the same cmd windows I used to run emsdk activate. Running emsdk activate with --global doe not seem to change anything. This may just be how it is intended to work.
Did you run emsdk activate --global in elevated cmd? That's what it would take for it to work and permanently store generated environment variables in registry.
Change:
<ins> error[E0432]: unresolved import `crate::issue_85992_extern_2` --> $DIR/issue-85992.rs:8:5 | LL | use crate::issue_85992_extern_2; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `issue_85992_extern_2` in the root error: aborting due to previous error For more information about this error, try `rustc --explain E0432`. </ins>

Discussion:
Exact code unknown code. The error was generated by using . Rerunning after did not fix this. Did not resolve this yet at the time of writing this. This might be related to: But I think this was because I compiles first and got this error: This was expected to give an error (needed to be ) <details<summary<strongFull backtrace on the fist check:</strong</summary<p</p</details: Problem persists after updating to last nightly: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace (After trying to recheck it)</strong</summary<p</p</details
I just found out the problem exists because of: If I comment out that line it will not report an internal error anymore. I had a function but I also use the crate  I now renamed the function but still getting errors. So it is likely because of a ambiguity issue. Trying to reproduce it in minimal code example, but not yet been able to do so.
After some testing a narrowed it down to the following: : : My guess why this fails: The macro uses inside of it. But when I try to export this it can not find it. commenting out/removing any line will give a normal compile error. I hope this helps to find out the problem. The error always happens and can thus be reliably reproduced. I tested this on latest nightly too:
reduced:
Hi can you assign it to me? I would like to give it a try and solve it.
Change:
/// Returns the current working directory as a [`PathBuf`]. /// <ins> /// # Platform-specific behavior /// /// This function currently corresponds to the `getcwd` function on Unix /// and the `GetCurrentDirectoryW` function on Windows. /// </ins> /// # Errors /// /// Returns an [`Err`] if the current working directory value is invalid.

Discussion:
As of now, the stable and nightly documentation on only states And proceeds to note a couple of errors the function may fail with. This does not mention the fact that (as far as I am aware, testing on Linux) the path is also canonicalized, having resolved all symlinks in any segment of the path. I'd imagine not documenting this behavior could lead to confusion and/or bugs, if it already hasn't. I tried this code within a symlink folder pointing to : I expected to see get the output: Instead, this was output: Currently using the nightly compiler. For obvious reasons, there's no backtrace. Update: Read a bit through the code and realized this behavior might be libc-dependent on my system returns
For UNIX Rust just calls and that behavior is documented in the , so it will be the same on all conforming implementations. We should document which platform-specific function we call here just like we do with other filesystem functions (e.g. ). label T-libs A-docs
It was also missing for so I opened for both.
Thanks a lot