problems: macro expansion: expected a ')'

[cheako]

Type: LanguageService

From: https://github.com/microsoft/vscode-cpptools/issues/3145#issuecomment-469894523 https://github.com/microsoft/vscode-cpptools/issues/3145#issuecomment-469988599

I don't see where a new issue was created or what work further has been done.

Describe the bug

• OS and Version: Debian Buster
• VS Code Version: 1.53.2
• C/C++ Extension Version: v1.1.3 and v1.2.2
• Other extensions you installed (and if the issue persists after disabling them): How to do this?
• Does this issue involve using SSH remote to run the extension on a remote machine?: NO
• A clear and concise description of what the bug is, including information about the workspace (i.e. is the workspace a single project or multiple projects, size of the project, etc).

Macros seem to not being processed correctly. Examples assert, assert_return, LIST_REMOVE.

assert_return(lease, -EINVAL);

#define assert_return(expr,r) do { if (!assert_log(expr, #expr)) return (r); } while (false)
Expands to:

do { if (!assert_log(lease, "lease")) return (-22); } while (false)

Steps to reproduce

git clone --depth 1 https://github.com/systemd/systemd.git
cd systemd
code src/libsystemd-network/sd-dhcp6-lease.c 

Expected behavior

Code and expansion look fine. A fix is in the details.

Logs

``` ------- Potential include path issues -------- Some headers exist in multiple locations. If IntelliSense is behaving incorrectly, try adding one of the alternate paths to the "includePath" in your configuration in c_cpp_properties.json to override the automatic path discovery for that header. Using: /usr/include/linux/if_ether.h Alternative: "/home/cheako/src/gitlab/systemd/src/basic" Using: /home/cheako/src/gitlab/systemd/src/basic/util.h Alternative: "/home/cheako/src/gitlab/systemd/src/boot/efi" ``` So I fixed that then got: ``` [2/28/2021, 10:29:20 AM] For C source files, IntelliSenseMode was changed from "linux-gcc-x64" to "linux-clang-x64" based on compiler args and querying compilerPath: "/usr/bin/clang" [2/28/2021, 10:29:20 AM] For C++ source files, IntelliSenseMode was changed from "linux-gcc-x64" to "linux-clang-x64" based on compiler args and querying compilerPath: "/usr/bin/clang" ``` All is now well, the fix: ``` mkdir -f .vscode cat >.vscode/c_cpp_properties.json <<'EOF' { "configurations": [ { "name": "Default", "includePath": [ "./src/basic", "./src/boot/efi" ], "intelliSenseMode": "linux-gcc-x64", "compilerPath": "/usr/bin/clang", "cStandard": "c17", "cppStandard": "c++14" } ], "version": 4 } EOF ```

Screenshots

Additional context

Please make C/C++: Log Diagnostics more friendly. Saying to apply includePath to c_cpp_properties.json has me thinking:

mkdir -f .vscode
cat >.vscode/c_cpp_properties.json <<'EOF'
{
    "includePath": [
        "./src/basic",
        "./src/boot/efi"
    ]
}
EOF

I had to google to get at the correct syntax and it's a mess not to have some URLs, like for when git merges fail.

[cheako]

As soon as I add "${workspaceFolder}/**", or "src/fundamental", the problem returns.

[sean-mcmanus]

Using "${workspaceFolder}/**" can cause problems if your workspace has files that match system headers.

Do you think there's a bug?

[cheako]

@sean-mcmanus when I said or I actually meant xor, sorry for not making that distinction. Yes, using "${workspaceFolder}/**" gave me issues. I removed the all inclusive thing that was painful and "replaced" it with the more concise "src/fundamental". The pain didn't go away or even change. I'm unsure if src/fundamental contains files that share the same name as system headers.

I'm no expert, but I'd guess/hope that -I"src/fundamental" means something and that there are separate flags for <> and ""? I could do some experimenting, but that you're not suggesting one config option(IncludePath) is equivalent to -I and another is the for paths passed to whatever else controls how headers are found: concerns me.

So I can say for sure something is wrong with the above statement, if it's a bug I can't yet say.

[sean-mcmanus]

If your build process uses -I "src/fundamental" and that compiles, then it's supposed to work the same for our tool, even with the same names (your build process would pick up the files in src/fundamental when there's a name conflict), unless you're missing some required compilerArgs.

Yeah, it sounds like it could be a bug. I'll see if I (or someone else) can get a repro.

[sean-mcmanus]

@cheako

• What do you believe is incorrect with how the macro is displayed in the hover result? It appears correct to me.
• Your repro step says "code src/libsystemd-network/sd-dhcp6-lease.c " which is the open file scenario, which won't be able to find the definition of the asserts, so I assume that repro step is incorrect and you meant to say to open the folder and then open the file?
• I noticed that the asserts give an error squiggle "expected a )" which appears to be caused by the usage of the identifier RELATIVE_SOURCE_PATH which appears to be defined in the meson.build file, but the squiggle goes away after I define that. UPDATE: I just realized your title mentioned this error message, so that is likely what you're hitting.
• FYI, your repo gives this error on Windows: "error: invalid path 'test/fuzz/fuzz-unit-file/dev-mapper-fedora_krowka\x2dswap.swap' error: invalid path 'units/system-systemd\x2dcryptsetup.slice'".

[sean-mcmanus]

Also, the includePath needs "src/basic" for the macro.h header and it might need "src/fundamental" for other stuff in macro-fundamental.h. And ${workspaceFolder}/** appears to correctly add those 2 folders (when I do C/C++: Log Diagnostics).

[github-actions[bot]]

This issue has been closed automatically because it needs more information and has not had recent activity.