docs(design):anony fntype as field mapped named fntype and refer #449
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #449 +/- ##
=======================================
Coverage 84.38% 84.38%
=======================================
Files 27 27
Lines 2728 2728
=======================================
Hits 2302 2302
Misses 385 385
Partials 41 41 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
luoliwoshang
force-pushed
the
doc/en/fnptr
branch
3 times, most recently
from
6855c85 to
ff94ed7
Compare
luoliwoshang
force-pushed
the
doc/en/fnptr
branch
from
ff94ed7 to
5edc2b9
Compare
doc/en/dev/llcppg.md
Outdated
| LLGo cannot use anonymous function types directly as field types. To preserve type information, llcppg automatically generates named function types and references them in the field and following this naming convention: | ||
| ``` | ||
| LLGO_<namespaces>_<typename>_<nested_field_typename>_<fieldname> | ||
| ``` |
There was a problem hiding this comment.
Based on our discussion in the meeting: In C, an anonymous function's type is not accessible from the outside. To follow this same rule in Go, we'll make the auto-generated type unexported, which still allows the field to be assigned correctly.
luoliwoshang
force-pushed
the
doc/en/fnptr
branch
from
24e8d8a to
545cb07
Compare
| To work around LLGo's inability to use anonymous function types directly in struct fields, llcppg automatically generates a corresponding named function type. This generated type is intentionally made unexported (private) to mirror C/C++ semantics, where anonymous function types are not externally accessible. Crucially, even though the type itself is private, this does not affect the ability to assign a compatible function to the field during normal use in Go. All such function types follow the specific naming convention: | ||
|
|
||
| ``` | ||
| llgo_<namespaces>_<typename>_<nested_field_typename>_<fieldname> |
There was a problem hiding this comment.
Although the design llgo_<namespaces>_<typename>_<nested_field_typename>_<fieldname> improves code readability to some extent, it compromises the original data structure. This is because the original code features a function pointer within a nested struct.
There was a problem hiding this comment.
in llgo, when you refer a func type which is comment with llgo:type C,it is actual a pointer in data structure
2 participants
design for #448
To work around LLGo's inability to use anonymous function types directly in struct fields, llcppg automatically generates a corresponding named function type. This generated type is intentionally made unexported (private) to mirror C/C++ semantics, where anonymous function types are not externally accessible. Crucially, even though the type itself is private, this does not affect the ability to assign a compatible function to the field during normal use in Go. All such function types follow the specific naming convention: