microsoft/STL

<intrin.h>: clang-tidy and "expected function body after function declarator"

ZaldronGG opened this issue ยท 24 comments

Describe the bug
After updating to 16.8.0 Preview 3, I've been getting strange errors from Clang-Tidy. Fearing it was some weird interaction between my MSBuild config, .clang-tidy, the Unity build, or project structure, I tried a simple x64 console project right from the templates and managed to get the same error:

Build started...
1>------ Build started: Project: ClangTidyIssue, Configuration: Debug x64 ------
1>ClangTidyIssue.cpp
Error while processing C:\Darkmere\experiments\ClangTidyIssue\ClangTidyIssue.cpp.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\MSVC\14.28.29304\include\intrin.h(56,1): error G7973E533: expected function body after function declarator [clang-diagnostic-error]
__MACHINE(void * _AddressOfReturnAddress(void))
^
Suppressed 1 warnings (1 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
Found compiler error(s).
1>Done building project "ClangTidyIssue.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Command-line test case
Just create a new Console Application, Enable Code Analysis on build and Clang-Tidy, build in x64/Debug.

Expected behavior
No compile failures ([clang-diagnostic-error]) every time intrin.h is included.

STL version
Microsoft Visual Studio Community 2019 Preview Version 16.8.0 Preview 3.0

Thanks for reporting this issue - while intrin.h is technically not part of the STL repo, we caused this issue by changing the header (ironically, to address other issues with Clang), so instead of asking you to file this on Developer Community, we can continue tracking the issue here. We're a bit busy with CppCon at the moment but we'll try to investigate soon as this is a very recent regression.

Thanks for the prompt response! I was hesitant to report the issue here as I couldn't find intrin.h, but I was also incapable of logging into Developer Community all day long ๐Ÿ˜ฃ. Not a blocker of any kind; enjoy the rest of CppCon!

Adding to this problem:

  1. intrinsics of mm sector including _mm_shuffle_ps turns red and speaks of invalid type conversion
  2. for cycle broke away, every declaration inside is red, and usage of iterator inside results in errors

but seems to compile without errors though.
image

Given that we have independent reports from users about two different problems caused by this change within two days of the preview release, I think we should make this a priority and try to get it fixed for 16.8.

I believe I can fix this (with a change entirely within intrin0.h); unfortunately I believe I've missed the 16.8 cutoff (the bar for porting fixes is very high now, and this doesn't affect the codegen compilers).

I believe I've fixed this with Microsoft-internal MSVC-PR-278849 which will ship in VS 2019 16.9 Preview 2.

@StephanTLavavej

Thanks for getting this issue fixed! Since the change won't be making it into 16.8, can you share with us any details of what the fix was? It might make it easier for us to work around the issue ourselves.

@ParthogenDavid Here's the actual diff for the fix we applied.

GH-1300.diff.txt

Thanks, that's perfect!

I'm a bit confused. Does this mean that 16.8 is incompatible with clang and we will have no fix for the next months? Using VC 2019 16.9 Preview is not an option for me.

In my experience Clang itself works fine, it's libclang (and tools based on it) which have issues. (Why there's a difference in behavior between Clang and libclang I couldn't tell you.)

(Also for what it's worth, the fix does not appear to have made it into 16.9 Preview 1.)

(Also for what it's worth, the fix does not appear to have made it into 16.9 Preview 1.)

See #1300 (comment) above:

I believe I've fixed this with Microsoft-internal MSVC-PR-278849 which will ship in VS 2019 16.9 Preview 2.

Good to know the difference in clang vs. libclang. I didn't know that. Unfortunately I'm interested in using clang tools, not the clang compiler. For me this is a blocker to use 16.8. Seems like I have to skip this release and wait for 16.9. Microsoft seems to be committed to support clang tools as well. Would regression tests with e.g. clang-tidy for the STL make sense?

It could be reasonable to add such a regression test, especially if (1) clang-tidy is installed along with clang-cl by VS (haven't checked), (2) an "include all headers" test finds issues like this, and (3) it doesn't take exceptionally long to run, or constantly fails for essentially spurious reasons. We're somewhat wary of increasing our "support matrix", but it seems like using clang-tidy with the STL is a common scenario.

I get this issue whenever I try to use this extension: https://github.com/Viladoman/StructLayout

Struct Layout uses Clang LibTooling internally to parse the C++ files and extract the memory layout information.

Thank you for the workaround! I went to use clang and was confused for a sec before finding your diff - compiles without the intrin file error now. Kinda super new to using clang and thought my compilation of llvm was screwed up lol

tuket commented

I get this issue whenever I try to use this extension: https://github.com/Viladoman/StructLayout

Struct Layout uses Clang LibTooling internally to parse the C++ files and extract the memory layout information.

Me too

Shiboken also uses libclang, everything based on it breaks in 16.8.3 (latest release). Why isn't this being hotfixed into 16.8?

I agree this should be hotfixed. Breaks my code generation as well (https://github.com/haikarainen/WIR.Framework)

Since I use clangd as my language server instead of cpptools in vscode, and clangd internally uses clang-tidy, I keep getting errors under the first include of any file. It's mildly annoying but curiously, everything else seems to work, even with that error.

Agree on need for hotfix to 16.8, all progress on LLVM.NET is now halted as we can't build anymore. Installing the preview isn't an option as the environments for GitHub Action builds don't support the preview releases of VS. Only the release versions.

Hotfix would be appropriate. For now we can use temporary hack (copied from mono/CppSharp) fix_intrin.ps1:

$intrin = 'C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/MSVC/14.28.29333/include/intrin0.h'
if (!(Test-Path $intrin)) {
  Write-Warning "This hack is no longer needed and should be removed."
}
else {
    $content = ((Get-Content $intrin) -replace 'ifdef __clang__', 'ifdef __avoid_this_path__')
    [IO.File]::WriteAllLines($intrin, $content)
}
e4lam commented

I'm still waiting for an official stable release for this fix. Anyone know if VS 16.9 GA is supposed to be happening soon or not?

VS 2019 16.9 was released for production use yesterday (March 2).