jiebi/CodeConvo huggingface dataset:
Change:
/// the value returned by `usable_size` for the requested size. #[inline] pub unsafe fn deallocate(ptr: *mut u8, size: uint, align: uint) { <del> // FIXME(14395) This is only required for DST ~[T], it should be removed once // we fix that representation to not use null pointers. if ptr.is_null() { return; } </del> imp::deallocate(ptr, size, align) }

Discussion:
I this to get DST landed. For types I use a fat pointer. If the vector is empy I use null for the pointer, so when this deallocates via drop glue jemalloc segfaults. It should be fairly easy to do a zero sized allocation or something and use that value and then we can remove the null check. That also allows us to use the Option to non-null pointer optimisation. For now I just want to get this branch landed though. cc
FWIW, as the sentinel value for this sort of situation (to ensure that still works, since that uses the "non-null" pointer as the discriminant).
It seems that landed the non-null pointer optimization for slices so this shouldn't be required anymore. Can it be closed?
This ended up landing as part of the initial implementation, but I don't think it is actually accomplishing anything.
Change:
.nth(2) .unwrap_or_else(|| panic!("unexpected output `{}`", recorded)); <del> // update_submodule if actual_hash == checked_out_hash.trim_end() { </del> <ins> if actual_hash == checked_out_hash { </ins> // already checked out return; }

Discussion:
To reproduce, I am in a worktree without (i.e., not the "main" worktree). I have a pre-commit hook set up as follows Now I change something trivial (e.g. remove a trailing in some comments) and commit. That does the following After a second or two I get suspicious and hit Ctrl-C. Now it looks like bootstrap has done something with the (previously clean) cargo submodule So let's and see what's up Eh... so the files are rustc files? Why are those being in ? Something is going seriously wrong here.
I think this only happens with . I attempted to reproduce it about 25 times without success.
Yes indeed, this does not happen in my folder (the main checkout, where lives), but it happens in worktree folders.
Adding some debug logging, it seems like some truly strange things are happening... This is the HEAD commit of the outer repository! I think what's happening is that some environment variables are set inside the git hook which overwrite the . x.py relies on just setting the working directory to determine which git dir to use, but e.g. GITDIR takes precedence over that. I tried setting instead of using and that does seem to help.
Change:
// FIXME(eddyb) producing readable type names for trait objects can result // in problematically distinct types due to HRTB and subtyping (see #47638). // ty::Dynamic(..) | <del> ty::Adt(..) | ty::Closure(..) | ty::Foreign(..) | ty::Generator(..) | ty::Str if !cx.sess().fewer_names() => { </del> <ins> ty::Adt(..) | ty::Closure(..) | ty::Foreign(..) | ty::Generator(..) | ty::Str => { </ins> let mut name = with_no_trimmed_paths(|| layout.ty.to_string()); if let (&ty::Adt(def, _), &Variants::Single { index }) = (layout.ty.kind(), &layout.variants)

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Hello! I'm observing a compilation regression coming from 1.47 to 1.48. Just an with only a dependency segfaults when building it with: System logs: GDB backtrace: Versions and also have this issue. Without these RUSTFLAGS it builds fine, it also builds fine when I build in debug mode. No problems at all when building that project on version 1.47.0. My system info:
This looks like it might be a duplicate of but it's great to have a smaller testcase than rustc itself!
The backtrace looks really similar indeed!
Steps: Result: How to make it not segfault, do any of the below: replace step 4 with don't use use or (preview doesn't work for me in github: so if it looks bad I'll try to edit)
Looks like a side-effect of , which exposed an existing bug in loop vectorize
This
Can confirm that is gone after applying (but without the test case fix which doesn't yet exist in rust 1.48.0 on gentoo)

When bootstrapping rustc, I can observe a crash inside llvm when building . In I could see this: I did a bisect and found out that the crash happens since cc my cpu is a The timing of the crash makes me think that this might happen somewhere during LTOing of the rustcmiddle crate, rustc did not show a backtrace for the crash though, since it happens inside llvm. I already did purge my rustc build cache and the sccache before I saw the segfault happens inside llvm (it didn't help anyway). :sweat_smile: rustc @
cc
Was a coredump generated? If so, should be able to generate a backtrace by running , followed by the command.
does this help?
via
There is no segfault if I build without
Marking this as P-high based on the
What setup are you using to pass ?
I had in my initially. reproduces the segfault as well.
was hitting segfaults with LLD with target-cpu=native, but that was on MSVC:
Hmm, I think i also have my linker set to lld, but I'm on linux...
Still crashes after llvm update in
I got the same SIGSEGV with at stage 0 Can't reproduce it with bootstrap from 1.47 to 1.47
some users hit it in gentoo with 1.48.0 downstream bug removing or helps as described here.
This
I ran into the same problem: OS: Ubuntu20.04 rustc exited with signal: 9 error: could not compile Caused by:
Change:
// FOREIGN STATIC ITEM return Ok(Some(self.parse_item_foreign_static(visibility, lo, attrs)?)); } <del> if self.check_keyword(keywords::Fn) || self.check_keyword(keywords::Unsafe) { </del> <ins> if self.check_keyword(keywords::Fn) { </ins> // FOREIGN FUNCTION ITEM return Ok(Some(self.parse_item_foreign_fn(visibility, lo, attrs)?)); }

Discussion:
This code produces "error: expected one of , , , or , found ":
That code sample probably didn't require linking to a playpen, I've made the description and title more useful.
Change:
<del> //@ known-bug: rust-lang/rust#124552 struct B; struct Foo { b: u32, b: B, } static BAR: Foo = Foo { b: B }; fn main() {} </del>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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. --:
with debug assertions: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
without: --<details<summary<strongBacktrace</strong</summary<p</p</details

<!-- 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) <details<summary<strongOriginal Code</strong</summary<p</p</details<!-- 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- has the same ICE location, but this one doesn't require any feature to make ICE. ICE-loc: Original ICE-triggering code is mutated from test-file
bisects to searched nightlies: from nightly-2024-01-01 to nightly-2024-04-30 regressed nightly: nightly-2024-02-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
The following already reproduces on 1.77 stable
Change:
#include_next <winsock2.h> <ins> // mingw 4.0.x has broken headers (#9246) but mingw-w64 does not. #if defined(__MINGW_MAJOR_VERSION) && __MINGW_MAJOR_VERSION == 4 </ins> typedef struct pollfd { SOCKET fd; short  events;

Discussion:
Latest mingw has broken headers () therefore missing definitions locally. This causes error on mingw-w64 since its header is not broken. :( cc
Quick fix is adding at . mingw-w64 doesn't define them, defines instead. I think we should prepare a plan when mingw also fixes it. (They already fixed third one of on w32api-4.0.3.) However, seems like mingw doesn't increment : both 4.0.0-1 and 4.0.3 have value .
mingw-w64 gets its' own section in , doesn't it? So adding mingw-fix-include to include path in can be conditioned on some macro defined there. As for mingw fixing their headers, I think we can just remove fixed headers from mingw-fix-include when that happens.
I'm building rust on mingw-w64-32bit but rust thinks it is on mingw. I'm not sure this is "legal", but I don't want to cross-build from mingw to mingw-w64-32bit since their difference is small.
has three mingw entries: i686-pc-mingw32 (normal mingw), i586-mingw32msvc (anyone who know this?), and x86_64-w64-mingw32 (mingw-w64 64bit). We don't have i686-w64-mingw32 (mingw-w64 32-bit). I don't know if it is good idea of adding it, so quick fix seems sufficient for now.
Change:
<ins> error[E0284]: type annotations needed: cannot satisfy `the constant `foo::{opaque#0}::{constant#0}` can be evaluated` --> $DIR/parent_generics_of_encoding_impl_trait.rs:9:5 | LL |     generics_of_parent_impl_trait::foo([()]); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot satisfy `the constant `foo::{opaque#0}::{constant#0}` can be evaluated` | ::: $DIR/auxiliary/generics_of_parent_impl_trait.rs:6:48 | LL | pub fn foo<const N: usize>(foo: impl Into<[(); N + 1]>) { |                                                ----- required by this bound in `foo` error: aborting due to previous error For more information about this error, try `rustc --explain E0284`. </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. --I tried simplifying my code, but the code is quite complex and I wasn't able to recreate the ICE. Here is the repo which you can try building to see it for yourself: The main source of the issue is my Tensor structs which look similar to the below code. I have had issues with this . The ICE started happening after I convolution with fft. I to simplify writing the types. Maybe it's related? Sorry for the code mess; I didn't plan to show this code to other people. <!-- 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
Please add A-const-generics, F-constevaluatablechecked, and F-const_generics labels
Maybe related to , but I had this ICE already all the way back in 04/06/2021. Back then the error was
Smaller repro of ICE:
confirming potentially predates 1.56 nightly
Change:
let at = { let start = s.find('%')?; if let '%' = s[start + 1..].chars().next()? { <del> return Some((Substitution::Escape, &s[start + 2..])); </del> <ins> return Some((Substitution::Escape((start, start + 2)), &s[start + 2..])); </ins> } Cur::new_at(s, start)

Discussion:
rustc crashes on the following input, found by :
searched nightlies: from nightly-2021-01-01 to nightly-2021-12-24 regressed nightly: nightly-2021-10-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
The regression happened in . cc
label regression-from-stable-to-stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
I've been taking a look at this. It's pretty interesting. I'm not entirely sure I'll be able to work it out, but I figure I may as well assign myself for the time being while I attempt to solve it.
Another test case:
The problem seems to reside within the crate , in the files and . The function in has a macro, , which is in charge of looking for foreign substitutions - that is, someone using printf or shell style formatting rather than Rust's style. It's a macro so it can be generic over the two types of substitution. The first time this macro is called, for printf substitutions, it finds two (I think "%%" and "%", though I'm not sure it's exactly that). The code that actually detects the substitutions is in . When parsing the substitution, in the function , it is somehow finding that the second substitution has a boundary in the middle of the character. I'm not sure exactly how yet. This gets turned into a span in . The span is malformed, as it splits a character in two, so the second the code tries to use it for anything it trips an assertion and causes this ICE. The remaining problem is figuring out what's going wrong in . This sort of string manipulation is not my forte. I'll probably take another few cracks at it though.
Something is broken about . This change makes the ICE go away (but probably breaks other things):
When returns here: it seems like we should increment by , but we actually only increment it by 2:
yes, I get the exact same error. . The error disappears if you add a new line after the , so maybe your text editor did that automatically.

That was it, thanks. I'm going to unassign myself from this. I do hope my exploration ends up being helpful to whoever fixes it though. if you want to fix this yourself, you certainly seem further along than I was, though you shouldn't feel any pressure to do so if you don't want to.
I put up a PR for a
I opened a new issue for your bug, because it's not exactly the same as this one.
Change:
// abort if the module is already found if result.is_some() { break; } <del> in_module.for_each_child_stable(self.r, |_, ident, _, name_binding| { </del> <ins> in_module.for_each_child(self.r, |_, ident, _, name_binding| { </ins> // abort if the module is already found or if name_binding is private external if result.is_some() || !name_binding.vis.is_visible_locally() { return

Discussion:
The test appears to be intermittently changing its output. Usually, it prints: but sometimes it prints: See for an example of this happening. Here's a log snippet from a compiler build which prints (the current expected output): Note - this indicates that the chosen (which is what actually gets printed) is Output from a compiler which prints : Note - here, the is . There appears to be some non-determinism occuring, but I'm not sure where.
This is blocking - some builders are printing while others are printing , making it impossible to merge.
Change:
fn resolve_imports(&mut self); <del> fn resolve_macro_invocation(&mut self, invoc: &Invocation, invoc_id: ExpnId, force: bool) -> Result<Option<Lrc<SyntaxExtension>>, Indeterminate>; </del> <ins> fn resolve_macro_invocation( &mut self, invoc: &Invocation, eager_expansion_root: ExpnId, force: bool ) -> Result<Option<Lrc<SyntaxExtension>>, Indeterminate>; </ins> fn check_unused_macros(&self);

Discussion:
This code ([playpen]) compiles on stable but not on nightly and beta: [playpen]: Standard Error Edit: Removed macro Originally posted by in
modify labels: A-macros A-resolve C-bug T-compiler
I updated the snippet to remove the module.
This is a regression from (cc Slightly more minimized reproduction will look like this: performs eager expansion on its arguments and hygienic context of produced by such expansion looks like it was produced by the opaque for some reason, so it's resolved at ' definition site. It maybe either some issue with hygiene infra interacting with eager expansion, but it also may be caused by incorrect spans produced by .
(I'm currently looking into the details.) UPD: I have a fix locally, will submit tomorrow.
Fixed in

() Errors: If either the recursion () or the is removed (), this compiles exactly as expected. Additionally, if I explicitly name my crate, it works as expected, but would be vulnerable to crate renames in user code (can't reproduce in playground because it doesn't build a library).
If you try and build Rustup, you get a similar failure, but without recursion or . Seems that just using another macro and is enough in some circumstances
cc for the hygiene macro in
This code () compiles on stable but not on nightly and beta:
Please, file a separate issue for the regression, I'll prioritize it over pre-existing issues (which the original issue seems to be).
Thanks, I filed it in
Fixed in
Thanks for your work on this!
Change:
let path = mi.move_path_index(move_data); debug!("moving out of path {:?}", move_data.move_paths[path]); <del> // don't move out of non-Copy things let lvalue = &move_data.move_paths[path].lvalue; let ty = lvalue.ty(mir, tcx).to_ty(tcx); let gcx = tcx.global_tcx(); let erased_ty = gcx.lift(&tcx.erase_regions(&ty)).unwrap(); if !erased_ty.moves_by_default(gcx, param_env, DUMMY_SP) { continue; } </del> on_all_children_bits(tcx, mir, move_data, path, |mpi| callback(mpi, DropFlagState::Absent))

Discussion:
MIR borrowck considers variables still initialized after their storage ends, so if an immutable variable is defined and used in a loop, this causes an error. e.g.: Which causes:
working on it
Change:
<ins> // compile-pass use std::marker::PhantomData; struct Meta<A> { value: i32, type_: PhantomData<A> } trait MetaTrait { fn get_value(&self) -> i32; } impl<A> MetaTrait for Meta<A> { fn get_value(&self) -> i32 { self.value } } trait Bar { fn get_const(&self) -> &dyn MetaTrait; } struct Foo<A> { _value: A } impl<A: 'static> Foo<A> { const CONST: &'static dyn MetaTrait = &Meta::<Self> { value: 10, type_: PhantomData }; } impl<A: 'static> Bar for Foo<A> { fn get_const(&self) -> &dyn MetaTrait { Self::CONST } } fn main() { let foo = Foo::<i32> { _value: 10 }; let bar: &dyn Bar = &foo; println!("const {}", bar.get_const().get_value()); } </ins>

Discussion:
The below example : I've tried minimizing the example as much as possible and that's the best I can do for now. Version: rustc 1.27.0-nightly ( 2018-05-06)
I have the same error, interesstingly the error seems to have something to do with PhantomData: Edit 1 & 2: Smaller example
After some testing i found out it has nothing to do with the PhantomData, since the following code still gives the same error: edit: further simplification
I think it's related to promoting references to fat pointers in const contexts. In your example you promote a closure to (?). In my example, I promote to .
It seems that the Problem only occurs, when using the associated constant from inside the implementation block:
I found a different example which gives the same error: It only ICEs if I initialize with a . It compiles after replacing the line with Moving the function outside the impl block still ICEs, but with a different error:
Hit this in , in stable(1.28.0), beta(1.29.0-beta.1) and nightly ( 2018-08-03). Here's the commit which exemplifies the issue: (run to trigger). Basically, I cant newtype-wrap a struct with , which requires me to duplicate doc comments :(
Triage: both the original example and the once_cell bug no longer reproduce for me on 1.31.1 (2018 release) and 1.34.1 (stable at the time of writing). The issue should probably be closed. Or do we want to add run-pass test just in case?
Lets add a regression test.
Change:
} else { fcx.type_error_message(expr.span, |actual| { <del> format!("binary operation {} cannot be  applied to type `{}`", ast_util::binop_to_str(op), actual) </del> <ins> format!("binary assignment operation  {}= cannot be applied to type `{}`", ast_util::binop_to_str(op), actual) </ins> }, lhs_t, None); <ins> check_expr(fcx, rhs); </ins> result_t = ty::mk_err(); }

Discussion:
OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:
Change:
<ins> error: expected type, found `1` --> $DIR/diagnostics-parenthesized-type-arguments-issue-120892-3.rs:5:19 | LL |             Foo::(1, 2) => {}, |                ---^ expected type |                | |                while parsing this parenthesized list of type arguments starting here | help: consider removing the `::` here to turn this into a tuple struct pattern | LL -             Foo::(1, 2) => {}, LL +             Foo(1, 2) => {}, | error: aborting due to 1 previous error </ins>

Discussion:
Given an invalid call such as: The following diagnostic is issued: This gets much worse on multiline calls: Which just prints out a diagnostic nowhere near the error: Ideally this should mention something about either missing a missing turbofish (e.g. ), or a missing identifier (e.g. ). This would at least get the error pointing to the correct spot. Latest playground nightly (2024-02-09) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oh, wow, it didn't even occur to me until now that the expression is syntactically valid .< Edit: Wow, even is syntactically well-formed.
This should pretty easy to fix, basically if we fail to parse a type here we should first of all attach a label to the saying something akin to while parsing this list of parenthesized type arguments starting here and we should suggest removing the trailing path separator if the is , the parenthesized generics aren't followed by or and if the list of non-types we encountered can be successfully parsed as a list of expressions (using a snapshot parser). Furthermore, if the is we can try to reparse the list as a list of patterns and provide the same structured suggestion. I will gladly mentor & review any PR for this.
claim
Hello , is this issue still open for mentoring? I can see that already claimed the issue, but there seems to be no progress.
I read the code but no time to finish it at the moment. You can do it.
Change:
// For coroutine-closures, we additionally must compute the // `coroutine_captures_by_ref_ty` type, which is used to generate the by-ref // version of the coroutine-closure's output coroutine. <del> if let UpvarArgs::CoroutineClosure(args) = args { </del> <ins> if let UpvarArgs::CoroutineClosure(args) = args && !args.references_error() { </ins> let closure_env_region: ty::Region<'_> = ty::Region::new_bound( self.tcx, ty::INNERMOST,

Discussion:
<!-- [31mICE[0m: Rustc '--edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'we captured CapturedPlace {'', 'thread 'rustc' panicked at 'we captured CapturedPlace {'' File: --snippet: 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: [typeck] type-checking [analysis] running analysis passes on this crate --
probably also caused by ?
yep ill put up a fix in a few