jiebi/CodeConvo huggingface dataset:
Change:
<ins> //@ build-pass //@ compile-flags: -Copt-level=3 // regression test for https://github.com/rust-lang/rust/issues/110722 // in --release we were optimizing to invalid bitcasts, due to a combination of MIR inlining and // mostly bad repr(simd) lowering which prevented even basic splats from working #![crate_type = "rlib"] #![feature(portable_simd)] use std::simd::*; use std::simd::num::*; pub unsafe fn mask_to_array(mask: u8) -> [i32; 8] { let mut output = [0; 8]; let m = masksizex8::from_bitmask(mask as _); output.copy_from_slice(&m.to_int().cast::<i32>().to_array()); output } </ins>

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 updated some benchmark code using portable simd to a current nightly (which included the llvm version bump from 15 to 16) and ran into the compiler getting killed with SIGILL, or when trying to simplify the code, an LLVM error about an invalid bitcast. It is likely that the problem is inside llvm itself, but so far I was not able to reduce the code to a minimal LLVM IR example. The initial problematic code involved : I could later reproduce it also with casting masks between bitmask, and : In compiler explorer, with arguments the output is the following: Compiling the same function, with an function in the rust playground (in release mode) leads to the compiler receiving a SIGILL <!-- 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. --:
Duplicate of
Not sure if this should be a separate issue, but I've also encountered the error with the trait: Using instead works
Resolved on latest nightlies. Needs a regression test.

<!-- 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. --Compiling the following in release on the recent nightlies causes a crash. Note that compiling in debug succeeds. <!-- 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. --: If the function is uncommented, rustc instead crashes with an illegal instruction searched nightlies: from nightly-2023-04-17 to nightly-2023-04-23 regressed nightly: nightly-2023-04-18 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
This bisects to a MIR inlining PR, but the actual bug here is related to lowering of . It's possible to write code that gets lowered to invalid LLVM IR without MIR inlining, but the code required is rather contrived. This has been extensively discussed on the Zulip: https://rust- I'm surprised nobody else opened an issue for this. Thanks!
Change:
}, _ => None }, <del> None => None </del> <ins> None => { debug!("no parent node of scope_id {}", scope_id) None } </ins> } }

Discussion:
For the input file below, the two distinct invocations of (but with identical arguments) are non-deterministically deciding whether or not to prompt with the "consider using an explicit lifetime parameter" hint. Input file (): Transcript: (See also for a problem with the suggestion actually provided by when it chooses to actually provide one.)
I tested it a bit, and the issue seems to be is fed slightly different information each time. In the first case we have a and in the second . In the constraint graph for some node we are trying to infer, there are multiple incoming edges and outgoing edges to and from . From my understanding the compiler only picks one node from these incoming edges and one node from these outgoing edges, and it doesn't pick the same pair each time (what I don't understand is why I didn't see the and variations).
I'm getting a non-deterministic error message using the latest nightlies: It's non-deterministic on my Fedora 20 machine but not my OSX machine.
Change:
<ins> // check-fail // run-rustfix enum FakeResult<T> { Ok(T) } fn main() { let _x = if true { FakeResult::Ok(FakeResult::Ok(())) } else { FakeResult::Ok(FakeResult::Ok(())) //~ERROR E0308 }; } </ins>

Discussion:
rustc version: rustc 1.65.0-nightly ( 2022-08-25) I have a very small reproducer for a weird fix advice from rustc when the two branches of an if had a type mismatch: This will produce the following output: Applying this fix obviously doesn't help:
label +A-diagnostics +T-compiler +D-invalid-suggestion
Change:
#[no_mangle] pub fn b(exp: u32) -> i64 { // CHECK: %{{[^ ]+}} = icmp ugt i32 %exp, 64 <del> // CHECK: %{{[^ ]+}} = zext i32 %exp to i64 </del> <ins> // CHECK: %{{[^ ]+}} = zext{{( nneg)?}} i32 %exp to i64 </ins> // CHECK: %{{[^ ]+}} = shl nuw i64 {{[^ ]+}}, %{{[^ ]+}} // CHECK: ret i64 %{{[^ ]+}} 2i64.pow(exp)

Discussion:
Seems like the updated test expectations don't quite match up with LLVM 18, first failing check is: Found over at our experimental rust + LLVM @ HEAD build bot: Looks like LLVM 18 adds some extra -s, testing a PR to fix this:
label: +A-LLVM
Change:
<ins> error[E0603]: tuple struct `Bar` is private --> $DIR/issue-75062-fieldless-tuple-struct.rs:9:10 | LL |     foo::Bar(); |          ^^^ private tuple struct | note: the tuple struct `Bar` is defined here --> $DIR/issue-75062-fieldless-tuple-struct.rs:5:5 | LL |     struct Bar(); |     ^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0603`. </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. --It is very finicky to reproduce. is as minimal as I could get without significantly changing the structure of the macro or having other errors cover it up. Apologies for the mess! Updated 2020-08-04: I got it down to a total of only 130 lines of code. Please review the improved output below. Instructions: the project: The ICE was triggered by change in , where I simply changed the scoping on a nested inner generated by a macro from public to private. : On stable, errors regarding scoping are printed (this error is repeated many times): On nightly, a backtrace occurs. <details<summary<strongBacktrace</strong</summary<p</p</details<details<summary<strongcargo expand with pub struct (updated 2020-08-04)</strong</summary<p</p</details
I have reduced this reproducer from about 500 lines of code total to 130 lines total. There are more syntax errors in it now, but the panic still triggers before them. Most of the other things I could change create an error that short circuits the compiler before the panic could trigger. EDIT: I also just updated the backtrace, because I didn't ask for a backtrace last time.
Let's get a MCVE and bisect the culprit PR. ping cleanup
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
Minimized:
is the likely cause.
Assigning as and removing .
Change:
<ins> error[E0658]: existential types are unstable --> $DIR/issue-60371.rs:8:5 | LL |     existential type Item: Bug; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: for more information, see https://github.com/rust-lang/rust/issues/34511 = help: add #![feature(existential_type)] to the crate attributes to enable error[E0277]: the trait bound `(): Bug` is not satisfied --> $DIR/issue-60371.rs:8:5 | LL |     existential type Item: Bug; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Bug` is not implemented for `()` | = help: the following implementations were found: <&() as Bug> = note: the return type of a function must have a statically known size error: could not find defining uses --> $DIR/issue-60371.rs:8:5 | LL |     existential type Item: Bug; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 3 previous errors Some errors have detailed explanations: E0277, E0658. For more information about an error, try `rustc --explain E0277`. </ins>

Discussion:
Another ICE that uses a nightly only feature, but still crashes on stable, beta and nightly without the flag. According to godbolt, this sneaked in with 1.34. 1.33 and lower are not affected. <details<summaryBacktrace:</summary
nevermind I was thinking of , which you also filed
I found this verry related:
Again this is kinda 2 issue's in 1, so I dont know if this should have it's own issue... After some more trying, I found this also panics, but only on nightly: Notice I removed the on the line <details<summaryBacktrace:</summary</details
Another one, stable, beta & nightly: <details<summaryBacktrace:</summary</details
triage: P-high due to ICE; removing nomination.
Likely duplicate from
Change:
onEachLazy(document.querySelectorAll(".rustdoc-toggle > summary:not(.hideme)"), function(el) { el.addEventListener("click", function(e) { <del> if (e.target.tagName != "SUMMARY") { </del> <ins> if (e.target.tagName != "SUMMARY" && e.target.tagName != "A") { </ins> e.preventDefault(); } });

Discussion:
For example, I can't click any links (i.e., when I click them, nothing happens) in header. Likewise, I can't click any links for , but I can click links in , which has no tag. This same behavior occurs in the docs, though every method is documented and thus has a tag, so there's no comparison to non- methods. This is a regression in nightly 1.58.0. I'm using Safari on macOS; I don't know if this reproduces on other browsers.
This is probably ; I don't know why that change was made or if this is intentional. cc
I can't imagine this part of the behavior is intentional, since it breaks a lot of rustdoc's UI.
We really need more GUI tests so this can't happen again...
Can confirm, that wasn't intentional. I manually checked during development to make sure that wouldn't happen, but it must have broken. Sorry for that, and sorry for not adding a GUI test for it. I'll post a fix in a moment.
Assigning priority as in the prioritization working group.
Change:
additional_attrs: Option<(&[ast::Attribute], DefId)>, ) -> Attributes { let mut doc_strings: Vec<DocFragment> = vec![]; let clean_attr = |(attr, parent_module): (&ast::Attribute, Option<DefId>)| { if let Some(value) = attr.doc_str() { trace!("got doc_str={:?}", value);

Discussion:
I expected this change to work: But it causes to panic: <details<summaryBacktrace</summary</detailsI don't have time to look into it right now, but I wouldn't expect it to be too hard to fix and it would reduce the memory usage of rustdoc by quite a lot. I'd suggest starting by adding a bunch of assertions that the old and new behavior of is the same and investigating the assertion failures. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Since would unconditionally add a final newline, shouldn't the note say that (instead of "this can") and the 'pop's be unconditional? Across the entire codebase, there's just one other invocation of 'adddocfragment' (currently line 1087 ); it seems that that doesn't need a newline popped. Instead, I think the last function you modified () should only have a newline popped for the last , as would only be false for the last , as far as I can tell. I made a commit to that effect in the PR above, though I have to resolve the merge conflict somehow.
feel free to try that out and see if it works :) like I said, I don't have time to work on it right now.
Change:
bounds } <ins> fn compare_impl<'a, 'b>(lhs: &'a &&Impl, rhs: &'b &&Impl) -> Ordering { let lhs = format!("{}", lhs.inner_impl()); let rhs = format!("{}", rhs.inner_impl()); // lhs and rhs are formatted as HTML, which may be unnecessary name_key(&lhs).cmp(&name_key(&rhs)) } </ins> fn item_trait( w: &mut fmt::Formatter, cx: &Context,

Discussion:
impl<'a, TIntoIterator for &'a mut [T; 12] impl<'a, TIntoIterator for &'a [T; 25] impl<'a, TIntoIterator for &'a mut [T; 21] impl<'a, TIntoIterator for &'a [T; 2] ... this ordering doesn't make any sense and makes the docs harder to navigate.
It has been fixed on nightly. The fix will come to stable eventually.
Change:
debug!("visit_terminator_kind: kind={:?}", kind); match &kind { TerminatorKind::Call { destination: Some((into, _)), .. } => { <del> if let Some(local) = into.base_local() { debug!( "visit_terminator_kind: kind={:?} local={:?}  never_initialized_mut_locals={:?}", kind, local, self.never_initialized_mut_locals ); let _ = self.never_initialized_mut_locals.remove(&local); } </del> <ins> self.remove_never_initialized_mut_locals(&into); }, TerminatorKind::DropAndReplace { location, .. } => { self.remove_never_initialized_mut_locals(&location); </ins> }, _ => {}, }

Discussion:
(sorry if this is an duplicate or the wrong repo :innocent: ) () Current behavior: no warning Expected behavior: The variable clearly doesn't need to be mutable, still, nothing is detected and no warning is emitted. Rust 1.35.0 (Using the , also in ())
The warning appears again if you switch to 2015 edition. Huh. Nice catch!
I found that Stable 2015 edition produces the warning and everything else doesn't.
cc (likely caused by NLL migrate mode, which was enabled in for the 2015 edition)
Yes, looks like another nll bug. If someone wants to have a go at this, the issue is that we are treating DropAndReplace differently to Assign for the purposes of this lint.
I can try doing it I just don't know here to begin.
I don't know this code too well, but take a look at . The first thing I'd try is adding a case for to the match in that mirrors what's done for .
Makes sense thank you. I was looking at librustc_lint and couldn't find anything.
Change:
debug_assert!(source.len() == 0); // We should have consumed the source buffer. uint } <del> /// Computes the unsigned absolute value without wrapping or panicking. #[inline] pub fn uabs(value: i64) -> u64 { // The only tricky part here is if value == i64::MIN. In that case, // wrapping_abs() returns i64::MIN == -2^63. Casting this value to a u64 // gives 2^63, the correct value. value.wrapping_abs() as u64 } </del>

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for on signed integral types. The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- First implemented in <!-- Include a list of all the PRs that were involved in implementing the feature. --
Are there any outstanding issues with this feature gate? It has a trivial implementation that is unquestionably correct, and it seemed quite clear in the RFC that it was desired.
One significant issue I see is currently the implementation for returns instead of . Edit: I found the reason. The is instead of as . This was not a problem so far because didn't appear in any function signature until now. So changing the call site for all pointer sizes should be enough.
Hmm…the behavior for different widths (16, 32, or 64). However, usize and u16/32/64 are not the same type. I'll make a modification locally and open a PR shortly.
Yes, exactly. Good job with the PR!
Why of returns instead of ? IMHO, it is not valid.
This is fixed on nightly (that you need anyway to use this for now)
Nice, thank you!
Change:
} } <del> fn check_for_bindings_named_same_as_variants(cx: &MatchVisitor<'_, '_, '_>, pat: &Pat<'_>) { </del> <ins> fn check_for_bindings_named_same_as_variants( cx: &MatchVisitor<'_, '_, '_>, pat: &Pat<'_>, rf: RefutableFlag, ) { </ins> pat.walk_always(|p| { if let hir::PatKind::Binding(_, _, ident, None) = p.kind { if let Some(ty::BindByValue(hir::Mutability::Not)) =

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: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case
Change:
ExprKind::Continue { .. } | ExprKind::Break { .. } | ExprKind::InlineAsm { .. } | <del> ExprKind::Return {.. } => { </del> <ins> ExprKind::Return { .. } => { </ins> unpack!(block = this.stmt_expr(block, expr)); this.cfg.push_assign_unit(block, source_info, destination); block.unit()

Discussion:
The following error results from dereferencing a as in this code:
What’s the correct fix? Compiler error with a nice error message?
I think this should compile and UB, but a lint against this is probably a good idea.
Reduced test case:
I'm working on a fix for this. Progress on . The idea is to avoid the typing issues entirely by terminating the blocks with as soon as a -value is constructed. Currently the examples given here are fixed, but some more convoluted examples still crash.
Change:
<ins> #![feature(exclusive_range_pattern)] #![allow(unreachable_patterns)] fn main() { match 0u8 { 251..257 => {} //~^ ERROR literal out of range //~| ERROR literal out of range 251..=256 => {} //~^ ERROR literal out of range //~| ERROR literal out of range _ => {} } } </ins>

Discussion:
For a match where I'm matching on a , I put on accident, and then rather than saying that 256 is out of range for , it decided to wrap 256 to 0 and then error that 251 is lower than the end of the range: Clearly this is not a good situation. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd like to fix this claim
Triage: I'm going to release assignment due to inactivity. If you're still interested in this, feel free to re-claim. release-assignment
Explanation on how to solve this in
Change:
panic!("expected abort due to worker thread errors") }, Err(_) => { <del> sess.fatal("Error during codegen/LLVM phase."); </del> <ins> bug!("panic during codegen/LLVM phase"); </ins> } };

Discussion:
Related to . If a fatal error occurs in LLVM, the compiler exits with status 1. This is problematic, because if a test is expecting a compilation failure, the test could still pass. It also makes it difficult to test for the presence of ICEs in general. A simple fix would be to patch our copy of LLVM to exit with 101 (like ICEs) in , but any other ideas would be appreciated.
Those error functions all call , which sounds like it could be a great hook for us, but then that only calls . :/
There is  though, and that handler gets called first.
That sounds nice, but if we exit with 101 (or simply panic) in the handler won't we be skipping any other cleanup (, plus any future cleanup that gets there)? Or could we just call it in our handler? I'm interested in putting a patch together, but I'm unfamiliar with how we link Rust to C++. The error handler needs to be able to consume a .
We shouldn't do anything that looks like exception unwinding. See : I think we can call it -- it's publicly declared in . We might want to keep a note to make sure we check for new cleanup needed when we update LLVM though. We bridge C++ code in . You could just write our handler in C++ there, and add some C-FFI function for to call and hook that up.
Change:
// where a brace being opened means a block is being started. Look // ahead for the next text to see if `span` is followed by a `{`. let sm = self.r.session.source_map(); <del> let mut sp = span; loop { sp = sm.next_point(sp); match sm.span_to_snippet(sp) { Ok(ref snippet) => { if snippet.chars().any(|c| !c.is_whitespace()) { break; } } _ => break, } } </del> <ins> let sp = sm.span_look_ahead(span, None, Some(50)); </ins> let followed_by_brace = matches!(sm.span_to_snippet(sp), Ok(ref snippet) if snippet == "{"); // In case this could be a struct literal that needs to be surrounded // by parentheses, find the appropriate span. <del> let mut i = 0; let mut closing_brace = None; loop { sp = sm.next_point(sp); match sm.span_to_snippet(sp) { Ok(ref snippet) => { if snippet == "}" { closing_brace = Some(span.to(sp)); break; } } _ => break, } i += 1; // The bigger the span, the more likely we're incorrect -- // bound it to 100 chars long. if i > 100 { break; } } </del> <ins> let closing_span = sm.span_look_ahead(span, Some("}"), Some(50)); let closing_brace: Option<Span> = sm .span_to_snippet(closing_span) .map_or(None, |s| if s == "}" { Some(span.to(closing_span)) } else { None }); </ins> (followed_by_brace, closing_brace) }

Discussion:
As a python programmer, forgetting a in an assignment to a variable that didn't exist before is an easy mistake to make. () Rust sees two uses of an undefined variable here (E0425 twice): While the second one is fine, in the first case I would have really appreciated a sentence like this: This would helped me as a newcomer to the language, because it does an educated guess what the problem might be and tells me how to fix it. I think the hint should be if the value is assigned to (first error), but not if it is used as an argument (second error). I hope this is the right place and format to file this suggestion, I would appreciate hints if this is not the case. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is the right place, however you should use the "diagnostic" template when creating issues like this. Thanks for the issue though. label +T-compiler +A-diagnostics
claim