Regression in usable type complexity: overflow representing the type `...`

[chrysn]

I tried building the iron example of typed-html (version 810fc820, but it's not changing frequently) the code is heavy with (partially recursive) generic types.

With the latest beta (1.43) or stable (1.42), builds succeed; with nightly, they fail with:

$ cargo +nightly build --verbose
[...]
error: overflow representing the type `std::option::Option<&T>`

error: aborting due to previous error

error: could not compile `typed-html`.

Caused by:
  process didn't exit successfully: `rustc --crate-name typed_html --edition=2018 typed-html/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C debuginfo=2 -C metadata=d47a854ad488ad21 -C extra-filename=-d47a854ad488ad21 --out-dir /tmp/typed-html/target/debug/deps -C incremental=/tmp/typed-html/target/debug/incremental -L dependency=/tmp/typed-html/target/debug/deps --extern htmlescape=/tmp/typed-html/target/debug/deps/libhtmlescape-93c9e1d0e3ad1b35.rmeta --extern language_tags=/tmp/typed-html/target/debug/deps/liblanguage_tags-25ca56886cd3e2ae.rmeta --extern mime=/tmp/typed-html/target/debug/deps/libmime-c67f239ef9444378.rmeta --extern proc_macro_hack=/tmp/typed-html/target/debug/deps/libproc_macro_hack-6271c07fb42254ec.so --extern proc_macro_nested=/tmp/typed-html/target/debug/deps/libproc_macro_nested-a84f2a4ba9005aa7.rmeta --extern strum=/tmp/typed-html/target/debug/deps/libstrum-13ea7f88aaf14180.rmeta --extern strum_macros=/tmp/typed-html/target/debug/deps/libstrum_macros-5e348577b435118e.so --extern typed_html_macros=/tmp/typed-html/target/debug/deps/libtyped_html_macros-3ce45005b6c7b859.so` (exit code: 1)

The iron example is comparatively simple typed-html usage. I've originally observed the same kind of regression in a game that uses typed-html.

Meta

This might be an occurrence of #32498; the behavior changing from stable/beta to nightly indicates a new issue and is thus reported anew.

rustc +nightly --version --verbose:

rustc 1.44.0-nightly (dbf8b6bf1 2020-04-19)
binary: rustc
commit-hash: dbf8b6bf116c7bece2987ff4bd2792f008a6ee77
commit-date: 2020-04-19
host: x86_64-unknown-linux-gnu
release: 1.44.0-nightly
LLVM version: 9.0

(Running with RUST_BACKTRACE does not change the output.)

Bisection results

I'm running cargo bisect-rustc on the code, which has narrowed it down to a regression in nightly-2020-04-10. I'll update this with a more detailled bisection result when it's ready, but that might be a while.

[chrysn]

Here's what cargo bisect-rustc says about it:

Regression found in the compiler

searched nightlies: from nightly-2020-04-05 to nightly-2020-04-12
regressed nightly: nightly-2020-04-10
searched commits: from 485c5fb to 94d3463
regressed commit: 93dc97a

[jonas-schievink]

Maybe #70896?

[chrysn]

I've built cargo with current master (2dc5b60) with the commits ce8abc6, 2c4cffd, 8aac107 and 859b8da reverted.

(Workflow, just to ensure I don't get things wrong methodically as this is the first time I build rust: Clone rust recursively, ./x.py build, test, revet the commits, ./x.py build, test again. The test step happens in a checkout of the failing code with PATH=.../build/${triple}/stage2/bin/:.../build/${triple}/stage0/bin/:$PATH, where the stage0 path gives me a cargo; tests get a cargo clear in-between due to changed std library and compiler).

While on master the error is present, and vanishes with the reverts.

[edit: For context, this confirms Jonas' assumption that #70896 caused the regression]

[spastorino]

Assigning P-medium as discussed as part of the Prioritization Working Group process, removing I-prioritize and also nominating for discussion on our next weekly meeting.

[spastorino]

cc @cuviper

[chrysn]

Reading up on the archived convesation, I've tried with an increased recursion limit. Setting the recursion limit inside the typed_html crate up did the trick; I'll bisect around a bit there to see how much the limit demands have raised.

If this is deemed acceptable breakage, it might be helpful to have an error message in the overflow message that says which crate is being compiled, and that the recursion limit should be incremented there.