У меня есть два параллельных стека сборки. В первом (рабочем) стеке 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-бит?
оказывается, есть правильное решение, но для вопроса с другими условиями поиска и другим описанием.
У вас возникли проблемы с 32-битной и 64-битной компиляцией? Нужно ли где-то указывать -m32?
@JonathanLeffler __GNUG__ как напечатано; это скопировано из вывода -dM -E -x c++. -m32 — волшебное решение! Я приму это, когда оно будет опубликовано в качестве ответа. тывм.
Я беру свои слова обратно: -m32 только «сработало по совпадению», потому что g++ отклонил его как опцию, и vscode вернулся к cl.exe, который продемонстрировал (очевидно) более разумное поведение для 32-битных целей. Кажется, это не самое безопасное решение.
Фактическое решение здесь: stackoverflow.com/questions/73232415/…





Хотя этот ответ - Clang-tidy: как настроить size_t, uintptr_t и указатели на 32-бит? - это вопрос, который не касается руки, это именно то, что мне нужно было сделать. Измените settings.json, чтобы включить
"C_Cpp.codeAnalysis.clangTidy.args": [
"--extra-arg=--target=arm"
],
и все проблемы 32/64 исчезнут. Обратите внимание, что это не то же самое, что включение --target=arm в compilerArgs.
Это
__GNUG__(как напечатано) или__GNUC__(как я ожидал увидеть)?