Skip to content
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

Sema: Fixing segfaults on mutually recursive structs #19995

Closed
wants to merge 2 commits into from

Conversation

antoniospg
Copy link
Contributor

Trying to fix both #19920 and #18556
Not sure those are the best approaches.

4d580af Solves the following issue:

const A = struct {
    a: A,
};

pub fn main() !void {
    const a: A = undefined;
    _ = a;
}

On addDbgVar, it keeps caling hasRuntimeBitsAdvanced infinitely on the struct type.
I've tried to add resolveTypeFully to get the compiler error first.

7170203 Solves the following issue:

const A = struct {
    unused: void,
    bad_field: [@sizeOf(A)]u8 align(@alignOf(A)),
};

pub fn main() !void {
    const a: A = undefined;
    _ = a;
}

In this example, only the first field of the struct is non-null when calling haveFieldTypes which causes it to return true when it shouldn't.

@mlugg
Copy link
Member

mlugg commented May 18, 2024

4d580af Solves the following issue:

This fix is not appropriate. We need to avoid infinite recursion on Type.hasRuntimeBitsAdvanced in the general case; for instance, I suspect your fix would fail if used in an -fstrip build. Fixing this correctly will probably involve some critical analysis of the whole "assumed runtime bits" system for structs, since it's a bit silly.

7170203 Solves the following issue:

This fix is also inappropriate, since it needlessly turns an O(1) operation into an O(N) operation. I recall fixing a bug similar to this one recently, actually... the easiest solution is probably to reset the first field type to .none if type resolution of any field fails.

Also, note that bugfixes such as these should add corresponding behavior tests whenever possible.

@mlugg mlugg closed this May 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants