Stddef.h переопределяет size_t с неправильной шириной только в clang-tidy

У меня есть два параллельных стека сборки. В первом (рабочем) стеке GCC 7.3.1-1.2.2, установленный в качестве кросс-компилятора, собирает 32-битную цель Arm.

Во втором (неработающем) стеке vscode 1.90.1 с плагином C/C++ 1.20.5 включен clang-tidy. Clang рассказали, где находится настоящий компилятор, через c_cpp_properties.jsoncompilerPath. Я пытался проверить код через clang-tidy. Я знаю, что он компилируется «в реальной жизни», но clang-tidy полон ложных срабатываний. я тоже бегал

echo | /.../arm-none-eabi-gcc/7.3.1-1.2.2/.content/bin/arm-none-eabi-g++.exe (realistic-args...) -dM -E -x c++ -

извлекать реалистичные определения; некоторые важные из них, которые я установил в конфигурации defines:

                "__GNUG__=7",
                "__SIZE_MAX__=0xffffffffU",
                "__SIZE_TYPE__=unsigned int",
                "__SIZE_WIDTH__=32",
                "__SIZEOF_SIZE_T__=4",

которые все кажутся правильными. И даже в пустом .cpp, когда я пишу

unsigned int z = sizeof(int);

ошибок проверки нет, и при наведении курсора на выражение sizeof отображается (unsigned int)4U, как и ожидалось.

Проблема возникает, когда я включаю stddef.h прямо или косвенно практически через любую часть STL. в clang-tidy кризис, он не может разобрать файл и пишет

stddef.h[Ln 216, Col 23]: typedef redefinition with different types ('unsigned int' vs 'unsigned long long')

Регион, на который жалуется:

#if !(defined (__GNUG__) && defined (size_t))
typedef __SIZE_TYPE__ size_t;

После этого происходят бесконечные каскадные сбои. Подписи operator new не работают из-за несоответствий 32/64, а <string> имеет аналогичные сбои из-за несоответствия шаблонов size_t.

Что дает? Откуда взялся size_t, который не запускал бы предикат #if, но вызывал бы сбой typedef? Похоже, это ошибка в clang-tidy (а не в vscode или gcc), потому что я попробовал clang-tidy для тривиального входного файла из командной строки, и это не удалось аналогичным образом.

Я попробовал добавить

"compilerArgs": [
    "-isystem", "${env:APPDATA}/xPacks/@xpack-dev-tools/arm-none-eabi-gcc"
]

но это тоже не помогло.

Связанный

ложное срабатывание clang-tidy: stddef.h size_t — аналогичная проблема, но с другим набором инструментов (ESP-IDF, который я не использую); и один ответ

"C_Cpp.intelliSenseEngine": "Tag Parser"

для меня ничего не меняет.

Clang-tidy: как настроить size_t, uintptr_t и указатели на 32-бит?

оказывается, есть правильное решение, но для вопроса с другими условиями поиска и другим описанием.

🤔 А знаете ли вы, что...
C продолжает оставаться важным инструментом для программистов, и его значимость не угасает.


1
81
1

Ответ:

Решено

Хотя этот ответ - Clang-tidy: как настроить size_t, uintptr_t и указатели на 32-бит? - это вопрос, который не касается руки, это именно то, что мне нужно было сделать. Измените settings.json, чтобы включить

"C_Cpp.codeAnalysis.clangTidy.args": [
    "--extra-arg=--target=arm"
],

и все проблемы 32/64 исчезнут. Обратите внимание, что это не то же самое, что включение --target=arm в compilerArgs.


Интересные вопросы для изучения

Может ли оптимизирующий компилятор при встраивании функции C разыменовывать указатель большее количество раз, чем явно написано в исходном коде?Почему TCC не создает мой пользовательский раздел?Почему я не могу получить доступ к местоположению в массиве указателей char с разыменованием указателя int как индексаVscode IntelliSense не работает для C/C++, что бы я ни делалЗапуск установки пакета в моем приложении Ruby on Rails генерирует ошибки в sqlite3 и nio4rVscode IntelliSense не работает для C/C++, что бы я ни делалПривязка клавиш VS Code для запуска отладки с определенной конфигурацией отладки?Скопируйте значение первого атрибута, а затем создайте новый атрибут со значением первого атрибутаДинамический тип возвращаемого значения на основе значения параметра JSDocМогу ли я использовать инструменты разработчика VS Code Edge с URL-адресом, а не только с файлом в моем проекте?