This is really a silly issue and it's reallynot 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, saya.h in which I haveextern _Atomic(size_t) something;. In another file, I includea.h and usesize_t i;. Then CLion complains with "Ambiguous symbolsize_t". There is one declaration ina.h and the libc declarationtypedef __SIZE_TYPE__ size_t;.

So anything that is_Atomic(T) and usesT elsewhere while including a file that has_Atomic(T) somewhere ends up with that kind of issue. For CPython, this would beextern _Atomic(size_t) _mi_numa_node_count; but there are other occurrences, for instance foruintptr_t elsewhwere.

A similar issue happens with__thread. While CLion recognizes the macro, it suggests to includethread.h to usethread_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 themimalloc 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 ofsize_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 isparsing code, so never at runtime or whatever (seehttps://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 inpyport.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 byTat CLion parse time. It will not affect VSCode or vim users.

Note thatsre.c andsre_lib.h have vim-only comment:

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

We also have inbytecode.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