История изменений

Как мне ответил их представитель на Хабре «У нас куча специалистов и куча опыта написания всякого рода парсеров. Поэтому всё будет хорошо». Я спрашивал, почему не используют libclang++, чтобы получить доступ к AST дереву - свой парсер не пришлось бы велосипедить, да и поддержка языка быстрее появляется. На что ответ был такой:

Давайте по порядку.

Во-первых, этот ишью не про то. А про интеграцию clang анотатора. То есть, чтобы ошибки, которые умеет детектить clang, показывать как часть встроенных code inspections. Так в AppCode сейчас сделано для Objective-C и для Swift (там SourceKit).

Во-вторых, про clang парсер. Мы бы и рады не писать велосипед, но к сожалению, в текущем состоянии clang не подходит, чтобы решить все задачи, которые IDE ставит парсеру. Почему? IDE должна работать с некорректным и неполным кодом, то есть в отличие от парсера должна восстановить дальнейший парсинг после нахождения ошибки. У IDE и компилятора разные требования к знаниям о путях, по которым находятся те или иные сорс-файлы (у компилятора они ниже). IDE необходимо знание о всем проекте. Например, чтобы иметь рефакторинг, который работает на всем проекте, а не только на открытом файле, нужен project-wide кэш символов. Все это добро должно работать инкрементально, чтобы IDE имела приемлемую производительность.

Наверное, если бы мы несколько лет назад начали работу именно с того, что допилили в clang все, чего нам не хватает, это бы решило проблему (хотя у нас нет четкой уверенности, что там легко можно все нужное реализовать — мы честно изучали вопрос). Но тогда clang еще был слишком молод. Сейчас он гораздо более «дружелюбен» к IDE, конечно.

В тоже время, у нас в компании накоплена 16-летняя экспертиза по написанию такого рода инструментов, есть архитектура, в которую наше решение встраивается легко и команда, которая с интересом этим занимается (и при этом следит за развитием clang-а и clang-based инструментов).

Надеюсь, что смогла ответить на ваш вопрос.

То есть мало того, что идея тормозит по крайней мере в Clion именно во время работы их парсера, так они даже и не будут пытаться встраивать libclang++. Я понимаю, что это сложно, но всё же.

Как мне ответил их представитель на Хабре «У нас куча специалистов и куча опыта написания всякого рода парсеров. Поэтому всё будет хорошо». Я спрашивал, почему не используют libclang++, чтобы получить доступ к AST дереву - свой парсер не пришлось бы велосипедить, да и поддержка языка быстрее появляется. На что ответ был такой:

Давайте по порядку.

Во-первых, этот ишью не про то. А про интеграцию clang анотатора. То есть, чтобы ошибки, которые умеет детектить clang, показывать как часть встроенных code inspections. Так в AppCode сейчас сделано для Objective-C и для Swift (там SourceKit).

Во-вторых, про clang парсер. Мы бы и рады не писать велосипед, но к сожалению, в текущем состоянии clang не подходит, чтобы решить все задачи, которые IDE ставит парсеру. Почему? IDE должна работать с некорректным и неполным кодом, то есть в отличие от парсера должна восстановить дальнейший парсинг после нахождения ошибки. У IDE и компилятора разные требования к знаниям о путях, по которым находятся те или иные сорс-файлы (у компилятора они ниже). IDE необходимо знание о всем проекте. Например, чтобы иметь рефакторинг, который работает на всем проекте, а не только на открытом файле, нужен project-wide кэш символов. Все это добро должно работать инкрементально, чтобы IDE имела приемлемую производительность.

Наверное, если бы мы несколько лет назад начали работу именно с того, что допилили в clang все, чего нам не хватает, это бы решило проблему (хотя у нас нет четкой уверенности, что там легко можно все нужное реализовать — мы честно изучали вопрос). Но тогда clang еще был слишком молод. Сейчас он гораздо более «дружелюбен» к IDE, конечно.

В тоже время, у нас в компании накоплена 16-летняя экспертиза по написанию такого рода инструментов, есть архитектура, в которую наше решение встраивается легко и команда, которая с интересом этим занимается (и при этом следит за развитием clang-а и clang-based инструментов).

Надеюсь, что смогла ответить на ваш вопрос.