jiebi/CodeConvo huggingface dataset:
Change:
err: &mut Diagnostic, source: PathSource<'_>, span: Span, <del> ) { </del> <ins> ) -> bool { </ins> if let PathSource::Expr(_) = source && let Some(Expr { span: expr_span,

Discussion:
Given the following code: The current output is: Ideally the output should look like: How do we remove other diagnostics in this scenario?
label +D-verbose
Change:
<ins> //@ check-pass //@ edition:2021 // https://github.com/rust-lang/rust/issues/123573#issue-2229428739 pub trait Test {} impl<'a, T: 'a> Test for &[T] where &'a T: Test {} fn main() { struct Local {} impl Test for &Local {} //~^ WARN non-local `impl` definition } </ins>

Discussion:
Sorry, I don't have simple code to reproduce the issue, because the project is large. The repro is this: Contents of the mentioned file is: I tried increasing , did not help. Also works on stable. This may be duplicate of because timing.
This is also affecting :
Using the starlark-rust repro, this bisects to
overflow is fatal in the old trait solver, so by proving additional goals, especially if they have inference variables, we can end up with new sources of overflow causing an error. the most straightforward fix is to use the new solver for this lint given that the lint uses an empty environment it uses pretty much the same parts of the solver as coherence so it should already be ready for that
WG-prioritization assigning priority (). label -I-prioritize +P-high
I have a somewhat minimal repro, it has a lot of deps (via bevy) but not much code: Where is not something (I think) that can be decomposed into a tuple.
Change:
// relocations (we have an active `str` reference here). We don't use this // result to affect interpreter execution. let slice = data.inspect_with_uninit_and_ptr_outside_interpreter(start..end); <del> let s = std::str::from_utf8(slice).expect("non utf8 str from miri"); p!(write("{:?}", s)); </del> <ins> p!(write("{:?}", String::from_utf8_lossy(slice))); </ins> Ok(self) } (ConstValue::ByRef { alloc, offset }, ty::Array(t, n)) if *t == u8_type => {

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 <!-- 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
Heh, I guess wasn't fixed after all. I wonder when it regressed.
That label is for , I do not think it is the right one here.
cargo bisect rustc says this regressed in Perhaps ?
Untagging as a regression, this requires nightly (const generics).
The bug no longer needs the to trigger.
Change:
pub fn offset(&self, i: usize) -> Size { match *self { <del> FieldPlacement::Union(_) => Size::ZERO, </del> <ins> FieldPlacement::Union(count) => { assert!(i < count, "tried to access field {} of union with {} fields", i, count); Size::ZERO } </ins> FieldPlacement::Array { stride, count } => { let i = i as u64; assert!(i < count);

Discussion:
cc I suspect (but have not verified) that this would be fixed by a backport of
was merged in October, I don't think it's related
Does this need an mcve?
Yeah, but I think at this point a bisection might be more helpful since we're not yet sure what caused this.
Here's a somewhat small-ish MCVE: Haven't managed to remove mio yet, but that's just a matter of time ;) Note, that this doesn't depend on the feature. You can use as well.
Here's a "M"CVE without any dependencies: regression in nightly-2020-01-11 <details<summaryBacktrace</summary</details modify labels: -E-needs-bisection -E-needs-mcve
searched nightlies: from nightly-2019-11-01 to nightly-2020-02-16 regressed nightly: nightly-2020-01-11 searched commits: from to regressed commit: source code: Reproduce bisection with: <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details<details<summaryERROR BEFORE ICE REGRESSION</summary<p</p</details
It would be good to continue the bisection into the rollup PR, among the following PRs: (Point at opaque and closure type definitions in type errors) (Reduce special treatment for zsts) (Parse the syntax described in RFC 2632) (rustcastlowering: misc cleanup & rustc dep reductions) (Extend support of in type parameters) (expect after / )
triage: P-high, removing nomination, assigning to self.
Given the backtrace, I think it's probably (Reduce special treatment for zsts)
I can indeed reproduce the ICE at , seems to be the culprit. cc <details<summaryBacktrace</summary</details
Here is a more minimal MCVE: /me needs to invest some time in tools like rust-reduce or creduce...
Okay so now we have two different PR's to fix this. PR is almost certainly the right call for nightly itself. My only Question is whether we should also land PR and also then backport that to beta. My argument for why is that it is "obviously" less risky, which is important because the beta is going to be imminently promoted to stable.
Change:
// This will fail if the path isn't converted to verbatim. path.push("a"); fs::create_dir(&path).unwrap(); <ins> // #90940: Ensure an empty path returns the "Not Found" error. let path = Path::new(""); assert_eq!(path.canonicalize().unwrap_err().kind(), crate::io::ErrorKind::NotFound); </ins> }

Discussion:
I tried this code: I expected to see this happen: returns os error 3 () Instead, this happened: it returns os error 123 () This is problematic as doesn't become but , which isn't useful for most users. Other platforms like Linux return so the former behavior should be correct here. : The issue doesn't happen on , I think the regression was introduced by .
Thanks for finding and fixing that! I do think that should be mapped to an . It means "The filename, directory name, or volume label syntax is incorrect". So a syntax error basically. But I don't think that should block your current PR.
Sounds good, maybe it should be ? (EDIT: Opened )
is it intentional that E-medium is instead of P-medium?
Oh oops.
Change:
<ins> // build-fail // compile-flags: --target i686-unknown-linux-gnu --crate-type lib // needs-llvm-components: x86 #![feature(no_core, lang_items)] #![allow(internal_features)] #![no_std] #![no_core] // 0x7fffffff is fine, but after rounding up it becomes too big #[repr(C, align(2))] pub struct Example([u8; 0x7fffffff]); pub fn lib(_x: Example) {} //~ERROR: too big for the current architecture #[lang = "sized"] pub trait Sized {} #[lang = "copy"] pub trait Copy: Sized {} </ins>

Discussion:
rustc generally detects when a static type is larger than bytes, giving an error that + 10x80000000isize::MAX + 1`): (The is to ensure that an object of size is actually created on the stack.) This is clearly unsound, since it breaks the size invariant of , and since third-party crates may depend on types being no larger than for soundness. However, it's nontrivial to observe unexpected behavior from this using only safe APIs in the standard library, since placing the overlarge type within any other type, even a wrapper, will result in a compile error as expected, and the standard APIs tend to refer to when creating a slice from a reference.
Wow, good catch! Looks like we're doing the check before rounding up to the next multiple of alignment? That's bad.
Change:
use std::fs::File; use std::path::{Path, PathBuf}; <del> use rustc_session::Session; </del> use rustc_codegen_ssa::back::archive::ArchiveBuilder; <ins> use rustc_session::Session; </ins> use rustc_data_structures::temp_dir::MaybeTempDir; <del> use rustc_middle::middle::cstore::DllImport; </del> <ins> use rustc_session::cstore::DllImport; </ins> struct ArchiveConfig<'a> { sess: &'a Session,

Discussion:
The following code from the manual fails with rustboot .
How embarrassing. Thanks for the report, I'll look into it.
Fix mem op= mem bug in (via not terribly good fix). Closed by .
Change:
<ins> error: free static item without body --> $DIR/issue-83907-invalid-fn-like-path.rs:3:1 | LL | static STATIC_VAR_FIVE: &One(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^- |                               | |                               help: provide a definition for the static: `= <expr>;` error[E0412]: cannot find type `One` in this scope --> $DIR/issue-83907-invalid-fn-like-path.rs:3:26 | LL | static STATIC_VAR_FIVE: &One(); |                          ^^^ not found in this scope error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0412`. </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</details
From
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
Change:
<ins> use std::mem::size_of; struct Foo<'s> { //~ ERROR: parameter `'s` is never used array: [(); size_of::<&Self>()], //~^ ERROR: generic `Self` types are currently not permitted in anonymous constants } // The below is taken from https://github.com/rust-lang/rust/issues/66152#issuecomment-550275017 // as the root cause seems the same. const fn foo<T>() -> usize { 0 } struct Bar<'a> { //~ ERROR: parameter `'a` is never used beta: [(); foo::<&'a ()>()], //~ ERROR: a non-static lifetime is not allowed in a `const` } fn main() {} </ins>

Discussion:
When trying to compile the following code, a panic occurs on :
Also happens on nightly
ICE reproduces all the way back to 1.36.0; before that, it still ICEs but in a different place.
Maximal reduction: ICE arises in: Blame: cc
I suspect this is a duplicate of . But the test case is slightly different so I'll leave it open for now
triage: P-medium (via analogy with priority on ), removing nomination label.
Triage: This is no longer ICE with the latest nightly:
Change:
git clone https://github.com/WebAssembly/wasi-libc cd wasi-libc <del> git reset --hard 4362b1885fd369e042a7c0ecd8df3b6cd47fb4e8 </del> <ins> git reset --hard 7018e24d8fe248596819d2e884761676f3542a04 </ins> make -j$(nproc)  CC="$bin/clang"  NM="$bin/llvm-nm" 

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. --I tried this code: I expected to see this happen: If you compile this to a WASI library and call the update function from a WASM runtime, then it will query the metadata of the file only during the first call to update. Every other invocation the update function should do nothing. Instead, this happened: The update function seems to refresh the list of preopened directories on every call... and it leaks them. The WASM memory keeps growing, looking like this: ! This likely is because of the way Rust lazily initializes the list of preopened directories through wasi-libc. It probably does it unconditionally, which wasi-libc probably can't handle, so it never frees any memory. The problem also occurs if you have any file system code at all, and it never even gets called: If you compile this code, but never call and instead only , it also keeps leaking the list of preopened directories. The WASM seems to come down to this: with looks too complex. The original C code probably needs to be checked. <!-- 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 ?
It seems like this has already been fixed in the upstream wasi-libc: But Rust still uses an old version of wasi-libc:
Change:
use errors::{Handler, DiagnosticBuilder}; use ext::tt::macro_parser::{NamedMatch, MatchedSeq, MatchedNonterminal}; use parse::token::{DocComment, MatchNt, SubstNt}; <del> use parse::token::{Token, NtIdent, SpecialMacroVar}; </del> <ins> use parse::token::{Token, Interpolated, NtIdent, NtTT, SpecialMacroVar}; </ins> use parse::token; use parse::lexer::TokenAndSpan; use tokenstream::{self, TokenTree};

Discussion:
See discussion on .
The ability to convert token-trees AST is also needed to
Do we need that ability here? It's only about interpolated matches.
Fixed in .
Change:
use errors::{Handler, DiagnosticBuilder}; use ext::tt::macro_parser::{NamedMatch, MatchedSeq, MatchedNonterminal}; use parse::token::{DocComment, MatchNt, SubstNt}; <del> use parse::token::{Token, NtIdent, SpecialMacroVar}; </del> <ins> use parse::token::{Token, Interpolated, NtIdent, NtTT, SpecialMacroVar}; </ins> use parse::token; use parse::lexer::TokenAndSpan; use tokenstream::{self, TokenTree};

Discussion:
I haven't finished investigating this, so I'm making an issue just so I don't forget it:
Actually, I'm really not sure this should work. I'm nominating this for well-defined.
Actually... this definitely shouldn't work in our current system. The basic issue is that a lonely sigil is not a complete "thing". The "tt" macro option is only intended for macros that expand into macro invocations. There are a number of ways around this; at the most basic level, you can insist that the user provide the sigil and the thing it's attached to. This works, but it may be unsatisfying if you want the sigil to be attached to names that are introduced by the macro. In this case, you have a couple of choices. use an unhygienic macro (and tell everyone what name you want to attach to the sigil, ugh) explicitly have three different versions of the macro, one for each sigil (bleah) clean up the second option by nesting one macro definition inside another one make sigils expand into macro invocations. Anyhow, I would say that as of right now, at least, this is not a bug. I'm going to leave this as nominated mostly because this came up in Vancouver as something that Graydon and I both expected to work.
Visiting for triage: still doesn't work, nothing more to add.
accepted for well-defined milestone
You can work around this by using a dummy macro so that you can pass the directly to it, e.g. for the example in the issue:
reading this workaround makes me feel like our macro system is really broken :(.
/cc
The modernized example gives me which looks like .
notes that another hacky work-around is a nested macro invocation, which avoids needing to define/export dummy macros (although one will want to be careful about giving that internal macro a fairly unique name to avoid trampling on any other macros in scope, unfortunately :disappointed: ).
Updated example: error:
Triage: This is an ancient P-low bug but per it actually comes up in the wild a lot - macro writers have to know how to do this workaround. Can this be escalated? Is there a solution somebody could mentor?
Discussed at lang meeting, we believe this should remain p-low since we don't know a very easy fix.

It should be fixed by converting macro_rules to expand to pure tokens then parsing, rather than mixing the two steps (which we hop would be back-compat). cc
Fixed in .
Change:
} }; <ins> let rustfn_ty = Type::from_ref(llvm::LLVMTypeOf(llrustfn)).element_type(); let mut rust_param_tys = rustfn_ty.func_params().into_iter(); </ins> // Push Rust return pointer, using null if it will be unused. let rust_uses_outptr = match tys.fn_sig.output { ty::FnConverging(ret_ty) => type_of::return_uses_outptr(ccx, ret_ty), ty::FnDiverging => false }; let return_alloca: Option<ValueRef>; <del> let llrust_ret_ty = tys.llsig.llret_ty; let llrust_retptr_ty = llrust_ret_ty.ptr_to(); </del> <ins> let llrust_ret_ty = if rust_uses_outptr { rust_param_tys.next().expect("Missing return type!").element_type() } else { rustfn_ty.return_type() }; </ins> if rust_uses_outptr { // Rust expects to use an outpointer. If the foreign fn // also uses an outpointer, we can reuse it, but the types

Discussion:
Repro: ICE:
tracks a number of cases that throw the same error.
A couple of hints - it looks like it happens when structure size is actually smaller or equal to register of architecture. I had the similar report for failing on iOS with the following sample: It fails on and if + <= 64 bits, i.e. they are u16 or u32. When switching to armv7 it fails if + <= 32 bits
after 6 hours bisecting the verdict is - , part of
sigh I actually saw that when I was working on but didn't come up with a test case that would trigger a problem here and then forgot about it. Will look into this.
will fix hit the upcoming beta?
Sorry, fixing a few regressions in LLVM that affected rust had higher priority for me than this issue (because LLVM is very close to its 3.6 release), so I couldn't devote much time to this issue yet. But given that the beta is still ~3 weeks away, I'm positive that I'll get around to have it fixed by then.
Hmm, beta is on week of Feb 16 (i.e. next week), isn't it?
Yes. Although, as someone hitting that bug, I'd be okay if that were flagged as a known bug and would prefer if semantic issues were cared about first.
I have nothing against fixing regressions, still be extremely happy to see it fixed as I will be stuck on beta1 following 6 weeks till beta2 or rc1.
:tada: thanks a lot!
Change:
<ins> error[E0432]: unresolved import `unresolved` --> $DIR/issue-109343.rs:4:9 | LL | pub use unresolved::f; |         ^^^^^^^^^^ maybe a missing crate `unresolved`? | = help: consider adding `extern crate unresolved` to use the `unresolved` crate error: aborting due to previous error For more information about this error, try `rustc --explain E0432`. </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</details
searched nightlies: from nightly-2023-02-10 to nightly-2023-03-18 regressed nightly: nightly-2023-02-12 searched commit range: regressed commit: cc
Could you assign it to me, I am willing to try to solve the problem
Change:
<ins> // Import for `A` is inlined and doc comments on the import and `A` itself are merged. // After the merge they still have correct parent scopes to resolve both `[A]` and `[B]`. // check-pass #![allow(rustdoc::private_intra_doc_links)] mod m { /// [B] pub struct A {} pub struct B {} } /// [A] pub use m::A; </ins>

Discussion:
Found while reducing , but the error is different (probably same root cause however) : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +T-rustdoc searched nightlies: from nightly-2023-01-01 to nightly-2023-02-23 regressed nightly: nightly-2023-02-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summary</detailscc
being looked up: table:
cc
Duplicate of , fixed in

This looks similar to , but this wasn't fixed by <!-- 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 modify labels +A-resolve
This ICE seems to be related to intra-doc link resolution, not standard name resolution. My bad :sweat_smile: modify labels +A-intra-doc-links -A-resolve
Minimum reproduction code:
The issue is in rustdoc, it passes a wrong parent module ( instead of the root ) when requesting resolutions for .
The resolution exists in rustc tables, it's just attached to , not .
The issue is in rustdoc, it passes a wrong parent module is currently used for determining the parent module, but it's wrong for inlined items because for them represents the target item, not the item itself. It looks like can be used instead, I'm just not sure how consistently it's set.
Thanks for the information! Wanna send the fix? Otherwise I plan to do it in the next days.
Fixed in The issue turned out a bit deeper than described in

The  crate <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
probably duplicate of
This is some different issue than whitespace issues in , it's not resolved by I'll investigate in more detail in a couple of days.
Fixed in
Change:
<del> Subproject commit dba35d2be72f4b78343d1a0f0b4737306f310672 </del> <ins> Subproject commit ef3f649e49607a1fad64eb0a5139110df3efa2a7 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Ah damn it, we keep getting broken so there's still no nightly with Miri. :(
Building std now ICEs on windows...? The same target works fine on my system, so it is host-specific. Sounds like one of the PRs in that rollup is buggy...
do you have a stack trace for that ICE?
Nope, I cannot reproduce so all we got is the . The ICE is .
Miri CI , not even in a Windows host. It's a 32bit host though. Would be great if someone with an x86_64 windows host could try to clone the Miri repo and do .
We're seeing a related-looking issue on Fuchsia on the same commit:
I'm unable to reproduce the ICE with on Btw the advice of results in a build error, because Miri was broken again by another PR.
This does look like my PR causes this.
Yeah when I wrote that, the other PR had not landed yet. ;)
Hm, that is odd. Not sure what the tools builder does differently, maybe it has debug assertions enabled? The line number in the ICE is so bad due to
Not sure how related they really are, the original ICE is some kind of out-of-bounds slice access within rustc itself... Could someone try upgrading Miri to current git master? Miri CI passes with latest rustc, after all... even if it fails again, we'll at least get better line numbers since was fixed. Maybe there is a way to run the windows tools runner without using up a full bors slot?
on it
Turns out the strange Windows-only ICE was caused by a buggy debug assertion:
Change:
// revisions: armv7a_none_eabihf // [armv7a_none_eabihf] compile-flags: --target armv7a-none-eabihf // [armv7a_none_eabihf] needs-llvm-components: arm <del> // revisions: armv7k_apple_watchos // [armv7k_apple_watchos] compile-flags: --target armv7k-apple-watchos // [armv7k_apple_watchos] needs-llvm-components: arm </del> // revisions: armv7r_none_eabi // [armv7r_none_eabi] compile-flags: --target armv7r-none-eabi // [armv7r_none_eabi] needs-llvm-components: arm // revisions: armv7r_none_eabihf // [armv7r_none_eabihf] compile-flags: --target armv7r-none-eabihf // [armv7r_none_eabihf] needs-llvm-components: arm <del> // revisions: armv7s_apple_ios // [armv7s_apple_ios] compile-flags: --target armv7s-apple-ios // [armv7s_apple_ios] needs-llvm-components: arm </del> // FIXME: disabled since it fails on CI saying the csky component is missing /* revisions: csky_unknown_linux_gnuabiv2

Discussion:
Right now I have to run with applied, but when I do several tests fail, eg: tests/assembly/targets/targets- more are visible in
I think this test should check for instead of . I believe that currently this test is actually matching something like , which is not emitted on Solaris since I assume the intention was to look for , but that's one of the section types for which an explicit is normally omitted.
Okay, just looking for doesn't work, because apparently targets-elf, despite the name, currently also includes the MachO targets.