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

winrt::impl::slim_source_location::current default arguments has an ODR violation when mixing cpp language standards #1445

Closed
dmachaj opened this issue Nov 4, 2024 · 1 comment

Comments

@dmachaj
Copy link
Contributor

dmachaj commented Nov 4, 2024

Version

(not yet released at this time)

Summary

I am filing this as a follow-up issue after #1444 is merged. That PR is eliminating a serious ODR issue and is replacing it with a minor ODR issue. There is no longer ABI incompatibility based on language standard or defining WINRT_NO_SOURCE_LOCATION. However, there is a minor new ODR incompatibility when it comes to the default arguments to the current() method.

The value of the default arguments are separate from the type of the method itself, so this misbehavior is minor at worst. When all translation units agree then there is no ODR and everything is great. When mixing different versions (e.g. cpp17 and cpp20 static libraries) the behavior becomes undefined. If a given method is only used by one library or the other then the source location value for that library will be in effect. If a method is used by both libraries then the linker will choose which version is linked (with or without source location).

tl;dr - If you use cppwinrt in both cpp17 and cpp20 code and link them together then sometimes source location will be missing, and sometimes it will be present. Your mileage may vary.

Reproducible example

No response

Expected behavior

No response

Actual behavior

No response

Additional comments

No response

@dmachaj
Copy link
Contributor Author

dmachaj commented Nov 4, 2024

Immediately closing this issue because there are no known changes at this time that can address it. If that changes in the future then we'll have this issue to reference against.

@dmachaj dmachaj closed this as completed Nov 4, 2024
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

No branches or pull requests

1 participant