Warn when lacking custom drop implementation for stack overflowing structures

Disclaimer

Maybe this is tricky to implement, or maybe it's already been posted somewhere, but the only resource I've found on this is (ironically) a stack overflow post. Or maybe it's just not as important as I think it is.

edit : I'm aware that this problem is pretty obvious, so it probably comes from older choices, but in the context of Rust safeness, I find it particularly dangerous.

Motivation

Rust being a language known to be "safe" (and it is), I find it quite unfortunate that an auto-implemented function can potentially lead to a stack overflow without even warning the user. I mean, if I were the CISO of a company, I would definitely ban the use of recursive structures. But if a team working on critical areas doesn't know this, it could potentially lead to unpredictable crashes with the consequences that would include.

Idea

Since Rust automatically handles deallocation of structures, I think it would be nice to warn users when deallocation can potentially lead to a stack overflow. This means warning the user when a custom deallocation function is not implemented for what we consider a potentially recursive or stack overflowing structure.

How to know

A simple solution might be to warn the user when a structure contains one or more boxes and does not have a custom deallocation function.

I felt like this should always be an Option, but it could also be a Box or a Box<Box<.... Box....>>.

So a more complex, but also more specific, solution might be to find cycle referencing types, with cycle detection in a graph.
For nested structures, we could say that it is impossible to make many nested boxes and therefore not handle the case.

We could also change the algorithm behind deallocation and use a recursive tree search algorithm, but the trade-off would be really terrible, and even more so with the drop function which is probably one of the most called functions, so impossible.

I don't have many ideas left, but I think the first one is probably the easiest and most convenient to use, the only problem being the false positive rate...

One way to solve this problem could be to take the problem the other way around. We could make sure that there would be no stack overflow if the number of nested boxes was less than a threshold and there was no cyclic reference between multiple types.

Conclusion

I agree that this is a complex problem, since we don't want too many false positives. But I really think the idea that an auto-implemented function is not robust to overflow is a bad concept.

Start by reading the linked Stack Overflow discussion and the issue's proposed approaches for Rust drop behavior. Determine whether warning criteria can be specified without unacceptable false positives, then document one agreed design and its expected behavior in an RFC.