Add vs2022 mapping file and support warning level from iwyu_tool

[ThosRTanner]

This adds a couple of small tweaks to help those of us working with visual studio 2022

1. A .imp file for windows headers. I've made windef, minwindef and winuser.h all map to windows.h because they do not compile by themselves (despite visual c++ include checker suggesting it...)
2. A small tweak to iwyu_tool to support outputting the messages as warning level instead of error level (useful for working with visual c++ which understands clang messages, but causes the build to come to a dead stop on errors.)

Note this is on not-the-latest iwyu as the latest llvm isn't available in the right sort of way for windows, yet. Which appears to be causing a build error in the check.

[kimgr]

Nice, thanks! Can I ask you to split it into three distinct commits;

• .gitignore changes
• iwyu_tool.py changes
• mappings

And it might be nice to split it into three different PRs, because they're entirely unrelated, and some might need more iterations before merge than the others.

[kimgr]

Also, if you rebase on latest IWYU master, CI should be able to build (there's been a breaking change in Clang since you last pulled upstream master).

[ThosRTanner]

well, I can do that but I can't actually build iwyu with that version is clang / llvm version 19 is available pre-packed yet. but will redo as 3 separate PRs, (but honest, it was just to get it usable with visual c++...)

Also I think the CI might be slightly broken if it's not pulling main branch on top of this change before verifying it.

[kimgr]

I can also do it, if you prefer.

Also I think the CI might be slightly broken if it's not pulling main branch on top of this change before verifying it.

Yeah, I was actually surprised to see a PR running on top of a rebased master in another project today. But doing it that way makes a lot more sense. I'm not sure what I'm doing wrong in our current GitHub Actions workflow: https://github.com/include-what-you-use/include-what-you-use/blob/master/.github/workflows/ci.yml#L45

[firewave]

I'm not sure what I'm doing wrong in our current GitHub Actions workflow

I am not sure. But I see no need for that IWYU_CHECKOUT_REF stuff. Just do uses: actions/checkout@v4 without any parameters.

[kimgr]

@ThosRTanner Do you mind if I commandeer these changes? I don't have a Window system to test on, but I'd be happy to split up and adjust the individual changes for mainline if you're not already doing something.

[ThosRTanner]

Sure, no problem. I've split them up into 3 commits anyway. My time can be a bit bursty I'm afraid, and I can't build IWYU for the latest llvm until the latter has been built appropriately for windows. (And hopefully this time they won't put in a hard coded reference to visual c++ 2019 professional - see llvm/llvm-project#86250 !)

[ThosRTanner]

Hm. some of the windows mappings seem wrong. windows headers are despicably evil.

The other 2 changes are OK, though

[kimgr]

@ThosRTanner Please take a look: #1515

[kimgr]

I'm not so sure about this mapping as a whole.

It's convenient for a VS2022 user, but it actually covers 3 unrelated libraries:

• The Windows SDK (which ships on a different cadence than Visual Studio)
• The MSVC STL (which I think is strictly speaking bound to the compiler release cadence, not the IDE... or maybe the compiler is bound to the IDE, not sure)
• The Universal CRT (which is Microsoft's attempt at a libc separate from compiler and IDE)

We typically ship mappings per library so they can be versioned as the library changes. It looks to me like these mappings are just what happened to work for your project, in which case it's probably better for you to maintain it as part of the project than as part of IWYU.

Let me know if I'm missing something there.

[ThosRTanner]

Well, maybe that should be multiple mapping files then? I didn't do any special settings so these changes look like things that users of visual c++ are likely to stumble across.

I couldn't find anything for windows in the project, so I thought it might be useful for others, not just me. Having said which if it needs to be 3 files, it needs to be 3 files.

[kimgr]

They look very sparse, I was curious how likely it is that another project using e.g. "shlwapi.h", <map> or <algorithm> would work with these mappings? My guess is not very.

I've tried to build a library mapping generators under https://github.com/include-what-you-use/include-what-you-use/tree/master/mapgen so that users can generate mappings from the actual installed libraries rather than carrying hand-edited mappings for everything in the project. I think it would be better to invest in something like that for the Windows/MSVC libraries.