jiebi/CodeConvo huggingface dataset:
Change:
<ins> // build-pass // compile-flags: -Zsave-analysis enum Enum2 { Variant8 { _field: bool }, } impl Enum2 { fn new_variant8() -> Enum2 { Self::Variant8 { _field: true } } } 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. --<!-- 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 is a recent regression, since we run this command every day in automation.
Almost certainly a regression from /cc
looks like a duplicate of

<!-- 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. --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 @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Its a regression from but fortunately the fix is relatively easy. I'll provide a PR soon,

<!-- 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. --repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
another one: another one:
I am on it
Same issue happened after upgraded to the latest version today.
Yes the has not landed yet.
Change:
t } <del> // Define a dummy resolution containing a `Res::Err` as a placeholder for a failed resolution, // also mark such failed imports as used to avoid duplicate diagnostics. fn import_dummy_binding(&mut self, import: &'a Import<'a>) { </del> <ins> // Define a dummy resolution containing a `Res::Err` as a placeholder for a failed // or indeterminate resolution, also mark such failed imports as used to avoid duplicate diagnostics. fn import_dummy_binding(&mut self, import: &'a Import<'a>, is_indeterminate: bool) { </ins> if let ImportKind::Single { target, ref target_bindings, .. } = import.kind { <del> if target_bindings.iter().any(|binding| binding.get().is_some()) { </del> <ins> if !(is_indeterminate || target_bindings.iter().all(|binding| binding.get().is_none())) { </ins> return; // Has resolution, do not create the dummy binding } let dummy_binding = self.dummy_binding;

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:
_ => None, }) .peekable(); <del> if let CtorKind::Fictive = s.struct_type { </del> <ins> if let CtorKind::Fictive | CtorKind::Fn = s.struct_type { </ins> if fields.peek().is_some() { write!( w, "<h2 id="fields" class="fields small-section-header"> <del> Fields{}<a href="#fields" class="anchor"></a></h2>", </del> <ins> {}{}<a href="#fields" class="anchor"></a> </h2>", if let CtorKind::Fictive = s.struct_type { "Fields" } else { "Tuple Fields" }, </ins> document_non_exhaustive_header(it) ); document_non_exhaustive(w, it); <del> for (field, ty) in fields { let id = cx.derive_id(format!( "{}.{}", ItemType::StructField, field.name.as_ref().unwrap() )); </del> <ins> for (index, (field, ty)) in fields.enumerate() { let field_name = field.name.map_or_else(|| index.to_string(), |sym| (*sym.as_str()).to_string()); let id = cx.derive_id(format!("{}.{}", ItemType::StructField, field_name)); </ins> write!( w, "<span id="{id}" class="{item_type} small-section-header">

Discussion:
Rustdoc should expose doc comments written on tuple fields: Tagging based on conversation on IRC.
This issue also applies to tuple variant fields:
It promises to be very interesting from a design point of view. We'll to think about how to render this nicely.
Change:
where R: TypeRelation<'tcx>, { <ins> debug!("{}.consts({:?}, {:?})", relation.tag(), a, b); if a == b { return Ok(a); } let a = replace_if_possible(self.const_unification_table.borrow_mut(), a); let b = replace_if_possible(self.const_unification_table.borrow_mut(), b); </ins> let a_is_expected = relation.a_is_expected(); match (a.val, b.val) {

Discussion:
<short summary of the bugI tried this code: I expected to see this happen: It should build. Instead, this happened: rustc crashed with: Possible workaround: replace with . playground: rustc version: 1.39.0-nightly 2019-09-15
cc
Also ICEs without explicit feature gate enabled :/
Change:
mod grisu; } <ins> use std::f64; use std::io::Write; use std::vec::Vec; use test::Bencher; </ins> use core::num::flt2dec::{decode, DecodableFloat, FullDecoded, Decoded}; use core::num::flt2dec::MAX_SIG_DIGITS;

Discussion:
floattodecimalcommon in does this: let mut buf = [0; 1024]; let mut parts = [flt2dec::Part::Zero(0); 16]; and then passes buf and parts to flt2dec::toexactfixedstr or flt2dec::toshorteststr Looking at the docs for those functions at and the "parts" array needs to have length at least 5, right? And the "buf" array needs to be at least 800+ for the toexactfixedstr case but only 17 (MAXSIGDIGITS) for the toshorteststr case, afaict. Changing the toshorteststr case to not use the huge buffer would probably help out too. Also, it's not clear to me that the "buf" scratch buffer needs to be zero-initialized. Does it?
Note that I'm poking at this a bit.
I spun off the zeroing thing into because I have a fix for that... we may still want to make the stackframe here smaller, though.
Change:
//! its file descriptors with no operations being performed by any other part of the program. //! //! Note that exclusive ownership of a file descriptor does *not* imply exclusive ownership of the <del> //! underlying kernel object that the file descriptor references (also called "file description" on </del> <ins> //! underlying kernel object that the file descriptor references (also called "open file description" on </ins> //! some operating systems). File descriptors basically work like [`Arc`]: when you receive an owned //! file descriptor, you cannot know whether there are any other file descriptors that reference the //! same kernel object. However, when you create a new kernel object, you know that you are holding

Discussion:
In std::io, : Note that exclusive ownership of a file descriptor does not imply exclusive ownership of the underlying kernel object that the file descriptor references (also called “file description” on some operating systems). File descriptors basically work like : when you receive an owned file descriptor, you cannot know whether there are any other file descriptors that reference the same kernel object. However, when you create a new kernel object, you know that you are holding the only reference to it. Just be careful not to lend it to anyone, since they can obtain a clone and then you can no longer know what the reference count is! In that sense, is like Arc and is like &'a Arc However the table in std::io::unix::io has the table saying: =Box<This is incorrect and potentially very misleading, because the result of ping a file descriptor creates a new fd which shares the same underlying file structure in the kernel. In particular, for seekable fds they share the current file offset (ie, used by and ) and in some cases, file locking state. (In addition to inode state and underlying file/pipe/etc contents.) The language here should reflect the language in std::io.
cc - I think this is something that should have addressed.
Yeah the model described in doesn't take into account and the indirection layer of "file descriptors" vs "file descriptions". (That was already the case before though, it just became a lot more apparent with that PR.)
Change:
<ins> error[E0080]: it is undefined behavior to use this value --> $DIR/dangling-zst-ice-issue-126393.rs:7:1 | LL | pub static MAGIC_FFI_REF: &'static Wrapper = unsafe { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ constructing invalid value: encountered a dangling reference (use-after-free) | = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior. = note: the raw bytes of the constant (size: $SIZE, align: $ALIGN) { HEX_DUMP } error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0080`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: could not find allocation for alloc3', 'error: internal compiler error: could not find allocation for alloc3' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [evalstaticinitializer] evaluating initializer of static [analysis] running analysis passes on this crate -- label +F-extern_types
Regression in nightly-2024-05-23 cc :thinking:
Anyway it doesn't seem to affect the test.
This is not a recent regression, here's a reproducer on stable:
But why?^^ lol XD its just side effect of the fuzzing I guess :D
Change:
); write_sidebar_links(out, blanket_format); } <ins> if let Some(impl_) = v .iter() .filter(|i| i.inner_impl().trait_.is_some()) .find(|i| i.inner_impl().trait_.def_id_full(cache) == cx.cache.deref_trait_did) { sidebar_deref_methods(cx, out, impl_, v); } </ins> } } }

Discussion:
For example, I would much rather have the documentation for my crate Staticvec look , as opposed to pulling in the docs for every single slice method Edit: Some additional thoughts: even if this isn't possible for some reason, it would almost certainly be better to have the crate-native "Trait Implementations" section appear before the "Methods From Deref" section does, since "Trait Implementations" will pretty much always be describing things that are unique to the crate being documented and so actually directly relevant a good idea might also be to have the "Methods From Deref" header amount to a clickable link that redirects to the actual primary docs for whatever is being derefed to in any case where it is being left empty, if that is still possible
Are there any details on when precisely this changed, also? I've noticed that even though the auto-generated docs on previously left the "Methods From Deref" section empty for user-submitted crates, it was seemingly always filled out for stuff like the official docs for , so presumably there has always been some kind of way of controlling 's behaviour in this regard, unless I'm missing something.
Yes, it was changed intentionally in and mentioned in the release notes: Vec derefs directly to slice - maybe the user crates you're talking about always deref to Vec?
:+1: I like this idea. Hmm, I'm a little concerned the methods will be harder to find that way. We get a lot of complaints that the "Trait Implementations" section is hard to read because you have to click on the name of the trait to see what methods are available.
Yeah, that makes sense. Honestly just showing before in any case where both exist would likely pretty much cover the kind of thing I was mostly concerned about by itself anyways.
Are you interested in making a PR for that? I think it would be as simple as moving after :)
Sure, I'll take a look at it tomorrow.
Got busy with some other stuff, but I've now opened a PR that make those changes, which do accomplish what you thought they would.
Change:
# If this file is modified, then llvm will be (optionally) cleaned and then rebuilt. # The actual contents of this file do not matter, but to trigger a change on the # build bots then the contents should be changed so git updates the mtime. <del> 2018-07-12 </del>  No newline at end of file <ins> 2018-08-02 </ins>

Discussion:
LLVM 7.0 has been branched as of 2018-08-01, with the final tag probably a couple weeks away. The first release candidate will be tagged in a couple of days. is the llvm-dev announcement, and is a view of the commits on the branch. Once the final release has been tagged, Rust should be updated to LLVM 7.0.
Great! I've started our branches: I'm hoping that this'll be pretty smooth since we upgraded most of the way through the cycle! I'm testing locally now and will send a PR once green.
Change:
// Foreign ABI requires an out pointer, but Rust doesn't. // Store Rust return value. let llforeign_outptr_casted = <del> builder.bitcast(llforeign_outptr, llrust_retptr_ty); </del> <ins> builder.bitcast(llforeign_outptr, llrust_ret_ty.ptr_to()); </ins> builder.store(llrust_ret_val, llforeign_outptr_casted); builder.ret_void(); }

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:
for arg in args { self.visit_operand(arg, location); } <del> } else if let TerminatorKind::Drop { location: ref place, .. } = *kind { self.super_terminator_kind(kind, location); </del> <ins> } else if let TerminatorKind::Drop { location: ref place, .. } | TerminatorKind::DropAndReplace { location: ref place, .. } = *kind { match *kind { TerminatorKind::DropAndReplace { .. } => {} _ => self.super_terminator_kind(kind, location), } </ins> // Deny *any* live drops anywhere other than functions. if self.mode.requires_const_checking() {

Discussion:
In the following example, and are allowed but isn't: The reason is that is lowered to in MIR, and that's not handled in const-checking as a and an assignment (which it functionally is). EDIT: nevermind, promotion works based on temporaries, so it shouldn't be affected. cc
I'm going to label this as a bug since it seems covered by from a T-Lang perspective.
Change:
fn bar() { //~ ERROR: code is never used foo(); } <ins> // Code with #[allow(dead_code)] should be marked live (and thus anything it // calls is marked live) #[allow(dead_code)] fn g() { h(); } fn h() {} // Similarly, lang items are live #[lang="fail_"] fn fail(_: *u8, _: *u8, _: uint) -> ! { loop {} } </ins>

Discussion:
Currently if you have some dead_code and you want to preserve it, you have to annotate every function you want to preserve and all the dead code that function calls. I think we should consider annotated code to be alive, and then all the code that touches to be alive as well.
cc sounds like a cool idea to me.
By "annotate", do you mean putting an attribute above the function you want to preserve?
yes.
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // aux-build:lang-item-public.rs // ignore-fast // ignore-android #[no_std]; extern crate lang_lib = "lang-item-public"; #[cfg(target_os = "linux")] #[link(name = "c")] extern {} #[cfg(target_os = "android")] #[link(name = "c")] extern {} #[cfg(target_os = "freebsd")] #[link(name = "execinfo")] extern {} #[cfg(target_os = "macos")] #[link(name = "System")] extern {} #[start] fn main(_: int, _: **u8) -> int { 1 % 1 } </ins>

Discussion:
Fails to compile with linking errors:
Either this or require that they are .
I think I disagree. Lang items should be public - for the most part they are used just like any other item.
Though there is some appeal to being able to hide lang items that aren't part of the public API.
I don't think we'll ever expect someone to use a lang item directly, and for an executable there's no need for lang items to be public, there's not even a need for them to be reachable really. I suppose we could just require that libraries have public lang items? Regardless, this seems like kinda a corner case to me because there's not that much interaction with lang items.
I'm actually surprised that this example compiled. I guess something in rustc was ignoring visibility when encoding calls to .
Change:
print("Target executable is '%s'." % target_path) print("Current working directory is '%s'" % os.getcwd()) <ins> # Start the timeout watchdog start_watchdog() </ins> # Create a new debugger instance debugger = lldb.SBDebugger.Create()

Discussion:
From time to time the LLDB test suite hangs on the build bots, which leads to the whole pipeline being blocked for an hour. One way to make this problem a bit less severe is to add a time-out to the LLDB test runner which just kills tests that take longer than a few seconds. This should at least reduce the time until the tests can be restarted. cc
cc
Change:
run_early_pass!(self, check_fn, fk, span, id); self.check_id(id); ast_visit::walk_fn(self, fk, span); <ins> // Explicitly check for lints associated with 'closure_id', since // it does not have a corresponding AST node if let ast_visit::FnKind::Fn(_, _, sig, _, _) = fk { if let ast::Async::Yes { closure_id, .. } = sig.header.asyncness { self.check_id(closure_id); } } </ins> run_early_pass!(self, check_fn_post, fk, span, id); }

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. --I don't have a minimal example yet, but here's . Sample: The ICE happens on the and macros, which are both from the crate. <!-- 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. --This began with commit . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
FYI, I think that link is only accessible to Googlers: !
Sorry, .
Minimized: Caused by
When we run on the AST, we create a definition for the desugared closure body inside an : As a result, the entry for our macro call will have the of the desugared closure. However, this desugared closure does not actually exist in the AST (it is created during lowering), so we will never check for lints with its when we emit buffered early lints.
Nightly has been broken for 3 days, if there's disagreement on how to fix the issue, can we revert while the fix is being worked on?
This will be fixed by PR
I'm still hitting this bug with the latest nightly.
Change:
util(); } <ins> #[allow(unconditional_panic)] </ins> fn util() { let _a: u8 = 4.try_into().unwrap(); let _a: u8 = 5.try_into().expect("");

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: Instead, this happened: Apparently, taking a shared reference of will suppress the lint. This seems like a false negative. While false negatives can't be avoided entirely, this case seems to be avoidable as taking a shared reference shouldn't change the type of (which is ) or modify any data in this example. Note that will trigger the lint properly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
See also .
claim
Note this is a problem because which is supposed to fail to compile but this bug makes it fail at runtime instead
In case no one has dug into it yet, the error is suppressed in but not in and before:
label +regression-from-stable-to-stable
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This is caused by . It only ever worked because the lint ran after optimizations. I made a fix . It specializes the length of arrays as constant, even if the array isn't. I'm going to open a PR when I have time, probably tomorrow. In the long term, I'd like to implement some more extensive tracking of "what parts of a value are constant". For example, the compiler currently assumes that anything that had its reference taken can change, but actually, this can only happen inside (as I understand it).
Labels from the closed duplicate , label A-diagnostics, A-lint, A-mir-opt, T-compiler.
Fixed on stable label E-needs-test
I claim the add test part
This lint only appears on full builds (not check), but this will be fixed once lands.
Reopening because I feel this is not yet solved, see on . As per the , should nail down this issue?
MRE: Also, duplicate of
Another variant of this same issue: