Taking many (500+) references to a value causes compiler stack overflow

[tyler569]

Source

While I recognize this is not what one might call a typical use case, I feel that the compiler should do something more useful than crash in this circumstance.

rustup run stable rustc --version
rustc 1.15.1 (021bd294c 2017-02-08)

rustup run nightly rustc --version
rustc 1.17.0-nightly (b1e31766d 2017-03-03)

rustup run stable cargo build
   Compiling reference_so v0.1.0 (file:///home/tyler/reference_so)
error: Could not compile `reference_so`.

To learn more, run the command again with --verbose.

rustup run nightly cargo build
   Compiling reference_so v0.1.0 (file:///home/tyler/reference_so)

thread 'rustc' has overflowed its stack
fatal runtime error: stack overflow
error: Could not compile `reference_so`.

To learn more, run the command again with --verbose.

Both the number of references and the #![recursion_limit] are minimal for my system.

I believe this may be related to #40119

[est31]

Also related to #40161

[durka]

I feel that when you raise the recursion limit and get a stack overflow, you maybe got what you asked for. (Having done so myself while abusing the macro expander.)

[ghost]

@durka True, but I think the error should be a bit clearer. Something like "recursion limit exceeded, you may expand this limit by increasing the value of [recursion_limit]" or something.

[Mark-Simulacrum]

To my knowledge, there's very little we can do here -- if the user raises the recursion limit, then it's very possible they will see a stack overflow, at which point we cannot print anything (as far as I know, anyway). As such, I'm going to nominate for @rust-lang/compiler to discuss, I think we should close as "not a bug" or at least as a duplicate of other bugs (e.g., #40119 to an extent) which document that the compiler has recursion for types in general.

[nikomatsakis]

triage: P-medium

I agree with @Mark-Simulacrum that there is not much to do here. One remedy that I think makes sense and which may help is adopting the stacker crate, which would allow us to grow the stack transparently, though of course you can still exhaust memory if you want to.

[eddyb]

Stacker issue is #41884.

[nikomatsakis]

Let's close as a dup of #41884 then.

[eddyb]

@nikomatsakis Do we want to do that though? What about #40161?
Or do you think it's not worth tracking individual instances?

[nikomatsakis]

@eddyb do we want to do what though? use stacker?

I do, at least sometimes (sometimes you can rewrite not to recurse in a reasonable way, but sometimes you can't conveniently do so). It's probably still worth tracking individual instances of deep recursion, though, since those are places where we'd have to deploy stacker.

[eddyb]

Close individual issues in favor of a potential general fix.

[nikomatsakis]

Well, it depends if we think this issue is worth addressing in a different way. If we think it's a case where recursion is hard to avoid, I'd prefer to close individual issues, but keep links to them in the general fix.