jiebi/CodeConvo huggingface dataset:
Change:
/// As a result, using `&packed.unaligned as *const FieldType` causes immediate /// *undefined behavior* in your program. /// <ins> /// Instead you must use the [`ptr::addr_of!`](addr_of) macro to /// create the pointer. You may use that returned pointer together with this /// function. /// </ins> /// An example of what not to do and how this relates to `read_unaligned` is: /// <del> /// ```no_run </del> <ins> /// ``` </ins> /// #[repr(packed, C)] /// struct Packed { ///     _padding: u8,

Discussion:
Rust 1.51 was released yesterday and included the  macro. Its documentation talks about its usage in creating pointers to unaligned fields without the need for an intermediate reference: Despite that, the documentation of [] states the following: The documentation of [] should be updated to reflect the new changes in the language. : and modify labels: T-doc claim []: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Change:
<ins> // Validation stops the test before the ICE we used to hit //@compile-flags: -Zmiri-disable-validation #![feature(never_type)] #[derive(Copy, Clone)] pub enum E { A(!), } pub union U { u: (), e: E, } fn main() { let E::A(ref _a) = unsafe { &(&U { u: () }).e }; } </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
seem like options that when paired together would cause issues... At first glance, I'm actually not sure why this is filed as a bug.
I agree. Nobody should be testing , I don't know why those passes are even in the codebase. But this is a bug. I've found this in real code with a much smaller set of flags: And this bisects to Bisected by hand, there's no nightly with that PR yet. Don't know where Matthias got that toolchain.
Afaict likes to do ICE testing against master
We just hit this on Fuchsia as well. I think we should revert the PR until we fix this issue and reland it.
Another one with
Also here's a list of files from the rustc repo that all seem to trigger the problem in one way or another
Looks like there is one more issue in GVN ():
There is no basis for the assumption that interpreter will never downcast to an uninhabited variant:
nice example! That assert was as an experiment to see if we ever hit that codepath, and it seems like the answer is yes. It should thus be removed, with a suitable const-eval test case.
I wonder if that code shouldn't have a read somewhere though... it is conceptually a match after all. Still, the assertion should go: That adds test, but not the others.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
/// /// The `len` argument is the number of **elements**, not the number of bytes. /// <ins> /// # Unsafety /// </ins> /// This function is unsafe as there is no guarantee that the given pointer is /// valid for `len` elements, nor whether the lifetime inferred is a suitable /// lifetime for the returned slice. /// <ins> /// `p` must be non-null, even for zero-length slices. /// </ins> /// # Caveat /// /// The lifetime for the returned slice is inferred from its usage. To

Discussion:
Link to the docs in question:
Is there any API that accepts a null raw pointer?
What about ptr::copy if the count is zero?
transmute does :)
I suppose I implicitly meant "explicitly accepts a pointer, and not some opaque T"
Change:
}; let mut file = write::Object::new(binary_format, architecture, endianness); <del> match architecture { </del> <ins> let e_flags = match architecture { </ins> Architecture::Mips => { let arch = match sess.target.options.cpu.as_ref() { "mips1" => elf::EF_MIPS_ARCH_1,

Discussion:
When compiling for , the resulting binaries should have the OS/ABI () field in the ELF header set to Standalone () as per the LLVM target, which it did before . Now, it is set to "UNIX - System V", which I only tested on Linux. identified the introduction of synthetic object files for exported symbols from to have changed this: I did not have a deep dive into the code yet, but I assume the synthetic object file has the host's OS/ABI, which is prevalent over the other OS/ABI. do you have any insight? Related:
Hmm, the crate sets to , which seems to be an alias of . Unfortunately currently crate provide no ways to set this field, so to fix this I suppose some postprocessing of the generated ELF file would be needed. I am surprised that this doesn't show up earlier, given that exactly the same routine is used to create rmeta files. Does hermit not support dylibs?
Ah, yes, sets the OS/ABI here: . I think there are three possibilities: proper support for setting OS/ABI in . This would probably take a lot of effort. before passing it to in This can be done quite easily. the synthetic object file after (?) the real ones. I think lld infers the OS/ABI from the first proper input object file, if I am reading this correctly:  For 1 and 2 we would need to know the proper OS/ABI from the real object files though. I am not sure how easy that would be to come by. What do you think? Hermit is a unikernel, which is linked statically to the application. There is no support for dynamic libraries. A similar problem occurs when using though (). This issue was closed, because we did not need anyways.
Here's how LLVM determines what OSABI to use: We could look at and use the same logic to determine the OSABI. The synthetic object can be placed after real object files (it only needs to be linked before any libraries), but assuming the linker only looks at the first object file sounds a bit hacky. cc what's your take on this issue?
object-rs has only recently been taught to set expected by some MIPS targets (). In think we can teach object-rs to set too, and then just set it, if some linker expects it.
All right.

Thanks for the quick feedback. I'll cook something up in the coming days.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
I opened , but first the necessary changes in have to be released.
Change:
fn suggest_derive( &self, err: &mut DiagnosticBuilder<'_>, <del> unsatisfied_predicates: &Vec<( </del> <ins> unsatisfied_predicates: &[( </ins> ty::Predicate<'tcx>, Option<ty::Predicate<'tcx>>, Option<ObligationCause<'tcx>>, <del> )>, </del> <ins> )], </ins> ) { let mut derives = Vec::<(String, Span, String)>::new(); let mut traits = Vec::<Span>::new();

Discussion:
Given the following code: The current output is: Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
if ambiguities.len() > 5 { let infcx = self.infcx; if !ambiguities.iter().all(|option| match option { <del> DefId(did) => infcx.fresh_args_for_item(DUMMY_SP, *did).is_empty(), </del> <ins> DefId(did) => infcx.tcx.generics_of(*did).count() == 0, </ins> ParamEnv(_) => true, }) { // If not all are blanket impls, we filter blanked impls out. ambiguities.retain(|option| match option { <del> DefId(did) => infcx.fresh_args_for_item(DUMMY_SP, *did).is_empty(), </del> <ins> DefId(did) => infcx.tcx.generics_of(*did).count() == 0, </ins> ParamEnv(_) => true, }); }

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 have a full repro in , but the short version is, it seems like some cases of code that look_ like an omitted type should be inferrable: while certain dependencies, leading to , are in the compile pathway (I could only get it to reproduce via a weird dependency chain via a workspace and a couple of public crates), can lead to an overflow: If the dependency chain is altered in any way that I could divine, the expected error is output: <!-- 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. --I've reproduced this bug both in and in . :
Bisects to nightly-2023-10-07. In nightly-2023-10-06, we get "the expected error" shown above.
Looks like , because reproduces the issue, but the previous commit on master () does not.
Minimal:
I'll put up a fix in a sec
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> // edition: 2021 pub(crate) trait Inbox<M> { async fn next(self) -> M; } pub(crate) trait Actor: Sized { type Message; async fn on_mount(self, _: impl Inbox<Self::Message>); } impl<'a> Actor for () { //~^ ERROR the lifetime parameter `'a` is not constrained by the impl trait, self type, or predicates type Message = &'a (); async fn on_mount(self, _: impl Inbox<&'a ()>) {} } 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</details
label +E-needs-mcve
Minimized to:
might be similar to , cc who self-assigned and probably knows more about this stuff ^^
in case we need more code snippets, here are 60 of them that that can trigger the ice in some way or another :upsidedownface:
I'm pretty sure all (or at least most) of these examples are not related. This issue is specifically the case where the code used to emit: and now ICEs. is unrelated except for the ICE message.
Ah so this () is a new one? Need to put some though into automatic ice distinction (perhaps based on query stack?)
Yeah, there's a class of ICEs that have the same name and often very different root causes (i.e. ICEs in snapshot-vec) and this is one of them.
Change:
<ins> # `abi_x86_interrupt` The tracking issue for this feature is: [#40180] [#40180]: https://github.com/rust-lang/rust/issues/40180 ------------------------ </ins>

Discussion:
see I'm happy to help mentor anyone who wants to fix this issue.
Hello, I would like to work on this issue.
I would love to work on this and be mentored as well in case topecongiro can not. Thank you!
got sent in, so maybe we can work together on some other issue? Just let me know, happy to help you help me.
That would be great, thank you so much would love to work with you.
Awesome. Maybe jump on IRC and message me? Or comment in another issue marked E-mentor? Whatever works
Awesome! What is your nick on IRC? Mine is jhorwitz
same as github: steveklabnik
Change:
<ins> // Copyright 2018 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. pub trait MyIterator { } pub struct MyStruct<T>(T); macro_rules! array_impls { ($($N:expr)+) => { $( impl<'a, T> MyIterator for &'a MyStruct<[T; $N]> { } )+ } } // @has issue_53812/trait.MyIterator.html '//*[@id="implementors-list"]//h3[1]' 'MyStruct<[T; 0]>' // @has - '//*[@id="implementors-list"]//h3[2]' 'MyStruct<[T; 1]>' // @has - '//*[@id="implementors-list"]//h3[3]' 'MyStruct<[T; 2]>' // @has - '//*[@id="implementors-list"]//h3[4]' 'MyStruct<[T; 3]>' // @has - '//*[@id="implementors-list"]//h3[5]' 'MyStruct<[T; 10]>' array_impls! { 10 3 2 1 0 } </ins>

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:
<ins> error: expected one of `!` or `::`, found `foo` --> $DIR/fn-defined-using-fun.rs:6:5 | LL | fun foo() {} | --- ^^^ expected one of `!` or `::` | | | help: write `fn` instead of `fun` to declare a function error: aborting due to previous error </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. 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: <!-- Please provide a link to --The current output is: Ideally the error message should suggest replacing or with . <!-- 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
New to rustc community and wants to contribute code. there any options to debug rustc which line of which file the error abort happens? can I dump the hierarchy tree for debugging use? C++ we usually use env for compiler debugging. How do rustc often use? Very newbie questions, thank you in advance.
label +E-easy +E-mentor Welcome to Rust! This might be some help -- This issue is very similar to , so take a peek at the diff there. IMO the following tokens are enough to check against function (Julia/JavaScript/etc) func (Go) fun (Kotlin) def (Python) Have fun! <3
Instructions -- Add a check if prevtoken is either ///etc Emit a message, something along the lines of "use instead of <prevtokento make a function" using , there are a few usages of this in the same file so those might be good examples. Add tests for this in -- Ideally each suggestion would have a test. Should be helpful to take as a reference
We can include if necessary.
Hi guys, another rust newbie looking for something easy to get started here. are you still on this or could go with my attempt here?

ypprog does seem to be active and it hasn't been that long, if you'd like you can pick another issue. =) Try going through the E-Easy and/or E-Mentor category for easy issues. However, to clarify, if an issue which is claimed doesn't seem to have any work done for a long period of time (A month or so is a good amount of time) -- Feel free to ping the assignee to confirm and handle it accordingly.
With these changes, I also think it is important to implement improved error messages for when a user puts the return type at the start of the function instead of the end. Given this code: The error output is:
I feel like adding might also be helpful for C++ developers :)
Is this still being worked on?
release-assignment
claim
Change:
<ins> 1|       |// Regression test for issue #98833. 2|       |// compile-flags: -Zinline-mir 3|       | 4|      1|fn main() { 5|      1|    println!("{}", live::<false>()); 6|      1|} 7|       | 8|       |#[inline] 9|      1|fn live<const B: bool>() -> u32 { 10|      1|    if B { 11|      0|        dead() 12|       |    } else { 13|      1|        0 14|       |    } 15|      1|} 16|       | 17|       |#[inline] 18|      0|fn dead() -> u32 { 19|      0|    42 20|      0|} </ins>

Discussion:
This can be seen here: To reproduce:
Last passing run was so this regressed between 2022-06-30 and 2022-07-02.
Minimized a reproducer. : : Execution:
label regression-untriaged
Bisection says searched nightlies: from nightly-2022-06-29 to nightly-2022-07-03 regressed nightly: nightly-2022-07-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsSo,
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Unfortunately while this fixes the minimal reproducer, it doesn't fix the full case. Would you prefer I file a new bug, or should this one be re-opened? To reproduce:
It's not very minimized, but slightly better. : : Empty
searched nightlies: from nightly-2022-07-07 to nightly-2022-07-22 regressed nightly: nightly-2022-07-09 searched commits: from to regressed commit:
Interesting, I had assumed based on the matching panic message that it'd have the same regressing commit.
Happy to report that with the latest nightly we're back to green on nightly. Thanks much
Thanks the first fix was enough for Suricata :-)
Thanks so much, pydantic-core has been pinned to but is not back on nightly.
Change:
[[package]] name = "compiletest_rs" <del> version = "0.3.24" </del> <ins> version = "0.3.25" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "676a74b493d50ac33cacd83fd536597e6b52c0b46b9856f7b9c809d82fef4ac0" </del> <ins> checksum = "f75b10a18fb53549fdd090846eb01c7f8593914494d1faabc4d3005c436e417a" </ins> dependencies = [ "diff", "filetime",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. 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! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
.encode_wide() .chain(Some(0)) .collect::<Vec<_>>(); <ins> let mut flags = c::FILE_FLAG_FIRST_PIPE_INSTANCE | c::FILE_FLAG_OVERLAPPED; if ours_readable { flags |= c::PIPE_ACCESS_INBOUND; } else { flags |= c::PIPE_ACCESS_OUTBOUND; } </ins> let handle = c::CreateNamedPipeW(wide_name.as_ptr(), <del> c::PIPE_ACCESS_INBOUND | c::FILE_FLAG_FIRST_PIPE_INSTANCE | c::FILE_FLAG_OVERLAPPED, </del> <ins> flags, </ins> c::PIPE_TYPE_BYTE | c::PIPE_READMODE_BYTE | c::PIPE_WAIT |

Discussion:
It looks like the use of overlapped I/O on stdio ports may cause some problems in Windows. When I try to shell out to using on the stderr port, the command runs successfully but hangs at the end. pointed me to this commit as the likely culprit: Here's the smallest test case I could figure out how to create: I wanted to try to come up with a minimal Node script to shell out to, as opposed to . Unfortunately, I'm not good enough at debugging npm and Node to figure out exactly what they're doing that causes the hang.
Ok I've tested this and it's a stable-to-stable regression that happened between 1.8 and 1.9. I believe the 1.9 release is indeed the first one with , the likely change which is a culprit. Tagging appropriately as such.
It looks like Rust is passing overlapped-mode pipe handles to the child process. The function returns two overlapped HANDLES. I'm not sure the overlapped mode can be changed after the fact -- maybe would work -- but I don't see it used anywhere, and I'd wonder about its use on the server handle. If the child inherits overlapped-mode handles, it would need to do async I/O to stdin/stdout/stderr. By convention, it does sync I/O using lpOverlapped==NULL, but that has undefined behavior if the handles are overlapped pipes. FWIW: the server and client ends of a named pipe aren't quite symmetric, but I'm guessing it doesn't matter whether the child process receives a server pipe or a client pipe? The interesting thing is that writing to a broken pipe returns , but reading from one returns . Apparently this is true for both ends. (I apparently wrote for this back in June'16.) I'd probably pass the client end to the child process, because it doesn't make sense that a program can call DisconnectNamedPipe on its stdio handles. (DisconnectNamedPipe doesn't work on client handles.) I made a Rust + C++ test case demonstrating how passing overlapped handles to the child breaks:
Fascinating! Thanks for the links That perfectly explains I think what's going on here. I think I can see the fix here, so I'll work on that pronto.
Yeah, I think the fix is easy -- use non-overlapped handles for the child but overlapped handles for the parent.
Change:
<del> Subproject commit 84f190a4abf58bbd5301c0fc831f7a96acea246f </del> <ins> Subproject commit 0af6c732ec6ca189cd7725e4a7d4290793046e83 </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. --Update: I forgot to write the command, its I tried this code: I expected to see this happen: compiles fine Instead, this happened: I get an . This does not occur on . <!-- 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
We are also seeing this error with rust + thread sanitiser on x86.
Probably caused by , though the actual bug may be in LLVM. cc
We're seeing a weird bitcode level error in our rustc built against head that root-caused to that same PR FWIW.
It's a tsan bug:
Confirmed that fixes the bug we were seeing too. Thanks for the quick fix!
Change:
// Check for foreign traits being reachable. self.tcx.visible_parent_map(()).get(&def_id).is_some() }; <ins> if Some(def_id) == self.tcx.lang_items().sized_trait() && let Some(hir::Node::TraitItem(hir::TraitItem { ident, kind: hir::TraitItemKind::Type(bounds, None), .. })) = tcx.hir().get_if_local(item_def_id) // Do not suggest relaxing if there is an explicit `Sized` obligation. && !bounds.iter() .filter_map(|bound| bound.trait_ref()) .any(|tr| tr.trait_def_id() == self.tcx.lang_items().sized_trait()) { let (span, separator) = if let [.., last] = bounds { (last.span().shrink_to_hi(), " +") } else { (ident.span.shrink_to_hi(), ":") }; err.span_suggestion_verbose( span, "consider relaxing the implicit `Sized` restriction", format!("{separator} ?Sized"), Applicability::MachineApplicable, ); } </ins> if let DefKind::Trait = tcx.def_kind(item_def_id) && !visible_item {

Discussion:
Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: A similar error message with an unsized generic type argument does mention the implicit bound. Unfortunately, it also doesn't explain the implicit bound up front in the "required by this bound" text. (It mentions it when suggesting to relax the implicit bound, but I think it would be better to mention it up front as well.) Both error messages could benefit from changing the "required by this bound" text to "required by an implicit bound". <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-associated-items +A-traits +A-typesystem +D-papercut +D-terse
I'm working on a pull request for this issue. claim
Oh! Very sorry, if you spent too much time on this already, but I have done some work around this already in If you want, you can take over it and bring it to completion, there are some cases, like that still need to be addressed and I haven't yet figured out. Alternatively, if you can find a way to accomplish the same result without touching the and instead deal only with a new , that would be preferable to my approach.
I've pushed what I have so far to , sorry if it conflicts with stuff you've already done. If you'd like to take a look at it, that would be great. I'll take a look at what you have as well. There are some issues to be worked out with conflicting suggestions for associated types for vs the existing suggestion for adding an explicit to a trait's bounds, in test cases such as within a trait declaration.