rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
96.9k stars 12.52k forks source link

Exponential parse time involving `maybe_suggest_struct_literal` #105067

Open jruderman opened 1 year ago

jruderman commented 1 year ago

Code

fn main() {
    0 & {
    x: y & {
    x: y & {
    x: y & {
    x: y & {
    x: y & {
    x: y & {
    x: y & {
    x: y & {
    x: y & {
    x: y & {
    x: y & {
    x: y & {
    x: y & {
    x: y & {
    x: y & {
    x: y & {
    x: y & {
    x: y & {
    x: y & {
    x: y & {
    x: y & {

Where it's slow

According to -Z time-passes, the slow pass is parse_crate.

sample-head.txt

maybe_suggest_struct_literal repeatedly on the stack is sus.

Regression

Regression in nightly-2020-10-09, most likely from #75470, which added the function maybe_suggest_struct_literal (@estebank)

Version

rustc 1.67.0-nightly (1eb62b123 2022-11-27)
binary: rustc
commit-hash: 1eb62b1235fd77200e6bd967d70e83c0f2497233
commit-date: 2022-11-27
host: x86_64-apple-darwin
release: 1.67.0-nightly
LLVM version: 15.0.4

@rustbot label +I-compiletime

estebank commented 1 year ago

We could add a flat to ensure that we don't recurse into that function given that this is meant only for error recovery and beyond a certain point all bets are off so it's better to bail early if we recognize that we don't know what we're dealing with. Ho was this found? Through fuzzing?

Also, now that I think about the approach can be changed entirely now that type ascription is no longer accepted syntax.

jruderman commented 1 year ago

Yes, this was found through fuzzing. I'm using a fork of fuzz-rustc where I've added a custom mutator.