jiebi/CodeConvo huggingface dataset:
Change:
span: Span, origin: &hir::OpaqueTyOrigin, ) { <del> let hidden_type = tcx.bound_type_of(def_id.to_def_id()).subst(tcx, substs); </del> let hir_id = tcx.hir().local_def_id_to_hir_id(def_id); let defining_use_anchor = match *origin { hir::OpaqueTyOrigin::FnReturn(did) | hir::OpaqueTyOrigin::AsyncFn(did) => did,

Discussion:
Since the nightly 2022-09-11, the following code doesn't compile anymore. <!-- 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
Minimized it a little
searched nightlies: from nightly-2022-01-01 to nightly-2022-09-30 regressed nightly: nightly-2022-09-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc
cc
I get the same ICE when using the current nightly in a complex Codebase. The works fine.
I think I minimized this to:

<!-- 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: <!-- 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<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I found this error occurred by this commit through
Probably cc
Minimized: claim label F-typealiasimpl_trait T-compiler
This has caused crate and docs fail to build.
This just upgraded from bad diagnostics to ICE on latest nightly.
Change:
self.s.word(","); } } <ins> self.ann.post(self, AnnNode::Arm(arm)); </ins> self.end() // close enclosing cbox }

Discussion:
ICE with the borrow checker on nightly. Tried on stable/beta and it correctly errors with in nightly, I get : Backtrace:
Reduced: cc
Bisected this one to and , that is, PR . cc
Change:
#![feature(no_sanitize)] // ASAN-LABEL: define void @test <del> // ASAN:         tail call fastcc void @random_inline </del> <ins> // ASAN:         call {{.*}} @random_inline </ins> // ASAN:       } // // LSAN-LABEL: define void @test

Discussion:
Code: If the function is marked as , it doesn't get compiled into the dll file: The reason a function may be marked as both and is so that it gets inlined when compiling the crate as a rust library, but not inlined when compiling the crate as a cdylib. There should be a warning to use something like instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Related to - I think is that we should include 'd functions in s and s, but as a short term solution, a warning is a nice idea
claim

I currently use Rust to generate a static library for FFI consumption. In some public interfaces, I call other FFI public interfaces as primarily a wrapper with a few tweaks. I'd like to mark these "inner" functions as inline, however, this seems to cause them to not show up in the final staticlib. Given this drastically simplified example: The function makes it to the static library, but the function does not: If I remove the attribute, we see both functions in the static lib: The don't seem to hint that can prevent / items from surviving all the way to the final library, or that they shouldn't be used together. I would expect any function marked and/or should be present in the final artifact, regardless of attributes. I see this behavior on stable, as well as a recent nightly. I don't know if this is a regression, as this is the first time I've run into this. Thanks! Edit: Simplified profile settings, they are not needed to reproduce. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tried with = same result
I’ve noticed this for a while but I always assumed it was intended... It would be really nice if this was fixed
This appears to have been done deliberately: Maybe it shouldn't apply to s.
Expanding on note, I would also expect this not to apply to s as well (I used the staticlib for my example, but my use case generates code for both static and dynamic library usage).
I think I'm going to take this on claim
Change:
<ins> //@ build-pass //@ compile-flags: -Zvirtual-function-elimination=true -Clto=true //@ only-x86_64 //@ no-prefer-dynamic // issue #123955 pub fn test0() { _ = Box::new(()) as Box<dyn Send>; } // issue #124092 const X: for<'b> fn(&'b ()) = |&()| (); pub fn test1() { let _dyn_debug = Box::new(X) as Box<fn(&'static ())> as Box<dyn Send>; } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc ./subtyping-impacts-selection-2.rs '-Zvirtual-function-elimination=true -Clto=true -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'expected principal trait object'', 'thread 'rustc' panicked at 'expected principal trait object'' File: /tmp/im/subtyping-impacts-selection-2.rs --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: --
Seems to be a duplicate of
Regression in nightly-2022-06-16 commit[0] 2022-06-14: Auto merge of - b-naber:transition-to-valtrees-in-type-system, r=lcnr commit[1] 2022-06-14: Auto merge of - flip1995:pk-vfe, r=nagisa commit[2] 2022-06-15: Auto merge of - compiler-errors:if-cond-and-block, r=oli-obk commit[3] 2022-06-15: Auto merge of - JohnTitor:rollup-rfg1a4s, r=JohnTitor commit[4] 2022-06-15: Auto merge of - nnethercote:rm-thread-local-IGNORED_ATTRIBUTES, r=michaelwoerister commit[5] 2022-06-15: Auto merge of - JohnTitor:rollup-c17vjdy, r=JohnTitor commit[6] 2022-06-15: Auto merge of - AzureMarker:feature/horizon-std, r=nagisa commit[7] 2022-06-15: Auto merge of - c410-f3r:assert-compiler, r=oli-obk commit[8] 2022-06-15: Auto merge of - sunfishcode:ownedfd-and-dup, r=joshtriplett looks like this has been broken eversince

This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:
Change:
} } <ins> /// Walks up the tree of definitions starting at `def_id`, /// stopping at the first `DefKind::Mod` encountered fn nearest_mod_parent(&mut self, def_id: DefId) -> Module<'a> { let def_key = self.cstore().def_key(def_id); let mut parent_id = DefId { krate: def_id.krate, index: def_key.parent.expect("failed to get parent for module"), }; // The immediate parent may not be a module // (e.g. `const _: () =  { #[path = "foo.rs"] mod foo; };`) // Walk up the tree until we hit a module or the crate root. while parent_id.index != CRATE_DEF_INDEX && self.cstore().def_kind(parent_id) != DefKind::Mod { let parent_def_key = self.cstore().def_key(parent_id); parent_id.index = parent_def_key.parent.expect("failed to get parent for module"); } self.get_module(parent_id) } </ins> crate fn get_module(&mut self, def_id: DefId) -> Module<'a> { // If this is a local module, it will be in `module_map`, no need to recalculate it. if let Some(def_id) = def_id.as_local() {

Discussion:
Found in the crater run: ICEs: ` This ICE happens on: but only shows a compiler error.
Assigning as and removing .
This is because an integration gets checked, which relies on the feature to be enabled. Once it is enabled, does not fail anymore, and yet the ICE persists . I'll thus kindly ask for this to be "re-prioritized", if possible, thanks. modify labels: +I-prioritize
Assigning and removing as in the prioritization working group.
ping cleanup This needs mcve and bisection
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched nightlies: from nightly-2020-07-20 to nightly-2020-08-25 regressed nightly: nightly-2020-07-28 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summary
Minimized:
Change:
| = help: mark blocks that do not contain Rust code as text: ```text <ins> warning: Rust code block is empty --> $DIR/invalid-syntax.rs:68:5 | LL |   /// ```rust |  _____^ LL | | /// ``` | |_______^ warning: Rust code block is empty --> $DIR/invalid-syntax.rs:72:5 | LL |   /// ``` |  _____^ LL | | /// LL | | /// LL | | /// ``` | |_______^ help: mark blocks that do not contain Rust code as text | LL | /// ```text |     ^^^^^^^ </ins> error: unknown start of token:  --> <rustdoc-highlighting>:1:1 |

Discussion:
Run tests for and you'll get the following diagnostic: But to be as helpful as possible the diagnostic should, if possible, point to the start of the invalid code block.
This error was removed in because I didn't think it could actually be produced. Looks like it was possible to trigger by writing an empty doc test. The error message is misleading, though. It's a valid code block, just empty. On master, this code produces a passing doc test now. IMO, that is the correct behavior. There should probably be a test for it.
I agree completely. Would this mean re-introducing this message but improving the message (replacing invalid with empty or something similar)? I believe that is the best course of action as warning on an empty code block is completely valid and desired IMO.
The original code only caught this incidentally. I think this check would make more sense as a rustdoc lint instead of a hard warning. Could be to or a new pass entirely.
could you edit this issue to reflect the current status? It should be something like "Empty doc tests should be linted".
I'd like to take this issue - should have a PR this week for review.
Change:
#[cfg(any(target_os = "linux", target_os = "emscripten", target_os = "android"))] pub fn metadata(&self) -> io::Result<FileAttr> { <del> let fd = cvt(unsafe {dirfd(self.dir.inner.dirp.0)})?; </del> <ins> let fd = cvt(unsafe { dirfd(self.dir.inner.dirp.0) })?; let name = self.entry.d_name.as_ptr(); cfg_has_statx! { if let Some(ret) = unsafe { try_statx( fd, name, libc::AT_SYMLINK_NOFOLLOW | libc::AT_STATX_SYNC_AS_STAT, libc::STATX_ALL, ) } { return ret; } } </ins> let mut stat: stat64 = unsafe { mem::zeroed() }; cvt(unsafe { <del> fstatat64(fd, self.entry.d_name.as_ptr(), &mut stat, libc::AT_SYMLINK_NOFOLLOW) </del> <ins> fstatat64(fd, name, &mut stat, libc::AT_SYMLINK_NOFOLLOW) </ins> })?; <del> Ok(FileAttr { stat }) </del> <ins> Ok(FileAttr::from_stat64(stat)) </ins> } #[cfg(not(any(target_os = "linux", target_os = "emscripten", target_os = "android")))]

Discussion:
First of all, it now returns an Err with "not available on this platform currently". But I found that there is a system call  available in Linux kernel 4.11, which can get the birth time. As the , the function uses on Unix platforms. But the just never contains . Shouldn't it try when available?
Change:
} #[derive(SessionSubdiagnostic)] <del> pub enum AddReturnTypeSuggestion<'tcx> { </del> <ins> pub enum AddReturnTypeSuggestion { </ins> #[suggestion( typeck::add_return_type_add, code = "-> {found} ",

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: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest how to specify the return type when a function returns a closure. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Is some thing like this not ok ?
release-assignment
It's ok but I was wondering if it's possible to make the compiler give some form of a suggestion to the user on how to do this. Cause the current diagnostics does not suggest how to fix it.
Change:
LL | impl AnotherTrait for D<OpaqueType> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `D<OpaqueType>` | <del> = note: downstream crates may implement trait `std::fmt::Debug` for type `OpaqueType` </del> <ins> = note: upstream crates may add a new impl of trait `std::fmt::Debug` for type `OpaqueType` in future versions </ins> error: cannot implement trait on type alias impl trait --> $DIR/negative-reasoning.rs:19:25

Discussion:
The full log is available from this link: From the aforementioned link:
Do you have a more concise way of reproducing this? I can't seem to get it to ICE when I run with , no matter if I use , etc.
nvm, should be using ..
This is actually reproducible even with . It seems to only ICE with feature. Command for reproduction: <details<summary<strongBacktrace</strong</summary<p</p</detailsWe don't use feature much, so it should be easy, to make a MRE, I'll try.
I found an MRE. I'll put up a fix in a second.
I found a MRE too :(
+1, I basically reproduced that in the UI test but manually expanding the part of the macro that causes the ICE.
Change:
cast_ty: Ty<'tcx>, cast_span: Span, span: Span, <ins> constness: hir::Constness, </ins> ) -> Result<CastCheck<'tcx>, ErrorGuaranteed> { let expr_span = expr.span.find_ancestor_inside(span).unwrap_or(expr.span); <del> let check = CastCheck { expr, expr_ty, expr_span, cast_ty, cast_span, span }; </del> <ins> let check = CastCheck { expr, expr_ty, expr_span, cast_ty, cast_span, span, constness }; </ins> // For better error messages, check for some obviously unsized // cases now. We do a more thorough check at the end, once

Discussion:
Compiles in stable rust (1.64) as well as in beta. But in nightly, we get this compilation error: playground link: 64, and beta current nightly
searched nightlies: from nightly-2022-08-01 to nightly-2022-10-24 regressed nightly: nightly-2022-09-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Seems like closures pick the constness of their parent when they should always be notconst
Change:
[53893]: https://github.com/rust-lang/rust/pull/53893/ [52861]: https://github.com/rust-lang/rust/pull/52861/ <ins> [51966]: https://github.com/rust-lang/rust/pull/51966/ </ins> [52656]: https://github.com/rust-lang/rust/pull/52656/ [52239]: https://github.com/rust-lang/rust/pull/52239/ [52330]: https://github.com/rust-lang/rust/pull/52330/

Discussion:
I'll leave my story here because it shows how important the information can be: We recently upgraded from rustc 1.43 to 1.47 to build Firefox (we got stuck on 1.43 for a large number of complicated reasons, and would still be stuck if we hadn't found workarounds). Anyways, consequently, we've had a bunch of regressions, one of which was performance-related and I was bisecting it. The first thing I did was to compare each rust release, and it turned out the regression started between 1.44 and 1.45. So I went to the 1.45 release notes suspecting LLVM could have been involved and saw nothing there. Now, several hours later bisecting through nightlies (because PGO and LTO being involved, testing one version takes a while), the regression appears to have started between rustc 1.45.0-nightly ( 2020-05-21) and rustc 1.45.0-nightly ( 2020-05-20) So I take my git, type and lo and behold, there it is: I'm still waiting on the results actually confirming LLVM is involved (it likely is), but it would have saved me a lot of time if the LLVM upgrade had been mentioned (which it is for LLVM 11 in 1.47, BTW, but OTOH, now that I look, it appears the last upgrade mentioned is to LLVM 6 in 1.25...)
FWIW, the LLVM 11 upgrade in 1.47 got back a lot of the performance LLVM 10 lost:
Not for the testcase I'm bisecting, but that's OT.
I agree we should be mentioning this; thank you for noting it. I would be happy to accept a PR adding those in to the release notes (just 1.45 and 1.47, or more if you have the time).
Do you have an issue for that regression?
Will have when I have more information to feed into one.
Change:
/// either identifying an `impl` (e.g., `impl Eq for int`) that /// provides the required vtable, or else finding a bound that is in /// scope. The eventual result is usually a `Selection` (defined below). <del> #[derive(Clone)] </del> <ins> #[derive(Clone, PartialEq, Eq)] </ins> pub struct Obligation<'tcx, T> { pub cause: ObligationCause<'tcx>, pub recursion_depth: uint,

Discussion:
That's a mouthful! To exemplify: This doesn't compile with , even though it does without it. Note that the only difference between the two configurations is that the function on is a free function instead of a default method. With , this fails with: Tested on
cc me
I've been running into very similar errors all day while updating my libs to the latest nightly. Here's an example of a method that works fine along with one that does not (simplest example I could come up with).
This example works now. I think this was a dup of
I just updated to master and I'm still running into the same error - perhaps my error is a separate issue?
Edwardw's PR does seem to fix my issue however, perhaps it addresses something extra?
The original issue is still present if the example on the first post is compiled with . I tested on , which contains Edit: just compiled . Still reproducible
Change:
s.print_type_bounds(":", &param.bounds); if let Some(ref _default) = default { // FIXME(const_generics_defaults): print the `default` value here <del> todo!(); </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. --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</detailsThis happens since cc
Oh my, I'll fix that now. The syntax is gated but evidently the flag can still reach into the parts which were not completed yet. Update: Ah but I misread the code, this is actually using const generics defaults. They're not done yet, ICE-ing is expected until the feature is completed in . how did you hit that ? Were you trying to use const generics defaults or did the ICE come up unexpectedly ? I can open a PR that will do nothing here instead of ICE-ing.
I made a small program that executes rustc on all the rust files with different flags and filters the ICEs. The file showed up as previously unknown crash.
On nightly-2020-12-31 (commit ), I get a parse error with the code you provided:
Yes, the PR was merged ~7 hours ago, it's not in nightly yet.
Ah, things move fast :) How did you get a build with the commit then? Did you use ?
There are inofficial "master" builds released for every merge commit in the repo (the latest one is then promoted to "nightly" once at some point of the day) You can install them with and run something like or afterwards.
Oh, I forgot about RTIM
will remove the ICE so that only the appears
Change:
<ins> error: expected field pattern, found `...` --> $DIR/issue-46718-struct-pattern-dotdotdot.rs:21:55 | 21 |             PersonalityInventory { expressivity: exp, ... } => exp |                                                       ^^^ help: to omit remaining fields, use one fewer `.`: `..` error: aborting due to previous error </ins>

Discussion:
Consider the following code: If you try to compile this, you get the following errors: See the bug? Its because I used when I should have used It would be nice if the compiler, in its ever friendly manner, suggested the latter to me.
I volunteer.
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-63322-forbid-dyn.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default error[E0741]: `&'static (dyn A + 'static)` must be annotated with `#[derive(PartialEq, Eq)]` to be used as the type of a const parameter --> $DIR/issue-63322-forbid-dyn.rs:8:18 | LL | fn test<const T: &'static dyn A>() { |                  ^^^^^^^^^^^^^^ `&'static (dyn A + 'static)` doesn't derive both `PartialEq` and `Eq` error: aborting due to previous error; 1 warning emitted For more information about this error, try `rustc --explain E0741`. </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. --: Note that the error is also present on stable (1.42.0). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
cc I don't think should be structurally matchable.
Note that this isn't matching on , it's matching on . There's a double pointer indirection because AtomicPtr requires T to be Sized.
References match by their pointee value, unlike raw pointers. You should use if you want to actually compare the pointers.
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-63322-forbid-dyn.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default error[E0741]: `&'static (dyn A + 'static)` must be annotated with `#[derive(PartialEq, Eq)]` to be used as the type of a const parameter --> $DIR/issue-63322-forbid-dyn.rs:8:18 | LL | fn test<const T: &'static dyn A>() { |                  ^^^^^^^^^^^^^^ `&'static (dyn A + 'static)` doesn't derive both `PartialEq` and `Eq` error: aborting due to previous error; 1 warning emitted For more information about this error, try `rustc --explain E0741`. </ins>

Discussion:
Pretty straightforward. The idea is to plug logic into a template. This seems like something that should/could work. Playground link: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
"smaller": Error:
claim
release-assignment is not structural match so this should not compile. We probably shouldn't ICE here though :laughing: cc
It shouldn't be, but it currently is. To fix it you need to change , .