Repository navigation
Exponential parse time involving maybe_suggest_struct_literal #105067
Description
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.
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
Activity
estebank commentedon Nov 29, 2022
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 commentedon Nov 30, 2022
Yes, this was found through fuzzing. I'm using a fork of fuzz-rustc where I've added a custom mutator.