Codecov Report

Patch and project coverage have no change.

Comparison is base (d104ee5) 85.06% compared to head (fb02761) 85.06%.

@@           Coverage Diff           @@
##           master    #3806   +/-   ##
=======================================
  Coverage   85.06%   85.06%           
=======================================
  Files         226      226           
  Lines       53857    53857           
=======================================
  Hits        45816    45816           
  Misses       8041     8041           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@k-takata Could you review this?

libyaml libxml2 jansson all support cmake build system, cmake is supported as of Virsual Studio 2017
https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio-the-visual-studio-2017-rc-update/

These packages could be easily built with cmake even if do not use any package managers.

Do you know if we can use C11? I frequently want to use anonymous union and struct.

MS document about C11 and C17 is here:
https://learn.microsoft.com/en-us/cpp/overview/install-c17-support?view=msvc-170
Also related:
https://learn.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformance?view=msvc-170

I frequently want to use anonymous union and struct.

This has been supported in MSVC for more than 25 years, I think.

per https://learn.microsoft.com/en-us/cpp/overview/install-c17-support?view=msvc-170

Support for C11 and C17 standards is available in Visual Studio 2019 version 16.8 and later. 

Support requires an updated Universal C Runtime (UCRT) and Windows SDK version to work properly with the conforming preprocessor ([/Zc:preprocessor](https://learn.microsoft.com/en-us/cpp/build/reference/zc-preprocessor?view=msvc-170)).

If we do support the latest two releases of Vistual Studio (Vistual Studio 2022 and Vistual Studio 2019 at this point), using C11 should have no problem.

This has been supported in MSVC for more than 25 years, I think.

@k-takata

You mean anonymous union and struct had been suppoted by Vistual Studio prior to C11?

I have no windows programming experience at all.

as per these documentations:

https://learn.microsoft.com/en-us/cpp/c-language/structure-declarations?view=msvc-140
https://learn.microsoft.com/en-us/cpp/c-language/structure-declarations?view=msvc-150
https://learn.microsoft.com/en-us/cpp/c-language/structure-declarations?view=msvc-160
https://learn.microsoft.com/en-us/cpp/c-language/structure-declarations?view=msvc-170

It seems that anonymous union and struct already have been suppoted by Vistual Studio many years ago.

@leleliu008, let's merge this.

Thank you. I'll make a pull request that uses the "anonymous struct and union" of C11 and see what happens.

You mean anonymous union and struct had been suppoted by Vistual Studio prior to C11?

Yes.

@leleliu008 @k-takata Can we remove the combination

    - compiler: msvc
      ARCH: x64

from appveyor.yml now?

I would like to work on #3795 after making the pull request pass all the testing.

this PR is implemented as https://github.com/universal-ctags/ctags/blob/master/win32/appveyor.bat#L63-L105

https://github.com/universal-ctags/ctags/blob/master/win32/appveyor.bat#L107-L109 is left, I don't known if https://github.com/universal-ctags/ctags/blob/master/.github/workflows/testing-msys2.yml#L56 is covered these tests. if not, we should add these tests to testing-msys2.yml

If you just want to pass the workflows on appveyor, I think applying following patch is the easiest way:

diff --git a/appveyor.yml b/appveyor.yml
index edd8c5ae..f8a38380 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -16,6 +16,7 @@ environment:
     #   MSYSTEM: MINGW32
     - compiler: msvc
       ARCH: x64
+      APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2019
     #- compiler: msvc
     #  ARCH: x86
     - compiler: mingw

Reference: https://www.appveyor.com/docs/build-environment/#choosing-image-for-your-builds

If the build configuration does not specify build worker image then Visual Studio 2015 image is used.

our appveyor.yml doesn't specify build worker image, so Visual Studio 2015 image is used. We could explicitly tell appveyor that we want to use Visual Studio 2019 or Visual Studio 2022

@masatake
I was gonna tweak appveyor.yml and win32/appveyor.bat via PR (#3815), but it fails due to some compiler warnings. I have no idea what's going on, GitHub Actions use Visual Studio 2019 Enterprise has no warnings. AppVeyor use Visual Studio 2019 Community reports some warnings, due to /WX compiler option is used, these warrnings are treated as errors and abort the build process.

@leleliu008 @k-takata Can we remove the combination

    - compiler: msvc
      ARCH: x64

from appveyor.yml now?

I would like to work on #3795 after making the pull request pass all the testing.

I think msvc-x64 environment for appveyor can be removed. running units on MSYS2 had been added via PR (#3817) just now.

I was gonna tweak appveyor.yml and win32/appveyor.bat via PR (#3815), but it fails due to some compiler warnings. I have no idea what's going on, GitHub Actions use Visual Studio 2019 Enterprise has no warnings.

It seems that the code generated by packcc causes the warnings. I'll look into it.

I was gonna tweak appveyor.yml and win32/appveyor.bat via PR (#3815), but it fails due to some compiler warnings. I have no idea what's going on, GitHub Actions use Visual Studio 2019 Enterprise has no warnings.

It seems that the code generated by packcc causes the warnings. I'll look into it.

What I'm confused is that GitHub Actions and AppVeyor both use Visual Studio 2019, the only difference is that the former is Enterprise Edition, the later is Community Edition

What I'm confused is that GitHub Actions and AppVeyor both use Visual Studio 2019, the only difference is that the former is Enterprise Edition, the later is Community Edition

The AppVeyor job is compiled with -DDEBUG and the GHA job is compiled without -DDEBUG.
Line 133 of peg_common.h is compiled only when DEBUG is defined.

@k-takata Thank you very much for the hint.

It seems that the code generated by packcc causes the warnings. I'll look into it.

It seems that peg\peg_common.h is not generated by packcc.