Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Compilation Exhausts Memory Instead of Detecting Potential Syntax Error #117080

Closed
iamanonymouscs opened this issue Oct 23, 2023 · 1 comment · Fixed by #117143
Closed

Compilation Exhausts Memory Instead of Detecting Potential Syntax Error #117080

iamanonymouscs opened this issue Oct 23, 2023 · 1 comment · Fixed by #117143
Labels
A-parser Area: The parsing of Rust source code to an AST C-bug Category: This is a bug. I-compilemem Issue: Problems and improvements with respect to memory usage during compilation. I-hang Issue: The compiler never terminates, due to infinite loops, deadlock, livelock, etc. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@iamanonymouscs
Copy link

I tried this code():

trait Mul<T> {
    type Output;
}
trait Matrix: Mul<<Self as Matrix>::Row, Output = ()> {
    type Row;
    type Transpose: Matrix<Row = Self::Row>;
}
fn is_mul<S, T: Mul<S, Output = ()>>() {}
fn f<T: Matrix>() {
    is_mul::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<f::<>();
}

I expected to see this happen: the compiler to recognize a potential syntax error and provide an error report.

Instead, this happened: the compiler consumes all available memory and exits.

This code contains obvious syntax errors, so it doesn't seem reasonable for it to be compiled for a long time.

Meta

rustc --version --verbose:

commit-hash: 1c05d50c8403c56d9a8b6fb871f15aaa26fb5d07
commit-date: 2023-10-21
host: x86_64-unknown-linux-gnu
release: 1.75.0-nightly
LLVM version: 17.0.3

The same problem is reproduced on the stable version(1.73 cc66ad4 2023-10-03)

Backtrace 

<backtrace>

@iamanonymouscs iamanonymouscs added the C-bug Category: This is a bug. label Oct 23, 2023
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Oct 23, 2023
@Noratrieb Noratrieb added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. I-compilemem Issue: Problems and improvements with respect to memory usage during compilation. I-hang Issue: The compiler never terminates, due to infinite loops, deadlock, livelock, etc. A-parser Area: The parsing of Rust source code to an AST and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Oct 23, 2023
@estebank
Copy link
Contributor

The problem is introduced by parse_angle_args_with_leading_angle_bracket_recovery. We need to take a look to add a further check to avoid falling into this pathological case.

estebank added a commit to estebank/rust that referenced this issue Oct 24, 2023
@estebank
Avoid unbounded O(n^2) when parsing nested type args
54dffa1 
When encountering code like `f::<f::<f::<f::<f::<f::<f::<f::<...` with
unmatched closing angle brackets, add a linear check that avoids the
exponential behavior of the parse recovery mechanism.

Fix rust-lang#117080.
@estebank estebank mentioned this issue Oct 24, 2023
Merged
bors added a commit to rust-lang-ci/rust that referenced this issue Oct 24, 2023
@bors
Auto merge of rust-lang#117143 - estebank:issue-117080, r=<try>
bbebabf 
Avoid unbounded O(n^2) when parsing nested type args

When encountering code like `f::<f::<f::<f::<f::<f::<f::<f::<...` with unmatched closing angle brackets, add a linear check that avoids the exponential behavior of the parse recovery mechanism.

Fix rust-lang#117080.
estebank added a commit to estebank/rust that referenced this issue Oct 24, 2023
@estebank
Avoid unbounded O(n^2) when parsing nested type args
7bce646 
When encountering code like `f::<f::<f::<f::<f::<f::<f::<f::<...` with
unmatched closing angle brackets, add a linear check that avoids the
exponential behavior of the parse recovery mechanism.

Fix rust-lang#117080.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Oct 26, 2023
@matthiaskrgr
Rollup merge of rust-lang#117143 - estebank:issue-117080, r=wesleywiser
7eb0548 
Avoid unbounded O(n^2) when parsing nested type args

When encountering code like `f::<f::<f::<f::<f::<f::<f::<f::<...` with unmatched closing angle brackets, add a linear check that avoids the exponential behavior of the parse recovery mechanism.

Fix rust-lang#117080, fix rust-lang#115414.
@bors bors closed this as completed in 2dec1bc Oct 26, 2023
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Oct 26, 2023
@rust-timer
Unrolled build for rust-lang#117143
eb98ead 
Rollup merge of rust-lang#117143 - estebank:issue-117080, r=wesleywiser

Avoid unbounded O(n^2) when parsing nested type args

When encountering code like `f::<f::<f::<f::<f::<f::<f::<f::<...` with unmatched closing angle brackets, add a linear check that avoids the exponential behavior of the parse recovery mechanism.

Fix rust-lang#117080, fix rust-lang#115414.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-parser Area: The parsing of Rust source code to an AST C-bug Category: This is a bug. I-compilemem Issue: Problems and improvements with respect to memory usage during compilation. I-hang Issue: The compiler never terminates, due to infinite loops, deadlock, livelock, etc. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Avoid unbounded O(n^2) when parsing nested type args estebank/rust
4 participants
@estebank @iamanonymouscs @rustbot @Noratrieb