The LLVM tools should be working fine on Windows, so we just need to test the script and make necessary changes. Still not a high priority, but is more relevant now since the final switch to clang on Windows seems to be done.

Looks like llvm-cov and llvm-profdata binaries should be available in llvm-code-coverage bundle on Windows, similarly to other platforms: https://cs.chromium.org/chromium/src/tools/clang/scripts/package.py?dr=C&l=339

Yuke, what are your plans on this?

Given that Windows is our largest desktop platform, I think we should consider this to be a bit of a priority. Thanks.

That's a good point. I think Yuke is pretty busy with other important tasks right now.

grt@, do you work on Windows? Maybe you want to give this a shot? :)

That's a good point. I think Yuke is pretty busy with other important tasks right now.

grt@, do you work on Windows? Maybe you want to give this a shot? :)

Adding some more windows stakeholders. I will setup some time to discuss this more.

Code coverage would be good. My chrome-Windows team is rather resource constrained at the moment (it will be down to one person for the next two weeks) but might be able to help in the future.

Thanks Bruce, putting this in your queue then.

Note that JF Bastien from Apple is trying to get clang-cl support atm. See http://clang-developers.42468.n3.nabble.com/Using-code-coverage-in-clang-cl-exe-td4060621.html

When i tried building locally with use_clang_coverage, i was getting the same sort of errors (after removing -fno-use-cxa-atexit).

So there are two things that need to be done.
1. Ensure that stuff builds with use_clang_coverage.
gn gen --args="is_clang=true use_clang_coverage=true ffmpeg_branding=\"Chrome\" is_component_build=false is_debug=false proprietary_codecs=true" //out/coverage 
ninja -C out\coverage crypto_unittests

2. Make code_coverage.py cross-platform. Since we wrote this, can help to answer any questions, code review, etc.

3. Setup windows coverage bot, i think we can involve chrome infra here. but atleast with points 1,2 anyone can see coverage stuff locally with their build targets.

 http://clang-developers.42468.n3.nabble.com/Using-code-coverage-in-clang-cl-exe-td4060621.html is confused about who's sending these messages. None of them are from JF Bastien. The original email was from ניצן חדד, the first reply from rnk, the 2nd from Miklos Vajna, the third ניצן חדד again, then rnk again, then phosek.

 Issue 845590  has been merged into this issue.

I think code coverage reports lose a **lot** of their value if code paths only hit on Windows are reported as "uncovered".

base/task_scheduler is reported at 96% but the vast majority of the remaining 4% is Windows only code and DCHECKs (issue 843209).

I'll be unable to monitor coverage there after doing the first pass I just did until it's easy to hit ~100%.

gab@, you have a valid point, but merge across platforms is even more complicated and actually is not possible with existing toolchain. See issue 844162 and issue 845735.

However, I wouldn't say that "coverage reports lose a **lot** of their value" :)

We see people landing nice CLs adding new tests or removing dead code in order to improve the coverage they see in the reports.

As for platform specific code, I suspect that you can split that into separate files rather then rely on the preprocessor. That way you won't see Windows specific files in Linux coverage reports at all, i.e. you could reach 100% - DCHECKS, and that might be a better design in general :)

Sorry, I didn't mean to infer code coverage is "useless", just that after doing a first pass over my code, I will not be able to monitor it because monitoring anything short of 100% isn't feasible (unless we could annotate perhaps..?).

As for splitting Windows specific code off : it isn't that simple. Some code in base/task_scheduler isn't "Windows-specific" per se but I know that in practice some code is "uncovered" because only a TaskScheduler initialized in a Windows configuration will trigger some of the platform agnostic code at the moment (e.g. because of conditions based on Lock::HandlesMultipleThreadPriorities() which is currently mostly only true on Windows).

That makes sense. Thanks for the feedback!

I believe that we'll resolve the issues mentioned above and figure out a solution even for cross-platform stuff, but it's hard to predict any ETA right now.

Adjusting priority (should maybe actually be 3...)