You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are cases where you would want these things for one specific declaration:
skip name mangling. Reason: only the root module declarations are not mangled, what if you want to access some other declaration?
keep a declaration even if it is not used. Reason: incremental compilation, glueing code together after linking, function-scope const-asserts...
this could be configured in the linker, but new attributes could also achieve this, example:
@no_strip
fnplease_keep_this(){// this declaration and its dependencies will be kept in the final WGSL, even if not used by entrypoints.// ...}
@no_mangle
fnsome_declaration(){// this declaration will not be mangled, even if it is not in the root module.// ...}fnsome_function(){
@no_mangle
subgroupExclusiveMul(x);// subgroupExclusiveMul is a new WGSL builtin function that may not be known by the linker yet...}
Partially linking something at build time and completing the link at runtime sounds pretty interesting. What are the user scenarios? I'm trying to understand how persistent the partially linked code is, what's supplied at runtime vs. build time, how this relates to potentially pre-parsing to an AST, etc.
for skipping name mangling for the host interface, could #65 be our solution? (i.e. host visible names need to be in the unmangled root module one way or another)
mangling: @publish is a preferable solution yes! no action at a distance, no risks of collision, one-fits-all solution..
stripping: well my initial thought was that sometimes you want to compile down code that doesn't have entrypoints, if for example it depends on a big stdlib and you want to bundle it down to one file. Just mark the functions you want to keep with @no_strip (@keep might be a better name).
Other use-case, you want to keep dead code to make sure it is valid with naga/tint.
just adding that those attributes are not really a priority nor a necessity (can be achieved by configuring linker), just sharing ideas.
There are cases where you would want these things for one specific declaration:
Reason: only the root module declarations are not mangled, what if you want to access some other declaration?
Reason: incremental compilation, glueing code together after linking, function-scope const-asserts...
this could be configured in the linker, but new attributes could also achieve this, example:
related: #45
The text was updated successfully, but these errors were encountered: