-
Notifications
You must be signed in to change notification settings - Fork 263
Description
Version
No response
Summary
When "-opt" is used, the "consume" projection no longer generates static method definitions in the "consume" headers - the whole point of "-opt" being to avoid the callouts to the activation factory. It depends on the component's .g.cpp file to have an inline definition that refers directly to the implementation type.
When a type has FeatureAttribute set to AlwaysDisabled the component writers do some filtering out of types and methods. (Search the cppwinrt code for is_always_disabled). This is fine, as it prevents these types and methods from being activatable via winrt_get_activation_factory.
Unfortunately, this filtering is also removing these "-opt"imized static method definitions from the component's .g.cpp file. This means that calls to these static methods will result in a linker error:
- The consume header no longer has a method definition thanks to "-opt"
- The AlwaysDisabled stuff removes the definition from the .g.cpp that should have replaced the non-"-opt" definition.
See this workaround that was put into WinAppSDK: microsoft/WindowsAppSDK#5108
I believe this happens to all factory interfaces, meaning constructors with parameters are also affected. Interestingly, parameterless constructors are not affected, because they aren't implemented on a factory interface with Feature(AlwaysDisabled).
Instead, we should stay consistent. There shouldn't be any prohibitions on in-component code calling AlwaysDisabled stuff. This should be a simple fix - adding the regression test coverage will probably be more work than the actual fix.
Reproducible example
Expected behavior
No response
Actual behavior
No response
Additional comments
No response