Description
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
#endifFortunately, _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