jiebi/CodeConvo huggingface dataset:
Code change:
extern "C" { pub fn LLVMRustInstallFatalErrorHandler(); <ins> pub fn LLVMRustDisableSystemDialogsOnCrash(); </ins> // Create and destroy contexts. pub fn LLVMRustContextCreate(shouldDiscardNames: bool) -> &'static mut Context;

Related discussion:
text: The Windows CI build with LLVM assertions enabled recently hung without an error message. It turned out to be an LLVM assertion failure resulting in a dialog which needed to be acknowledged, see According to the such a dialog is always displayed, but that is not the whole truth. Apparently can be used to customize assertion failure handling. We should definitely make assertions failures exit with error after printing failure information to stderr instead of displaying a dialog and hanging. label O-windows
Could this be part of why we're getting so many hangs in the CI?
That was responsible for four stuck builds recently. I don't think it was responsible for many timed out builds before that.
Posted with a possible solution.
Code change:
E0701: include_str!("./error_codes/E0701.md"), E0704: include_str!("./error_codes/E0704.md"), E0705: include_str!("./error_codes/E0705.md"), <ins> E0706: include_str!("./error_codes/E0706.md"), </ins> E0712: include_str!("./error_codes/E0712.md"), E0713: include_str!("./error_codes/E0713.md"), E0714: include_str!("./error_codes/E0714.md"),

Related discussion:
text: we currently emit We should tell people that trait functions are not possible , and possibly point them to . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Created
Code change:
// don't create labels for compiler-generated spans Some(_) => None, None => { <del> let (span, suggestion) = suggest_ampmut( self.infcx.tcx, local_decl, opt_assignment_rhs_span, *opt_ty_info, ); </del> <ins> let (span, suggestion) = if name != kw::SelfLower { suggest_ampmut( self.infcx.tcx, local_decl, opt_assignment_rhs_span, *opt_ty_info, ) } else { match local_decl.local_info.as_deref() { Some(LocalInfo::User(ClearCrossCrate::Set( mir::BindingForm::Var(mir::VarBindingForm { opt_ty_info: None, .. }), ))) => { suggest_ampmut_self(self.infcx.tcx, local_decl) } // explicit self (eg `self: &'a Self`) _ => suggest_ampmut( self.infcx.tcx, local_decl, opt_assignment_rhs_span, *opt_ty_info, ), } }; </ins> Some((true, span, suggestion)) } }

Related discussion:
text: Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --is not a valid argument; it needs to be either or . For some reason this problem only happens when the function is async.
This is the same diagnostic you get when mutably dereferencing let-bindings that are : So it seems like this has to do with the fact that ast_lowering emits a binding when desugaring. I wonder if we can get the name of the variable when emitting this diagnostic, and special-case when it .
Another (possibly related?) bug: doesn't have the suggestion if it's in an async block:
Same with closures. I would probably classify that as a separate bug, since the original bug has to do specifically with desugaring, and the latter has to do with closure/generator captures.
Thanks for the report and getting a PR up so quickly! label +AsyncAwait-Triaged +AsyncAwait-Polish
Another similar error, not related to async this time: isn't valid Rust.
Code change:
/// Was the origin of the `span` from a scrutinee expression? /// /// Otherwise there is no scrutinee and it could be e.g. from the type of a formal parameter. <del> origin_expr: bool, </del> <ins> origin_expr: Option<&'tcx hir::Expr<'tcx>>, </ins> /// The span giving rise to the `expected` type, if one could be provided. /// /// If `origin_expr` is `true`, then this is the span of the scrutinee as in:

Related discussion:
text: <!-- 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 to the user that they need to initialize the enum variant's value in order to use the . <!-- 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 --
Can you give the output of what it should look like?
It should probably look similar to the suggestion given for and So I guess sth. like: Edit: Or instead of saying “to instantiate this tuple variant” we could say “to call this function” like it's done for the erroneous snippet (where is a ).
claim
commit the fix
Code change:
[submodule "src/llvm-project"] path = src/llvm-project url = https://github.com/rust-lang/llvm-project.git <del> branch = rustc/18.0-2024-02-13 </del> <ins> branch = rustc/18.1-2024-05-19 </ins> shallow = true [submodule "src/doc/embedded-book"] path = src/doc/embedded-book

Related discussion:
text: I get a segfault when I try to run on the following code: I see the same behavior with the latest nightly . I see no error with 1.77.0 or earlier. It also works fine on Linux, and on an older Intel Macbook. I also updated to the latest XCode to make sure all parts of my toolchain were up to date. Doing so did not make the segfault go away.
The problem disappears if I turn off incremental compilation by adding this to the :
I believe this bisects to LLVM 18 from cc
We are hitting an LLVM assertion:
Could someone please run and then repeat the rustc command with and share the bitcode files?
I can reproduce it, and I will try to reduce it.
Upstream issue: Reduced:
It has already been backported to LLVM 18: label +llvm-fixed-upstream
Code change:
[submodule "src/llvm-project"] path = src/llvm-project url = https://github.com/rust-lang/llvm-project.git <del> branch = rustc/18.0-2024-02-13 </del> <ins> branch = rustc/18.1-2024-05-19 </ins> shallow = true [submodule "src/doc/embedded-book"] path = src/doc/embedded-book

Related discussion:
text: <!-- 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. --This bug is spotted jointly by and We tried this code (minimized by and I expected to see this happen: The program should exit without error. Instead, this happened: segmentation fault. Notice that the code will pass . (). The error is reproducible with larger than . The error seems to be related, as does not reproduce the bug. There seems to be no bug in LLVM IR. noticed that produces different asm compared with the one in the ELF output. Notice that we encountered an ICE while exploring the code (for now, we are not sure whether the ICE is related to SEGV, we can file a separate report for ICE if needed). Basically, invoking the rustc consecutively, one will get (cleaning up the directory can help): <!-- 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. --Both nightly and stable versions are affected :
may be running into
This started on stable in 1.73, and bisects to : A couple notes, when using cargo: incremental compilation is not enabled on release builds for people who opt into optimizing dependencies even in debug builds: incremental compilation is not enabled for dependencies either, only local crates It would be interesting to see exactly what impacts codegen here when enabling incremental compilation of a single session (but at the same time, it seems probable that not many users should encounter this issue in the more common configurations?).
Some additional context: the code is largely related to ecow. In case people compile typst/ecow related code with incremental build and level 1 optimization enabled and run into segmentation fault, this should be the bug behind it.
So the error happens just from adding , without there actually being a previous incremental cache there? Wow. Cc Seems likely that the LLVM 17 update is involved. Cc
I can confirm that this reproduces with an empty cache -- which should be good news in terms of debugging the issue. I'm pretty sure this is a ThinLTO-related bug and incremental somehow configures CGUs and LLVM settings in a way that triggers the bug. The segfault does not reproduce when compiling with .
Code change:
[submodule "src/llvm-project"] path = src/llvm-project url = https://github.com/rust-lang/llvm-project.git <del> branch = rustc/18.0-2024-02-13 </del> <ins> branch = rustc/18.1-2024-05-19 </ins> shallow = true [submodule "src/doc/embedded-book"] path = src/doc/embedded-book

Related discussion:
text: Running the miscompiled binary in gdb (with ) gives:
Yeah, that would crash...
I think this is a minimal reproducer: We infer that the result of this function is nonnull...
Upstream issue:
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
} let source_string = match file.get_line(line.line_index - 1) { <del> Some(s) => s, </del> <ins> Some(s) => replace_tabs(&*s), </ins> None => return Vec::new(), };

Related discussion:
text: The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim
Code change:
import_id: Option<LocalDefId>, ) { debug!("visiting item {:?}", item); <ins> if self.inside_body { // Only impls can be "seen" outside a body. For example: // // ``` // struct Bar; // // fn foo() { //     impl Bar { fn bar() {} } // } // Bar::bar(); // ``` if let hir::ItemKind::Impl(impl_) = item.kind && // Don't duplicate impls when inlining or if it's implementing a trait, we'll pick // them up regardless of where they're located. impl_.of_trait.is_none() { self.add_to_current_mod(item, None, None); } return; } </ins> let name = renamed.unwrap_or(item.ident.name); let tcx = self.cx.tcx;

Related discussion:
text: <!-- 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. --Consider the following code is local to and inaccessible, and should not be documented. Instead, rustdoc currently documents the module at the same level as . <!-- 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. --: </details
cc does this have to do with those changes you made to item collection?
Very likely. I won't be able to fix it until next week though. EDIT: I suspect it broke from
I just realized that this is broken on stable, too, so I think the cause may be older than that?
Oh. I'm at least happy to realize that I didn't break it recently. Thanks for the report. Will fix it monday.
Code change:
<ins> // check-pass // aux-build:test-macros.rs // compile-flags: -Z span-debug // // Regression test for issue #76182 // Tests that we properly handle patterns with a leading vert #![no_std] // Don't load unnecessary hygiene information from std extern crate std; extern crate test_macros; #[test_macros::print_attr] fn main() { match () { | () => () } } </ins>

Related discussion:
text: The following code: is currently pretty-printed as: If this occurs in a macro invocation, it leads to an instance of
Extra info (but it boils down to what said): Using I get the following log: Rendered diff:
This applies to all trailing separators in theory (except that the separator is leading rather than trailing in this case), but in other cases the difference is fixed up by fuzzy comparison in .
Code change:
fn is_expr_delims_necessary(inner: &ast::Expr, followed_by_block: bool) -> bool { followed_by_block && match inner.kind { <del> ast::ExprKind::Ret(_) | ast::ExprKind::Break(..) => true, </del> <ins> ExprKind::Ret(_) | ExprKind::Break(..) => true, </ins> _ => parser::contains_exterior_struct_lit(&inner), } }

Related discussion:
text: This produces a lint: But removing the parentheses produces an error. This bug was already mentioned in , but that issue is lost in feature-request purgatory since it asks for the version without parentheses to be allowed. I'm opening this issue to track the incorrect lint specifically. (Edit: Fixed the example.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Will wait for to get merged before this is fixed though.
Code change:
fn is_expr_delims_necessary(inner: &ast::Expr, followed_by_block: bool) -> bool { followed_by_block && match inner.kind { <del> ast::ExprKind::Ret(_) | ast::ExprKind::Break(..) => true, </del> <ins> ExprKind::Ret(_) | ExprKind::Break(..) => true, </ins> _ => parser::contains_exterior_struct_lit(&inner), } }

Related discussion:
text: The following code fails to compile (): The compiler error is: Adding parentheses or braces, it will compile fine: The same issue happens with other constructs such as:
cc
I believe the error is expected here, the same as with : Which also needs to be to compile. That said, the warning to remove the necessary parens is definitely wrong. EDIT: Hmm, I might be wrong, actually. The following compiles, which surprised me: as does this: So maybe the parser restriction is only for struct literals, not for keyword-introduced expressions.
Yeah I think is the better comparison here so it's probably a bug.
This is exactly what a thought. I didn't know that this:
For , hmmm... well, I can't come up with a truly devastating example, but eliminating the parentheses could hurt diagnostics.
Code change:
} } <del> /// Checks `#[doc(hidden)]` attributes. Returns `true` if valid. fn check_doc_hidden( &self, attr: &Attribute, meta_index: usize, meta: &NestedMetaItem, hir_id: HirId, target: Target, ) -> bool { if let Target::AssocConst | Target::AssocTy | Target::Method(MethodKind::Trait { body: true }) = target { let parent_hir_id = self.tcx.hir().get_parent_item(hir_id); let containing_item = self.tcx.hir().expect_item(parent_hir_id); if let hir::ItemKind::Impl(hir::Impl { of_trait: Some(_), .. }) = containing_item.kind { let meta_items = attr.meta_item_list().unwrap(); let (span, replacement_span) = if meta_items.len() == 1 { (attr.span, attr.span) } else { let meta_span = meta.span(); ( meta_span, meta_span.until(match meta_items.get(meta_index + 1) { Some(next_item) => next_item.span(), None => match attr.get_normal_item().args { MacArgs::Delimited(DelimSpan { close, .. }, ..) => close, _ => unreachable!(), }, }), ) }; // FIXME: #[doc(hidden)] was previously erroneously allowed on trait impl items, // so for backward compatibility only emit a warning and do not mark it as invalid. self.tcx.struct_span_lint_hir(UNUSED_ATTRIBUTES, hir_id, span, |lint| { lint.build("`#[doc(hidden)]` is ignored on trait impl items") .warn( "this was previously accepted by the compiler but is  being phased out; it will become a hard error in  a future release!", ) .note( "whether the impl item is `doc(hidden)` or not  entirely depends on the corresponding trait item", ) .span_suggestion( replacement_span, "remove this attribute", "", Applicability::MachineApplicable, ) .emit(); }); } } true } </del> /// Checks that an attribute is *not* used at the crate level. Returns `true` if valid. fn check_attr_not_crate_level( &self,

Related discussion:
text: Just wanted to add that this is also affecting , but in a different way: <img width="500" src="https://user-"The isn't there at all without the : <img width="500" src="https://user-"Based on the above, this isn't correct: it actually hides the entire thing, at least for associated constants.
In your case, it's inherent associated items being accidentally flagged which is which was meaning the most recent nightly should not have your issue anymore. Sorry for the inconvenience. The longer I look this lint, the less I like it.
Code change:
&base_segments[base_segments.len()-2], base_segments.last().unwrap()) } <del> Def::Mod(id) => { </del> <ins> Def::Mod(..) => { </ins> // Used as sentinel by callers to indicate the `<T>::A::B::C` form. // FIXME(#22519) This part of the resolution logic should be // avoided entirely for that form, once we stop needed a Def

Related discussion:
text: rustc crashes when compiling the following source code. I expect this to compile or report error. Instead the compiler crashed.
Reduced testcase:
This also causes an ICE with the latest nightly:
Any update on the issue. Please let me know if you need more information. Thanks
Code change:
mod predecessors; mod query; pub mod tcx; <ins> pub mod terminator; pub use terminator::*; </ins> pub mod traversal; mod type_foldable; pub mod visit;

Related discussion:
text: moved the file to over 3k LOC, but I didn't fix it there and instead just annotated the file so tidy ignores it. We should probably split the mir types into separate submodules by the way they are used in MIR. I think we can start by pulling out e.g. terminators and all their sub-types to a submodule <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Will be interested in picking this up
Code change:
.try_resolve_as_non_binding(pat_src, pat, bmode, ident, has_sub) .unwrap_or_else(|| self.fresh_binding(ident, pat.id, pat_src, bindings)); self.r.record_partial_res(pat.id, PartialRes::new(res)); <ins> self.r.record_pat_span(pat.id, pat.span); </ins> } PatKind::TupleStruct(ref path, ref sub_patterns) => { self.smart_resolve_path(

Related discussion:
text: The following code... the following error and warning: The warning says that is not used but it clearly is, just not properly. This error is normally easier to spot when using the proper casing for constants, but that might not always be the case. Perhaps in this instance, we should look for other items with the exact same name and point out that the user is trying to use a constant as a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Every single one of these errors should point at similarly named things of the wrong namespace.
Do you know where in the code this is coming from?
running the following will tell you where the error is being emitted: From there the place you might want to start looking at is , which is a bit hard to follow at the moment (I'm doing a slight clean up of that method at the moment), but should be reasonably straight forward to add another check for this case to that pile :)
claim
Can I take this issue?
Yes feel free to take it, I removed my assignment.
I’m going to be tied up until May, feel free to take this issue:pray:
Hey I'm looking to get to know the Rust codebase better and contribute to the project - would love to take a crack at this issue!
claim
Code change:
<ins> // build-pass // aux-build:issue-97708-aux.rs extern crate issue_97708_aux; use issue_97708_aux::TaskStub; static TASK_STUB: TaskStub = TaskStub::new(); fn main() {} </ins>

Related discussion:
text: <!-- 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. --Github: Repro: Reproduces in: Stable Linux - rustc 1.61.0 ( 2022-05-18) Nightly Linux - rustc 1.63.0-nightly ( 2022-06-02) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I'll see if I can make a smaller repro case
So, the minimal repro case is MUCH smaller: in : In : Which points to these code chunks: This seems to work in the tests for , so it seems like the ICE only triggers when used from an external trait. Additionally, this ICE does NOT trigger in .
CC
Yeah, this seems to occur specifically when trying to compile an external crate that calls this function. Lib tests inside the crate that call the function don't ICE, but adding an integration test (outside of the crate's compilation unit) does trigger the ICE:
If the function is made , the ICE no longer occurs. For example, this commit does not ICE:
prioritize
, if the functions are made but placed in a private module, they get culled again, triggering the ICE:
It also appears that if you move the functions out of the , AND mark them as , the ICE is also abated. See this PR for addressing:
For folks joining now/as a TL;DR, the offending code is basically this: The function produces a value, that gets created in a static: Which gets loaded into a static in user code: It LOOKS like somehow the two original functions (declared inside a private, const fn; inside a private type), are getting culled, which means that when the static (in another compilation unit) goes to be created, the MIR for those functions are missing.
This is likely a disagreement between . Though I don't know much about codegen.
Anyways I think I have a fix, though I am not certain it's the right one. In any case, I at least have a minimized UI test for rustc devs who know codegen better than me. PR incoming.