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

Type: improve type equality checking #528

Merged
merged 3 commits into from
Oct 24, 2023
Merged

Type: improve type equality checking #528

merged 3 commits into from
Oct 24, 2023

Conversation

ehaas
Copy link
Collaborator

@ehaas ehaas commented Oct 24, 2023

I tried to figure these out by reading the standard but it's pretty dry.

Functions in C11 6.7.6.3.15 (too long to paste)

Arrays in C11 6.7.6.2.6: "For two array types to be compatible, both shall have compatible element types, and if both size specifiers are present, and are integer constant expressions, then both size specifiers shall have the same constant value"

Briefly,

  1. Arrays with same child type are compatible if at least one array is incomplete or if they have the same constant integer length
  2. Functions must both have or both not have ellipses to be compatible
  3. A function with no prototype is compatible with a function with a parameter list if none of the named parameter types undergo default argument promotion and the return type is compatible

1) Arrays with same child type are compatible if at least one array is incomplete
2) Functions must both have or both not have ellipses to be compatible
3) A function with no prototype is compatible with a function with a parameter
   list if none of the named parameter types undergo default argument promotion
   and the return type is compatible
Copy link
Owner

@Vexu Vexu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like it resolves my TODO adjusted equality check comments in SymbolStack.zig.

@@ -9,5 +9,4 @@ int arr[3]; // TODO should make the error go away
#define EXPECTED_ERRORS \
"tentative array.c:1:5: warning: tentative array definition assumed to have one element" \
"tentative array.c:3:16: error: invalid application of 'sizeof' to an incomplete type 'int []'" \
"tentative array.c:5:5: error: redefinition of 'arr' with a different type" \
"tentative array.c:1:5: note: previous definition is here" \

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should also remove the TODO and SKIPPED_TESTS.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this one the warning: tentative array definition assumed to have one element should not happen since the definition is later completed. I think we'd have to do something similar to what we do for tentative_defs in the Parser since we don't want to issue the warning until we're done and have determined the definition is incomplete.

@Vexu Vexu merged commit d8c26ad into Vexu:master Oct 24, 2023
3 checks passed
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.

2 participants