clang даёт доступ к дереву синтаксического разбора. Эту фичу используют для создания статических анализаторов кода.

clang даёт доступ к дереву синтаксического разбора.

А gcc не даёт?

Насколько я знаю, нет.

Clang имеет модульную архитектуру - отдельно фронт-энд парсер, отдельно платформонезависимый оптимизатор, отдельно кодогенератор и платформозависимый оптимизатор. Таким образом очень легко как добавить поддержку новой архитектуры, так и поддержку нового языка программирования (самое известное, наверное, это rust, работающий на базе llvm). Ну и вообще модульная архитектура упрощает разработку и исправление багов. А ещё у clang более либеральная лицензия, чем у gcc, но кому-то это наоборот покажется минусом.

Clang имеет модульную архитектуру

А gcc нет? Он же тоже кучу языков и архитектур умеет переваривать.

Но тем не менее gcc монолитен и добавление туда нового языка или архитектуры очень большая боль. А для clang есть даже официальные туториалы «как быстро сделать свой язык программирования с jit на базе llvm»

50 LoC if

А gcc нет? Он же тоже кучу языков и архитектур умеет переваривать.

Да, но нет. Проблема в том, что GCC не соблюдает принципы UNIX-Way, он монолитен. А вот Clang/LLVM соблюдает, поэтому его части можно использовать в IDE для подсветки, разбора. автодополнения и статического анализа кода. За счёт этих фич Clang и набрал популярность.

А как он тогда работает?

Сначала подумал, ну и что тут такого, подумаешь жирный if на пол-экрана, ведь все так пишут. But then…

Ладно, кажется я тут опять к терминологии придрался

Очень просто – компилирует исходный код в программу, не предоставляя за свои пределы каких-либо промежуточных результатов, за исключением ассемблерного листинга. А с помощью clan можно, указав «-Xclang -ast-dump», сдампить дерево разбора и использовать его для создания плагинов к IDE, например.

Проблема GCC в том, что у него нету (или в своё время не было) библиотеки подобной libclang, которую можно было бы цеплять к любой IDE и крутить разные полезные финты, попутно выкидывая из кодовой базы IDE стрёмные самописные парсеры C/C++, которые работали нормально только на «лёгком» коде.

Сейчас ситуация, когда практически все релевантные IDE для C и C++ либо используют libclang (KDevelop, Qt Creator), либо опционально предлагают из него различные плюшки (CLion). Остальные либо в процессе прехода на LSP, который использует libclang тоже, либо померли, либо собственные парсеры поддерживают крупные компании (Eclipse, Visual Studio, CLion).

Очень просто – компилирует исходный код в программу, не предоставляя за свои пределы каких-либо промежуточных результатов, за исключением ассемблерного листинга.

https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html

https://gcc.gnu.org/onlinedocs/jit/

А ещё, помимо уже написанного, шланг умеет в reproducible build, в том числе между хостами (собираешь на линупсах и на шиндруз идентичные бинарники)

В общем, тут написал всё правильно написали.

Дополню только что gcc тоже предоставляет свой доступ к представлению, и у него есть система плагинов уже лет 5 как (но в качестве библиотеки его сложно было бы прикрутить), но использовать gcc очень сложно просто потому что у него беда с документацией, да и с удобством использования тоже.

С лицензиями - я хз была бы проблема если бы его использовали как подключаемую библиотеку.

Была бы. Всякие Сани, Яблы и Гуглы хотят, по крайней мере, проприетарные расширения

собираешь на линупсах и на шиндруз идентичные бинарники

Это как вообще возможно? Любое По зависит от системных библиотек, а они совсем разные будут. Ну и под Linux - ELF, под Windows что-то свое...

Сани? Ораклы.

Здесь идентичные бинарники – бинарники у которых хешсумма будет одинакова вне зависимости от погодных условий (всяких там имён файлов, путей, хостов и прочего).

Эм...если я соберу целевой ELF из под linux и из под windows с помощью clang, то они отличаться не будут - это имеется в виду?

Да, но правда х.з. насколько это между хостами с разными OS справедливо, я никогда не занимался таким.

тут та же ситуация?

Вроде того. Кому-то делать нечего, а кто-то хочет использовать проприетарное на основе LLVM и поэтому пытается собрать с помощью Clang.

Да, это

https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html

У меня нет идей, чем эта отладочная информация может быть полезна. Сравнение на примере вырожденного случая пустой программы:

# cat test.c
int main(void)
{
    return 0;
}

# gcc -fdump-tree-all=gcc-dump.log -o test test.c
# head -n 20 gcc-dump.log
;; Function main (null)
;; enabled by -tree-original


{
  return 0;
}
return 0;
@1      type_decl        name: @2       type: @3       chain: @4
@2      identifier_node  strg: int      lngt: 3
@3      integer_type     name: @1       size: @5       algn: 32
                         prec: 32       sign: signed   min : @6
                         max : @7
@4      type_decl        name: @8       type: @9       chain: @10
@5      integer_cst      type: @11     int: 32
@6      integer_cst      type: @3      int: -2147483648
@7      integer_cst      type: @3      int: 2147483647
@8      identifier_node  strg: char     lngt: 4
@9      integer_type     name: @4       size: @12      algn: 8
...

# clang -Xclang -ast-dump -c test.c
TranslationUnitDecl 0x7f9083014ce8 <<invalid sloc>> <invalid sloc>
|-TypedefDecl 0x7f9083015580 <<invalid sloc>> <invalid sloc> implicit __int128_t '__int128'
| `-BuiltinType 0x7f9083015280 '__int128'
|-TypedefDecl 0x7f90830155e8 <<invalid sloc>> <invalid sloc> implicit __uint128_t 'unsigned __int128'
| `-BuiltinType 0x7f90830152a0 'unsigned __int128'
|-TypedefDecl 0x7f90830158a8 <<invalid sloc>> <invalid sloc> implicit __NSConstantString 'struct __NSConstantString_tag'
| `-RecordType 0x7f90830156c0 'struct __NSConstantString_tag'
|   `-Record 0x7f9083015638 '__NSConstantString_tag'
|-TypedefDecl 0x7f9083015940 <<invalid sloc>> <invalid sloc> implicit __builtin_ms_va_list 'char *'
| `-PointerType 0x7f9083015900 'char *'
|   `-BuiltinType 0x7f9083014d80 'char'
|-TypedefDecl 0x7f9083019c68 <<invalid sloc>> <invalid sloc> implicit __builtin_va_list 'struct __va_list_tag [1]'
| `-ConstantArrayType 0x7f9083019c10 'struct __va_list_tag [1]' 1
|   `-RecordType 0x7f9083019a90 'struct __va_list_tag'
|     `-Record 0x7f9083019a00 '__va_list_tag'
`-FunctionDecl 0x7f9083019d88 <test.c:1:1, line:4:1> line:1:5 main 'int (void)'
  `-CompoundStmt 0x7f9083019ed0 <line:2:1, line:4:1>
    `-ReturnStmt 0x7f9083019eb8 <line:3:5, col:12>
      `-IntegerLiteral 0x7f9083019e98 <col:12> 'int' 0

Если ты посмотришь кто за него топит, то поймешь, главная фича, что это не богомерзкий GPL, посему основные сторонники Apple, BSD и пр

Она может быть полезна для анализа того, как компилятор переводит программу из одного абстрактного представления в другое, на каких стадиях и какие конкретно преобразования/оптимизации он выполняет.

Она может быть полезна для анализа того, как компилятор переводит программу из одного абстрактного представления в другое, на каких стадиях и какие конкретно преобразования/оптимизации он выполняет.

А она может отдать AST, чтобы можно было не пихать в cscope свой парсер C, а использовать результаты компиляции для навигации по коду?

А она может отдать AST, чтобы можно было не пихать в cscope свой парсер C, а использовать результаты компиляции для навигации по коду?

Не знаю, я над этим не задумывался. Ну наверное можно как-нибудь запатчить GCC, или парсить там что-то из диагностического выхлопа. Вообще-то это не задачи компилятора.

Да, GCC не задумывался таким модульным, в отличии от clang/LLVM. И что? Это еще совершенно не значит, что как компилятор он хуже. Вполне можно использовать какие-то кишки clang чтобы в IDE навигация работала, и тому подобное, но компилировать при этом через GCC, я в этом никакой проблемы не вижу.

Ну наверное можно как-нибудь запатчить GCC, или парсить там что-то из диагностического выхлопа.

Был уже такой проект, назывался gccxml. Но, к счастью, появился clang, и gccxml сдох.

Вообще-то это не задачи компилятора.

Тем не менее, это лучше всего реализуется именно в компиляторе. А если компилятор ещё и нормально разбит на компоненты (отдельный фронтенд, отдельный бэкенд), то это фактически ещё и бесплатно.

GCC не задумывался таким модульным

Ну то есть его не проектировали нормально, просто херак-херак на коленке, так?

Это еще совершенно не значит, что как компилятор он хуже.

Это значит, что сам GCC сложнее разрабатывать, а значит в нём больше вероятность багов. Что таки значит, что как компилятор он хуже.

Для меня – отсутствие необходимости иметь по сборке компилятора для каждой платформы.

В том что bsd-like лицензия.

чем clang лучше gcc

По практике сопровождения FreeBSD за 14 лет: Clang тормознее и жирнее GCC; Clang порождает менее оптимизированный код со своими странностями (глюками). GCC же простой как палка.

LLVM/Clang — это игрушка их создателей, «серебряная пуля», «универсальная модель компилятора», которая на практике представляет собой неповоротливую субстанцию, отвлекающую на себя довольно много человеческих ресурсов и внимания. Лично я предпочитаю инструменты, которые не замечаешь. LLVM/Clang/Rust — это сущее наказание.

Ад версий LLVM/Clang

> clang --version <системный компилятор>
FreeBSD clang version 10.0.0 (git@github.com:llvm/llvm-project.git llvmorg-10.0.0-0-gd32170dbd5b)
Target: x86_64-unknown-freebsd12.1
Thread model: posix
InstalledDir: /usr/bin

> pkg info -x llvm <версии llvm/clang, которые НУЖНЫ>
llvm80-8.0.1_3
llvm90-9.0.1_1

> pkg info -r llvm80 <издержки сговора между Intel и AMD>
llvm80-8.0.1_3:
	mesa-dri-19.0.8

> pkg info -r llvm90
llvm90-9.0.1_1: <нужен для сборки Firefox/Thunderbird>

Clang порождает менее оптимизированный код со своими странностями (глюками). GCC же простой как палка.

И тем не менее, это именно в gcc, начиная с как минимум 8 версии, есть тянущийся баг с кривыми дебаг-символами

GCC же простой как палка.

Смеялись всем шреддером. У GCC славная история генерации очень стремного кода, иногда приводящего к багам.

Не распарсил. Куда там смотреть?

Ужс.

Там условие в if 50 строк, с разными #ifdef

помимо того, что уже по делу написали KivApple и EXL, двойная сборка (двумя компиляторами) служит для своего рода верификации кода на портабельность. чтобы он случайно не привязался на GCC-specific фичи и был более свободным.

KDevelop

Сейчас не знаю, а раньше он запускал clangd, и очень медленно разбирал даже не очень большие проекты

Он запускает кланг в треде. Что ведёт к падению ИДЕ если падает парсер :)

Это про новые версии? Потому что в старых я не наблюдал падений из-за разбора проекта (только из-за плагина doxygen), а в последних да, при открытии проекта падает.

собственные парсеры поддерживают крупные компании Visual Studio

Intelli Sens или как его там, работает значительно медленнее, чем libclang, плюс есть ложное определение ошибок или не определение реальных ошибок. Это по наблюдениям на одном и том же cmake-проекте в QtCreator 4.12 и VS 2019

P.S. Поторопился отправить предыдущее сообщение, не дочитав весь коммент, а отредактировать уже не могу. Прости, что 2 раза притянул тебя

всего две. ты генту видел?

По практике сопровождения FreeBSD за 14 лет: Clang тормознее и жирнее GCC;

это правда.

Clang порождает менее оптимизированный код со своими странностями (глюками). GCC же простой как палка.

а вот это тот случай, когда трава у соседа зеленее. я лично читал, как Линус посылал в детский сад (или обозвал ретардед, уже не помню) девелоперов GCC 6.3.

вот чем-чем, а простотой GCC никогда не славился. наоборот clang появился, потому что в GCC никто не мог разобраться.

и кстати, раскрой мне секрет. я зарепортил сегфолт в базовой системе, чувак, который отвечает за баг, сначала отписался, а потом даже не подветрдил, что данных для фикса достаточно. когда теперь ждать работы по этому багу? месяц, два, три, полгода, год? на убунту я ждал 6 лет и закрыли с wontfix.

Тем не менее, это лучше всего реализуется именно в компиляторе.

А почему именно компиляторах? Может это лучше всего реализуется в статических анализаторах?

Ну то есть его не проектировали нормально, просто херак-херак на коленке, так?

Не знаю. Это ты уже у разработчиков GCC в мейл-листе можешь спросить, как его там проектировали. Может в то время это было не актуально, делать компиляторы модульными. Первый выпуск GCC был 22 марта 1987 года.

GCC was first released March 22, 1987, available by FTP from MIT.[13] Stallman was listed as the author but cited others for their contributions, including Jack Davidson and Christopher Fraser for the idea of using RTL as an intermediate language, Paul Rubin for writing most of the preprocessor, and Leonard Tower for «parts of the parser, RTL generator, RTL definitions, and of the Vax machine description.»

В те времена все эти практики грамотного проектирования могли еще быть не выработаны. Например, книга «Design Patterns» от банды четырех была опубликована только в 1995 году.

Это значит, что сам GCC сложнее разрабатывать, а значит в нём больше вероятность багов.

Не значит.

Что таки значит, что как компилятор он хуже.

Опять-таки, нет. Излишняя модульность тоже может быть проблемой и источником багов.

А почему именно компиляторах?

Потому что жизнь становится гораздо проще, когда у тебя всего один эталонный парсер языка. Особенно если это язык типа C++.

Излишняя модульность тоже может быть проблемой и источником багов.

Нет, если у тебя корректно описаны интерфейсы и взаимодействие.

Потому что жизнь становится гораздо проще, когда у тебя всего один эталонный парсер языка. Особенно если это язык типа C++.

Ну вот не факт. Парсер должен соответствовать некоей спецификации, описанной в стандарте. Где гарантии, что эталонный парсер языка точно соответствует этой спецификации? И почему бы не иметь несколько разных эталонных парсеров, написанных разными людьми на основе одного текста стандарта, и сравнивать их на предмет одинаковости их поведения?

Нет, если у тебя корректно описаны интерфейсы и взаимодействие.

Это опять-таки спорно. Как оценивать уровень корректности? И даже если всё корректно, есть ли строгие пруфы того, что модульность не мешает реализовывать некие нетривиальные фичи, и не усложняет код из-за необходимости делать всякие «места стыков» этих модулей, и что это всё не порождает неких багов?

Может надо провести некий научный эксперимент, ну скажем взять две группы программистов одинаковой квалификации, одну группу попросить с нуля написать свой компилятор в модульном стиле, другую в монолитном, а потом сравнить количество багов и время разработки. И при этом такой эксперимент проделать несколько раз. Вот тогда можно сделать какие-то выводы. А так - это просто слова.