-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recursive type alias segfaults #1867
Comments
I believe we should actually reject both cases, and more generally such self-recursive types.
|
With the reference (exactly the provided example) also seems to segfault FWIW, C++17 (I think) does allow incomplete types in vectors:
but that may be hard to replicate, I don't know |
Darn. :-) Now we definitely have a bug.
Interesting, I never realized that C++17 added that. But yeah, I don't immediately see how we'd use that, seems the standard supports only vectors and lists for this. However, if there was a way to make this work for our containers and structs, then that could have quite an impact on our generated code because many instances of our |
I think @timwoj reported some issues around incomplete types in Spicy when he tried to bump Zeek to C++20, I wonder (but didn't check) whether that was due to how we emit defaulted functions, see e.g., https://www.lukas-barth.net/blog/cpp20-vector-incomplete/#sec-speculation. |
This is part of #1867 - there is a fair bit more work to do, but this recursion limit gives a simple way to prevent overflows without a pretty unecessary cycle detector. Types within containers (like vectors) or references will continue to segfault - that happens at type unification. Then, in order to allow references, more will be necessary.
This is part of #1867 - there is a fair bit more work to do, but this recursion limit gives a simple way to prevent overflows without a pretty unecessary cycle detector. Types within containers (like vectors) or references will continue to segfault - that happens at type unification. Then, in order to allow references, more will be necessary.
Closes #1867 There are two different cases where infinite loops happen with recursive types. First, a type may reference itself (`type Data = Data`). Second, a type may reference itself inside some other type (`type Data = vector<Data>`). The first is fixed with a recursion limit. Since the type simply cannot resolve, it doesn't get anywhere near codegen. You could detect cycles, but that introduces some extra overhead and complexity that shouldn't be needed in a "simple" function. The second is fixed with an ad-hoc "occurs" check in type unification. That just detects cycles and aborts if one is present. This could be placed at some other place in the "resolve until convergence" loop, but it seems best put closest to the source of the issue.
Closes #1867 There are two different cases where infinite loops happen with recursive types. First, a type may reference itself (`type Data = Data`). Second, a type may reference itself inside some other type (`type Data = vector<Data>`). The first is fixed with a recursion limit. Since the type simply cannot resolve, it doesn't get anywhere near codegen. You could detect cycles, but that introduces some extra overhead and complexity that shouldn't be needed in a "simple" function. The second is fixed with an ad-hoc "occurs" check in type unification. That just detects cycles and aborts if one is present. This could be placed at some other place in the "resolve until convergence" loop, but it seems best put closest to the source of the issue.
Closes #1867 There are two different cases where infinite loops happen with recursive types. First, a type may reference itself (`type Data = Data`). Second, a type may reference itself inside some other type (`type Data = vector<Data>`). The first is fixed with a recursion limit. Since the type simply cannot resolve, it doesn't get anywhere near codegen. You could detect cycles, but that introduces some extra overhead and complexity that shouldn't be needed in a "simple" function. The second is fixed with an ad-hoc "occurs" check in type unification. That just detects cycles and aborts if one is present. This could be placed at some other place in the "resolve until convergence" loop, but it seems best put closest to the source of the issue.
The following code segfaults during compilation via
spicyc
:Like:
Offending line just loops infinitely trying to resolve (unsurprisingly)
I think there's merit in having this be possible, but it can also be a difficult problem sometimes, so just not segfaulting would work too.
EDIT: To be clear, that minimal case above doesn't seem useful, but this kind of type may be:
The text was updated successfully, but these errors were encountered: