Disable _Atomic and __thread keywords on JetBrains IDE only

[picnixz]

Note

I already have a PR ready in case this is accepted

This is really a silly issue and it's really not an issue with CPython. The issue is on CLion's side (https://youtrack.jetbrains.com/issue/CPP-15688/False-error-highlighting-for-C11-atomic-functions). The issue has been there for at least the past decade and nothing seemed to advance on JetBrains' side.

Let's assume that I have a file, say a.h in which I have extern _Atomic(size_t) something;. In another file, I include a.h and use size_t i;. Then CLion complains with "Ambiguous symbol size_t". There is one declaration in a.h and the libc declaration typedef __SIZE_TYPE__ size_t;.

So anything that is _Atomic(T) and uses T elsewhere while including a file that has _Atomic(T) somewhere ends up with that kind of issue. For CPython, this would be extern _Atomic(size_t) _mi_numa_node_count; but there are other occurrences, for instance for uintptr_t elsewhwere.

A similar issue happens with __thread. While CLion recognizes the macro, it suggests to include thread.h to use thread_local instead and the inspection cannot be disabled.

So, now, why would this be actually CPython's responsibility? well.. this is because it really annoys me and hinders me when developing on CLion. Because of _Atomic issues, I have syntax errors everywhere and I can't reliably go through real errors.

For instance, when I inspect the mimalloc bundled files, here's what my IDE would show:

Or, even worse, when I just inspect the _hashopenssl.c module, I have

Considering the sheer amount of size_t across the code base, this is very disturbing. There is however a simple and very portable solution: __JETBRAINS_IDE__.

The __JETBRAINS_IDE__ macro is a macro that is set when CLion is parsing code, so never at runtime or whatever (see https://blog.jetbrains.com/clion/2017/02/clion-2017-1-eap-debugger-fixes-ide-macros-and-new-cmake/). Because of this, we can easily do the following in pyport.h:

/*
 * Disable keywords and operators that are not recognized by CLion.
 *
 * This is only a temporary solution until CLion correctly supports them.
 */
#ifdef __JETBRAINS_IDE__
/*
 * Prevents false positives in CLion's static analysis which incorrectly
 * detects _Atomic(size_t) and _Atomic(uintptr_t) as duplicated declarations
 * of size_t and uintptr_t respectively.
 */
#define _Atomic(x)  x

/* Ignore C99 TLS extension '__thread' keyword. */
#define __thread
#endif

Fortunately, _Atomic T is not used across CPython code base, so we're safe on this side and only _Atomic(T) is replaced by T at CLion parse time. It will not affect VSCode or vim users.

Note that sre.c and sre_lib.h have vim-only comment:

/* vim:ts=4:sw=4:et
*/

We also have in bytecode.c:

// Note that there is some dummy C code at the top and bottom of the file
// to fool text editors like VS Code into believing this is valid C code.
// The actual instruction definitions start at // BEGIN BYTECODES //.
// See Tools/cases_generator/README.md for more information.

So it's not unprecedented that we have some editor-only hacks in the project.

cc @colesbury @erlend-aasland @vstinner @serhiy-storchaka

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

Linked PRs

• gh-134585: disable _Atomic and __thread keywords during CLion parsing phase #134625

[serhiy-storchaka]

Would adding #include <stddef.h> help?

[picnixz]

Err... I never tried. I'm not on my dev session but I'll try this tomorrow. However, I don't think it helps because even the _Atomic declarations at the libc level are highlighted in red for CLion.

[picnixz]

So I tried, and indeed it doesn't help. I think the issue is really with CLion parser and I can only suggest this hacky solution. I'm now used to having red marks but navigating through "next error" is still annoying.

[picnixz]

I'll open a PR to check with buildbots first (still as a PoC)

[vstinner]

Did you report the issue to CLion? I would prefer to fix the issue in CLion rather than having to modify Python.

[picnixz]

It was reported 6 years ago and nothing has changed since then :(

[picnixz]

Ok, turns out there is a workaround that works for me. By using ./configure CC=clang, the errors are gone so I'm going to disable this one. I can definitely use clang by default though I'm more used to GCC (well the __thread macro issue persists but this is a really minor one)