C++/WinRT
Перейти к файлу
David Machaj fa079fb34b
Address variable name collisions in generated consume methods (#1455)
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.
2024-11-19 16:25:25 -08:00
.config/1espt TDBuild - updating localized resource files. 2024-03-31 05:01:31 +00:00
.github Try to fix the disabled/failing nuget test build step (#1451) 2024-11-15 16:12:21 -08:00
.pipelines GitHub Actions workflow cannot build arm32 after updating Windows SDK (#1454) 2024-11-18 16:52:31 -08:00
cppwinrt Address variable name collisions in generated consume methods (#1455) 2024-11-19 16:25:25 -08:00
docs Clarify contributing guide (#1324) 2023-06-21 15:16:35 -05:00
fast_fwd GitHub Actions workflow cannot build arm32 after updating Windows SDK (#1454) 2024-11-18 16:52:31 -08:00
mingw-support Add CMake build and a limited subset of tests for llvm-mingw (#1216) 2022-11-09 10:26:19 -06:00
natvis Spelling (#1412) 2024-04-06 07:17:18 -05:00
nuget GitHub Actions workflow cannot build arm32 after updating Windows SDK (#1454) 2024-11-18 16:52:31 -08:00
prebuild GitHub Actions workflow cannot build arm32 after updating Windows SDK (#1454) 2024-11-18 16:52:31 -08:00
scratch GitHub Actions workflow cannot build arm32 after updating Windows SDK (#1454) 2024-11-18 16:52:31 -08:00
strings GitHub Actions workflow cannot build arm32 after updating Windows SDK (#1454) 2024-11-18 16:52:31 -08:00
test GitHub Actions workflow cannot build arm32 after updating Windows SDK (#1454) 2024-11-18 16:52:31 -08:00
vsix GitHub Actions workflow cannot build arm32 after updating Windows SDK (#1454) 2024-11-18 16:52:31 -08:00
.gitattributes Build (#478) 2020-01-16 09:16:13 -08:00
.gitignore Add GitHub Action build and test workflow for MSVC (#1201) 2022-10-14 17:15:09 -05:00
CMakeLists.txt cmake: Allow using external winmd headers to bypass download (#1256) 2023-01-03 11:33:25 -06:00
Directory.Build.Props GitHub Actions workflow cannot build arm32 after updating Windows SDK (#1454) 2024-11-18 16:52:31 -08:00
Directory.Build.Targets catch is evidently incompatible with VS 2022 (platform toolset v143) - backing off to unblock (#1127) 2022-03-23 15:35:56 -07:00
LICENSE clean 2019-10-08 05:14:30 -07:00
README.md GitHub Actions workflow cannot build arm32 after updating Windows SDK (#1454) 2024-11-18 16:52:31 -08:00
build_nuget.cmd GitHub Actions workflow cannot build arm32 after updating Windows SDK (#1454) 2024-11-18 16:52:31 -08:00
build_prior_projection.cmd GitHub Actions workflow cannot build arm32 after updating Windows SDK (#1454) 2024-11-18 16:52:31 -08:00
build_projection.cmd GitHub Actions workflow cannot build arm32 after updating Windows SDK (#1454) 2024-11-18 16:52:31 -08:00
build_test_all.cmd GitHub Actions workflow cannot build arm32 after updating Windows SDK (#1454) 2024-11-18 16:52:31 -08:00
build_vsix.cmd GitHub Actions workflow cannot build arm32 after updating Windows SDK (#1454) 2024-11-18 16:52:31 -08:00
compile_tests.cmd port 2019-10-08 08:19:10 -07:00
cppwinrt.sln GitHub Actions workflow cannot build arm32 after updating Windows SDK (#1454) 2024-11-18 16:52:31 -08:00
cross-mingw-toolchain.cmake Spelling (#1412) 2024-04-06 07:17:18 -05:00
nuget.config Add NuGet config with public feed (#1433) 2024-09-05 10:22:01 -07:00
prepare_versionless_diffs.cmd GitHub Actions workflow cannot build arm32 after updating Windows SDK (#1454) 2024-11-18 16:52:31 -08:00
run_tests.cmd Remove old Windows 7 support code (#1348) 2023-08-28 08:35:09 -05:00

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.

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.sln solution.
  • 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.sln solution
  • 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.cmd in the dev command prompt
  • Run build_prior_projection.cmd in the dev command prompt as well
  • Run prepare_versionless_diffs.cmd which removes version stamps on both current and prior projection
  • Use a directory-level differencing tool to compare _build\$(arch)\$(flavor)\winrt and _reference\$(arch)\$(flavor)\winrt