fa079fb34b
Why is this change being made? Someone discovered a subtle compatibility issue with the cast result checking changes and certain projected methods. The variables in the consume_ method, such as the generically-named code variable, can shadow the parameters to the function. This led to a build break where a function took an int16_t named code and that was shadowed by the int32_t named code with the HRESULT in it. Fortunately the compiler had our back and flagged the size truncation as a build break so it was noticed. Briefly summarize what changed The variable names in these generated functions are now much uglier (and therefore less likely to collide by coincidence). They have an underscore prefix and then lowercase which should put them into an unofficial namespace that shouldn't collide with anything else. The code variable is now named _winrt_cast_result_code for example. While I was renaming everything I realized that my previous names mismatched the cppwinrt naming convention of snake_case so I fixed them up. |
||
|---|---|---|
| .config/1espt | ||
| .github | ||
| .pipelines | ||
| cppwinrt | ||
| docs | ||
| fast_fwd | ||
| mingw-support | ||
| natvis | ||
| nuget | ||
| prebuild | ||
| scratch | ||
| strings | ||
| test | ||
| vsix | ||
| .gitattributes | ||
| .gitignore | ||
| CMakeLists.txt | ||
| Directory.Build.Props | ||
| Directory.Build.Targets | ||
| LICENSE | ||
| README.md | ||
| build_nuget.cmd | ||
| build_prior_projection.cmd | ||
| build_projection.cmd | ||
| build_test_all.cmd | ||
| build_vsix.cmd | ||
| compile_tests.cmd | ||
| cppwinrt.sln | ||
| cross-mingw-toolchain.cmake | ||
| nuget.config | ||
| prepare_versionless_diffs.cmd | ||
| run_tests.cmd | ||
README.md
The C++/WinRT language projection
C++/WinRT is an entirely standard C++ language projection for Windows Runtime (WinRT) APIs, implemented as a header-file-based library, and designed to provide you with first-class access to the modern Windows API. With C++/WinRT, you can author and consume Windows Runtime APIs using any standards-compliant C++17 compiler.
- Documentation: https://aka.ms/cppwinrt
- NuGet package: http://aka.ms/cppwinrt/nuget
- Visual Studio extension: http://aka.ms/cppwinrt/vsix
- Wikipedia: https://en.wikipedia.org/wiki/C++/WinRT
Building C++/WinRT
Don't build C++/WinRT yourself - just download the latest version here: https://aka.ms/cppwinrt/nuget
Working on the compiler
If you really want to build it yourself, the simplest way to do so is to run the build_test_all.cmd script in the root directory. Developers needing to work on the C++/WinRT compiler itself should go through the following steps to arrive at an efficient inner loop:
- Open a dev command prompt pointing at the root of the repo.
- Open the
cppwinrt.slnsolution. - Choose a configuration (x64, x86, Release, Debug) and build projects as needed.
If you are working on an ARM64 specific issue from an x64 or x86 host, you will need to instead:
- Open the
cppwinrt.slnsolution - Build the x86 version of the "cppwinrt" project first
- Switch to your preferred configuration and build the test binaries and run them in your test environment
Comparing Outputs
Comparing the output of the prior release and your current changes will help show the impact of any updates. Starting from a dev command prompt at the root of the repo after following the above build instructions:
- Run
build_projection.cmdin the dev command prompt - Run
build_prior_projection.cmdin the dev command prompt as well - Run
prepare_versionless_diffs.cmdwhich removes version stamps on both current and prior projection - Use a directory-level differencing tool to compare
_build\$(arch)\$(flavor)\winrtand_reference\$(arch)\$(flavor)\winrt