Skip to content

Register extern struct/union symbols#314

Open
borup3 wants to merge 2 commits intozenc-lang:mainfrom
borup3:register-extern-struct-union
Open

Register extern struct/union symbols#314
borup3 wants to merge 2 commits intozenc-lang:mainfrom
borup3:register-extern-struct-union

Conversation

@borup3
Copy link
Contributor

@borup3 borup3 commented Mar 15, 2026

Description

Please see the 2nd commit. I don't think it's a correct change, but I noticed that extern struct/unions were still emitted into the C output as a typedef which causes double-typedefs for structs defined in a C header. I don't see any unit tests using extern struct/union to verify its behavior so I'm not sure if this is intended or a bug. It makes my use-case below work.

This registers extern struct and extern union as known extern symbols to quench the warning "assuming external C struct". I didn't change the branch for extern fn because they don't seem to have this issue.

#include "c_header_that_defines_dmon_structs.h"

extern struct dmon_watch_id;
extern struct dmon_action;

alias FsCallback = fn(dmon_watch_id, dmon_action, const char*, const char*, const char*, void*);

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation update

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes

Copy link
Member

@Burnett01 Burnett01 left a comment

Choose a reason for hiding this comment

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

If I remember correctly there was a reason behind emitting those warnings when the typechecker got implemented.

If we want to keep the current typechecker behaivour, we should lax the warning with a flag instead.

If we don't want to keep the current typechecker behaivour, your PR is a sufficient fix I think.

This is related to #116

@borup3
Copy link
Contributor Author

borup3 commented Mar 16, 2026

I think there's 2 concerns there.

1 is a warning/error/diagnostic if a symbol is unknown. This PR is not about this.

2 is that an extern symbol shouldn't have to be unknown. It should be possible to define it in Zen C as "This type will exist." and that's what this PR is about.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants