Change:
Hi, i have made some changes for a crate to support a generic type that implements from , but suddenly the code can't compile because it runs out of memory with 6, 8, 10 GB. This is the code i'm trying to compile: if changed the type for or it then compiles and runs fine. Source: It fails to compile on x86_64-unknown-linux-gnu with , . I'm attaching the Heaptrack files for further analysis.
It seems a problem with utilized in the , unfortunately memory report is strange, the execution time tracked is wrong besides the graph shows up the memory grow. I'm thinking ways to better troubleshoot, but the side effects of the issue is hard.
It'd be helpful to try and simplify the code, ideally to something that doesn't have dependencies (beyond std or so), or at least as few dependencies as possible. As a start putting up a github repository with a and as simple a crate as possible would be helpful for reproducing on our side (i.e., extracting the file you've linked from that crate -- or, if the crate is really necessary, then indicating as such). The heaptrack profile looks pretty useless unfortunately -- rustc on linux is shipped with jemalloc as the allocator which likely makes heaptrack tracking not really work too well.
Thank you, sorry for the late response (working) but i get it working on playground. I'm now trying to minimize them to focus on the issue.
Got it down to 18 lines. Still produces the same error. I have not tested if this goes out-of-memory. But receiving a would signal that. EDIT: After taking some more time, I got rid of Tokio and reduced it to 6 lines: Additionally, I advise to rename this issue to something like to make it very clear and concise.
One liner: . Strangely, this no longer crashes if you remove any of , , , or . There's nothing special about Send or Sync, this also crashes: Even weirder, this does not crash: (I didn't come up with the one-liner, that was
I stopped rustc (SIGSTOP) and got a backtrace with gdb, it looks like it's trying to generate infinite errors: <details<summarybacktrace</summary</details
It looks like this is a problem with the error reporter itself: it's affected by the length of the name (!!) OOM: No OOM:
I figured out the issue has to do with how the error printer places the annotations, adding a newline after the trait names and before the plus solves the issue.
Probably caused by some code in here:

Discussion:
// This offset and the ones below need to be signed to account for replacement code // that is shorter than the original code. <del> let mut offset: isize = 0; </del> <ins> let mut offsets: Vec<(usize, isize)> = Vec::new(); </ins> // Only show an underline in the suggestions if the suggestion is not the // entirety of the code being shown and the displayed code is not multiline. if show_underline {

.map(|ch| unicode_width::UnicodeWidthChar::width(ch).unwrap_or(1)) .sum(); <ins> let offset: isize = offsets .iter() .filter_map( |(start, v)| if span_start_pos <= *start { None } else { Some(v) }, ) .sum(); </ins> let underline_start = (span_start_pos + start) as isize + offset; let underline_end = (span_start_pos + start + sub_len) as isize + offset; <ins> assert!(underline_start >= 0 && underline_end >= 0); </ins> for p in underline_start..underline_end { buffer.putc( row_num, <del> max_line_num_len + 3 + p as usize, </del> <ins> ((max_line_num_len + 3) as isize + p) as usize, </ins> '^', Style::UnderlinePrimary, );

for p in underline_start - 1..underline_start + 1 { buffer.putc( row_num, <del> max_line_num_len + 3 + p as usize, </del> <ins> ((max_line_num_len + 3) as isize + p) as usize, </ins> '-', Style::UnderlineSecondary, );

// length of the code to be substituted let snippet_len = span_end_pos as isize - span_start_pos as isize; // For multiple substitutions, use the position *after* the previous <del> // substitutions have happened. offset += full_sub_len - snippet_len; </del> <ins> // substitutions have happened, only when further substitutions are // located strictly after. offsets.push((span_end_pos, full_sub_len - snippet_len)); </ins> } row_num += 1; }

<ins> // Regression test for issue #67690 // Rustc endless loop out-of-memory and consequent SIGKILL in generic new type // check-pass pub type T<P: Send + Send + Send> = P; //~^ WARN bounds on generic parameters are not enforced in type aliases fn main() {} </ins>

<ins> warning: bounds on generic parameters are not enforced in type aliases --> $DIR/issue-67690-type-alias-bound-diagnostic-crash.rs:5:15 | LL | pub type T<P: Send + Send + Send> = P; |               ^^^^   ^^^^   ^^^^ | = note: `#[warn(type_alias_bounds)]` on by default help: the bound will not be checked when the type alias is used, and should be removed | LL | pub type T<P> = P; |            -- </ins>

// Test `ignored_generic_bounds` lint warning about bounds in type aliases. <del> // build-pass (FIXME(62277): could be check-pass?) </del> <ins> // check-pass </ins> #![allow(dead_code)] use std::rc::Rc;

help: the bound will not be checked when the type alias is used, and should be removed | LL | type SVec<T> = Vec<T>; <del> |     --    -- </del> <ins> |           -- </ins> warning: where clauses are not enforced in type aliases --> $DIR/type-alias-bounds.rs:10:21

help: the bound will not be checked when the type alias is used, and should be removed | LL | type VVec<'b, 'a> = (&'b u32, Vec<&'a i32>); <del> |            --  -- </del> <ins> |                -- </ins> warning: bounds on generic parameters are not enforced in type aliases --> $DIR/type-alias-bounds.rs:14:18

help: the bound will not be checked when the type alias is used, and should be removed | LL | type WVec<'b, T> = (&'b u32, Vec<T>); <del> |           --  -- </del> <ins> |               -- </ins> warning: where clauses are not enforced in type aliases --> $DIR/type-alias-bounds.rs:16:25