company_banner

Все, что вы давно просили, в одном релизе — CLion 2018.2

    Привет, Хабр!

    Не знаем, насколько жарко у вас за окном, но у нас в JetBrains эти недели точно жара — релизная. Одну за другой мы опубликовали обновленные версии 2018.2 почти всех наших инструментов на базе платформы IntelliJ: WebStorm, IntelliJ IDEA, PyCharm, DataGrip, GoLand, PhpStorm, RubyMine и CLion.

    Для команды CLion этот релиз особенный, так как включает в себя результаты нашей работы по трем очень важных направлениям:

    1. Clangd как основа для нового экспериментального движка для разбора кода на C++.
    2. Улучшения производительности IDE за счет новых архитектурных решений.
    3. Новые проектные модели, поддерживаемые в CLion.

    А также поддержка Google Sanitizers, возможность пересборки отдельного файла и многое другое!

    image

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

    Clangd для парсинга кода на C++ в CLion


    Еще в марте мы рассказали вам, что рассматриваем различные альтернативные варианты языкового движка для CLion. Это и понятно — хочется и принципиально улучшить поддержку текущих языковых возможностей, и быстрее добавлять свежие фишки C++, и писать больше крутых и специфичных для C++ рефакторингов и пр. Для всего этого нужен точный и быстрый парсер кода.

    Мы продолжаем улучшать наш текущий парсер, методично вытравливая разнообразные ошибки и недочеты. А в дополнение мы решили попробовать сделать еще один языковой движок на базе clangd (это такая реализация LSP протокола для clang).

    Если сразу переходить к результатам — в CLion 2018.2 в дополнение к основному языковому движку работает еще и новый, экспериментальный, на clangd. Мало того, мы так осмелели, что включили его по умолчанию на Linux и macOS. На Windows, к сожалению, обнаружилась неприятная особенность работы clangd с памятью, и мы по умолчанию выключили новый движок на этой платформе (но с высокой вероятностью это будет исправлено уже в первых минорных обновлениях на версию 2018.2).
    Включить/выключить экспериментальный парсер кода на основе clangd можно в настройках Settings/Preferences | Languages & Frameworks | C/C++ | Clangd:

    image

    Важно понимать:

    • Парсер кода на основе clangd работает в параллели с собственным парсером CLion.
    • Clangd используется только для показа ошибок и предупреждений в редакторе. Для всего остального (включая рефакторинги, исправления ошибок (quick-fixes), навигацию, автодополнение и пр.) используется собственный парсер CLion.
    • Конфигурация ошибок и предупреждений Clang по умолчанию специально подобрана так, чтобы показывать довольно много предупреждений о потенциальных ошибках, но при этом не противоречить тем инспекциям кода, которые работают в CLion на базе собственного парсера кода и включены по умолчанию.

    Предупреждая ваши вопросы, сразу скажу, что да, мы планируем пробовать переводить другие умные возможности IDE на clangd, но сначала надо стабилизировать текущее решение, провести еще множество тестов и решить множество сложных и принципиальных вопросов на этом пути.

    Новая проверка для кода на C++


    Когда функция принимает несколько параметров одинакового типа, бывает легко ошибиться и незаметно для себя (и компилятора) поменять местами аргументы одного типа при вызове этой функции. Такие ошибки тяжело отлавливать, а значит их стоимость высока. Но в CLion 2018.2 мы реализовали новую проверку кода (inspection) специально для таких случаев. Она использует эвристический алгоритм для анализа имен параметров и аргументов функции и способна обнаружить ситуации, когда порядок аргументов ошибочно изменен:

    image

    Важно:

    • Чтобы избежать ложных срабатываний, алгоритм отключается автоматически для очень коротких имен (менее 3 символов).
    • По тем же причинам алгоритм отключается для функций, названия которых содержат подстроки swap/inverse/rotate/backward/flip.
    • По ряду технических причин инспекция работает только при включенном экспериментальном парсере кода на clangd и к тому же только при включенном анализаторе кода clang-tidy через clangd (это все в настройках упомянутых выше Settings/Preferences | Languages & Frameworks | C/C++ | Clangd).

    Производительность IDE


    В этом релизе мы целенаправленно изводили подвисания IDE (UI freezes) в целом ряде случаев: при автодополнении, в поиске Search Everywhere, в навигации на связанный символ (которая как правило используется для переключения между исходным файлом и заголовочным и обратно), при использовании хлебных крошек (breadcrumbs) для навигации. Первые пользователи релиза, а также многочисленные участники нашей программы раннего доступа (Early Access Program) уже оценили улучшения и подтверждают, что поведение IDE существенно улучшилось, а подвисаний стало значительно меньше. Работа в этом направлении будет продолжена и в 2018.3.

    К тому же, мы перевели встроенный форматтер кода на лексер. Конечно, при работе через парсер (как раньше) его результат более точен, но вот время работы значительно увеличивается. А так как форматирование кода в CLion происходит в тот момент, когда вы печатаете код, подвисания тут могут очень негативно отражаться на общем впечатлении о скорости работы IDE. Отзывчивость редактора падает, подвисания становятся заметными и так далее.

    Форматтер на лексере работает довольно аккуратно, но если вы все же испытываете проблемы с форматированием на вашем коде, то во-первых, обязательно расскажите об этом нам, а во-вторых, вы всегда можете переключиться на более медленный, но и более точный форматтер на парсере — для этого есть опция cidr.indent.lexer.only.cpp в Registry.

    Новые проектные модели: Gradle C++ и compilation database


    До 2018.2 были следующие способы открыть проект в CLion:

    • Открыть CMake проект.
    • Открыть файл или целую папку, не имеющую CMake-файлов. При этом многие умные функции по работе с кодом окажутся отключены.
    • Для кода на Rust при использовании Rust плагина в CLion можно использовать Cargo.
    • Воспользоваться сторонним плагином к CLion для открытия проекта на Bazel.

    К этому списку в 2018.2 мы добавили две новые опции:

    • Открыть проект на Gradle, указав IDE местоположение файла build.gradle. Обращаем внимание, что CLion сейчас поддерживает только новый Gradle формат для проектов на C++:
      image
    • Открыть проект из compilation database, указав IDE местоположение файла compile_commands.json. Пока что в данном случае невозможна сборка и запуск проекта из CLion, так как compilation database не содержит информации о сборке проекта целиком.

    Но в обоих случаях, как Gradle, так и compilation database, все умные функции по работе с кодом доступны! И кстати, опция compilation database интересна тем, что фактически теперь какой бы ни был у вас проект — Makefiles, Ninja, Qbs, любая ваша специфическая проектная модель — вы можете сгенерировать compilation database для вашего проекта и открыть его в CLion!

    А мы тем временем продолжаем работу над API для добавления поддержки новых проектных моделей в CLion!

    Улучшения CMake


    Кое-какие важные улучшения были сделаны и для CMake проектов. Самое главное – если ваши заголовочные файлы, расположенные внутри директории вашего проекта, используются в файлах проекта и подключены через директиву #include, их больше не надо явно перечислять в CMake скриптах! CLion теперь сам пометит их как проектные, и все умные функции вроде рефакторингов и автодополнения будут доступны в таких файлах:

    image

    Второе важное улучшение связано с настройкой внешних инструментов (external tools), которые можно затем вызывать как самостоятельно по команде, так и делать частью конфигураций запуска приложения. В них теперь доступны макросы, содержащие всяческие CMake переменные. Например, директория сборки или имя исполняемого файла:

    image

    Инструменты для динамического анализа кода


    Для Valgrind Memcheck, поддержанного в CLion еще в версии 2017.3, появилась возможность экспортировать и затем импортировать обратно результаты анализа:

    image

    Также в этой версии в CLion появилась поддержка другого инструмента для динамического анализа кода — Google Sanitizers. Для их включения нужно явно указать специальный ключ -fsanitize в CMake скриптах вашего проекта, и тогда, в случае использования Clang версии не менее 3.8.0 или GCC версии не менее 5.0.0, CLion сможет автоматически обнаружить использование sanitizers и показать результаты их работы в специальном окне:

    image

    В нем можно просматривать не только список найденных ошибок, но и исходный код (и навигироваться на него), изучать информацию о фрейме, смотреть трассу ошибок. Более подробно про поддерживаемые sanitizers и настройки в CLion читайте в нашем блог посте на английском.

    Пересборка одного отдельного файла


    Для проектных моделей CMake и compilation database в CLion 2018.2 есть возможность пересобрать один файл, не вызывая пересборку всего проекта. Для этого есть действие в меню Run — Recompile, или можно воспользоваться комбинацией клавиш Shift+Ctrl+F9 на Linux/Windows, ⇧⌘F9 на macOS (в раскладках по умолчанию):

    image

    Данная возможность — отличный способ быстро проверить, что ваши текущие изменения в файле не сломали сборку всего проекта. Если интересны детали, какая именно команда компиляции вызывается и как выбирается тип сборки, можно почитать подробно в нашем блоге.

    Базы данных


    По результатам нашего опроса в Twitter, многие пользователи CLion обращаются к тем или иным базам данных при разработке проекта на C/C++. Поэтому с этого релиза в нашу IDE включен плагин для работы с базами данных и кодом на SQL. Он является полным функциональным аналогом нашей среды для работы с базами данных — DataGrip. Так что вот этот пост здесь на Хабре от moscas про нововведения в DataGrip 2018.2 вам тоже может быть интересно почитать.

    И это еще не все!


    Коротко о других улучшениях:

    • Мы забандлили новую версию отладчика LLDB 6.0 и новую версию CMake 3.12.
    • К тому же в случае GDB CLion научился использовать pretty-printers для типов при показе указателей на переменные данного типа.
    • Для WSL поддержаны фоновые процессы, что значительно облегчает запуск всей конфигурации CLion с WSL.
    • Из IntelliJ-платформы CLion получил ряд улучшений в поддержке систем контроля версий, на платформе macOS поддержку MacBook Touch Bar и более темные заголовки окон, к тому же обновился весь ряд иконок в интерфейсе IDE.

    Традиционное видео о новых возможностях CLion 2018.2 на английском языке от нашего девелопер-адвоката:


    И кстати, до среды, 1 августа 2018, 19:05 по Москве (GMT+3), мы дарим скидку 50% на все продукты JetBrains Toolbox.

    Вопросы? Будем рады ответить в комментариях!

    Ваша команда JetBrains CLion
    The Drive to Develop

    JetBrains

    376,00

    Делаем эффективные инструменты для разработчиков

    Поделиться публикацией

    Похожие публикации

    Комментарии 63
      0

      По поводу новой фичи Clangd: он у меня течёт в sles, так что пришлось отключить.
      Касательно производительности: на больших файлах всё ещё лютые фризы, надеюсь поправите к следующему релизу.

        0
        А можно чуть больше деталей про утечки: suse linux? Как именно видно утечки, какие логи/дампы смотрите? Какие-то конкретные сценарии работы с IDE при этом или просто открываете проект и более особо ничего? Движок на clangd пока экспериментальный, ваш репорт будет очень полезен, наверняка мы что-то упустили.

        Про фризы — вы CPU снэпшоты нам не репортили? Просто понять, это что-то новое или просто еще непофикшенное старое. Если репортили, можно номер тикета напомнить.
          0

          К сожалению, сейчас нет доступа к машине и проверить подробности утечки не могу. Помню что через несколько сборок проекта (через make) cland начал есть слишком много памяти. Отключение помогло.
          Фризы точно не новые, потому что мучаемся с этим достаточно давно. Репорты емнип не отправляли, ибо там похожих тикетов и так много. Файл большой (30к строк), может проблема в макросах.

            0
            А «слишком много» — это сколько? И что при этом открыто в редакторе? Попробую пояснить вопрос — 1.5-2Гб в некоторых случаях, при нескольких больших открытых файлах в редакторе, это норма.
              0
              ~1гб, но этого оказалось достаточно, чтобы забить до упора память моей машины.
              > при нескольких больших открытых файлах в редакторе
              Проект как раз был небольшой, и файлов крупных не было. Максимум 500 строк.
                0
                А заголовочные файлы большие/много?
                  0
                  Инклюдов прилично (llvm, clang-lib), считаете в этом дело? Если так, то 2гб «хватит всем»?
                    0
                    Возможно. А проект случайно не OS? Посмотреть не получится?

                    В целом, стоит понять, там память течет или ее просто (почему-то) много требуется для работы clangd. К сожалению, в экспериментальной версии пока не много вариантов посмотреть какие-то логи и всякую отладочную инфу. Завтра командой подумаем, как вообще нам такое более удобно диагностировать и какие логи от вас нам могут помочь.
        +1
        Чтобы избежать ложных срабатываний, алгоритм отключается автоматически для очень коротких имен (менее 3 символов).

        А можно все же включать для переменных с названиями типа
        vx, vy, vz
        x1, x2, x3
        ?

        Например, если имя переменной соответствует (.+)[xyz]|[xyz](.+)?
          0
          Можно, наверное, но логика эвристик очень сильно усложнится или будет много ложных срабатываний. Так что пока выключены такие ситуации. Мы обсудим, спасибо!
            0
            Или можно добавить это в настройки.

            В любой непонятной ситуации добавляй крутилку в настройки!
              +1
              В любой непонятной ситуации добавляй крутилку в настройки!
              Как показывает практика — это не работает. Ибо очень, очень мало людей трогают настройки если и без этого «всё работает».
          0
          Планируется ли что-то делать с инспекциями кода, а точнее с тем, что на больших файлах (да практически любой файл из LLVM) во время запуска инспекций кода помечается как «Too complex». Особенно заметно на больших header-only библиотеках. Тикет в багтрекере висит, но непонятно, планируется ли это фиксить.
            0
            Планируется, конечно) Если коротким ответом.

            Если чуть более вдаваться в детали, то такая ошибка выдается вполне конкретной инспекцией, а не всеми, – Data Flow analysis. Ее можно отключить, если ошибка сильно мешает.

            Но вообще DFA правда может быть очень сложным. Хотя, конечно, бывает, что просто из-за проблем в парсере такая ошибка в инспекции. Проблемы парсере — у нас в приоритете, но за этой ошибкой too complex может скрываться столько разных случаев / причин / проблем, что вот взять и починить все и сразу пока не получается.
              0
              Ну просто насколько я помню в тикете отписали, что там есть какие-то ограничения движка. Если отключаете проверку из-за того, что проверка может занимать слишком много времени, то я бы согласился на Opt-In опцию с предупреждением, что это может сильно замедлить анализ. Так как вполне вероятно, что у меня на компьютере довольно неплохой процессор с достаточным даже для CLion обьёмом оперативной памяти, что я готов пойти на такие жертвы ради инспекций :-)
                0
                Дело не во времени анализа. Too complex означает, что CLion не смог провести DFA из-за сложности кода. Если видите такое уведомление, это как раз и есть предупреждение, что может надо отключить инспекцию.
            0
            Анастасия, а можно чуть подробнее о причинах побудивших задействовать clangd?
            Спрашиваю потому, что давным-давно (кажется в FB) я советовал вам идти этим путем, а вы не соглашались…
              +2
              Не совсем правда, что мы не соглашались.
              1. Мы всегда говорили, что есть причины, почему clang не был выбран изначально (исторические платформенные ограничения).
              2. Есть (до сих пор) сомнения, что на clang можно решить все необходимые для IDE задачи, потому что это компилятор и он архитектурно предназначен для других задач.
              3. Не понятно пока, получится ли на нем сделать global refactorings и прочие умные штуки на всем проекте, а если и получится, то будет ли это достаточно быстро работать.

              Но мы в общем то никогда не скрывали, что смотрим на разные другие решения для парсера и clang одно из них.
              А сейчас просто нашлись ресурсы, чтобы этим заниматься. + Пришло понимание, как бы подружить clang и нашу платформу. + Мы научились дружить clangd и наш собственный парсер, чтобы они работали одновременно и не мешали друг другу. В общем сложилась благоприятная обстановка, чтобы что-то реально попробовать и показать пользователям. Надеемся, что получилось неплохо.
              Насколько это экспериментальное решение станет постоянным, я пока не могу сказать. Время покажет.
                0

                cquery рассматривали как вариант?

                  0
                  Мы много чего рассматривали как варианты. До серьезного рассмотрения и proof of concept дошли не многие опции)
                  0
                  А что вы думаете про Language Server Protocol в целом?
                    +1
                    Слишком общий вопрос) Штука хорошая, а насколько применима будет успешно в наших условиях — зависит от того, что мы от LSP ожидаем. С clang было решено работать через clangd/LSP, в общем же LSP в CLion никто пока не обсуждает.
                  +2
                  Для того, чтобы эффективно использовать clang в IDE (как парсер) — clang надо правильно готовить и патчить. Как правильно написала Анастасия, кланг — это, в первую очередь, компилятор. И ведёт он себя с кодом как компилятор, а не как IDE — более строго. И работает он, мягко скажем, не быстро. А чтобы заставить работать быстро — надо колдовать. Да и после колдовства (если не лезть глубоко в реализацию парсера) некоторые фишки просто не будут работать. Например, о фичах типа «создать декларацию функции из определения» или «создать декларацию из использования» можно будет забыть — кланг для таких кусков кода просто не построит адекватную AST (код для него, как компилятора, будет невалидный). Про адекватную работу код-коплита внутри шаблонов тоже можно будет забыть, передав привет двухфазному парсингу. В общем, дружить clang и IDE — весело. И больно.
                  0

                  Обновился, радуюсь. Вопрос возник по выравниванию кода после вложенных циклов.
                  Пишу что-нибудь такое


                      for (int i = 0; i < 2; ++i)
                          for (int j = 0; j < 3; ++j)
                              for (int k = 0; k < 3; ++k) {
                                  int s1 = i * i;
                                  int s2 = j + k;
                              }
                              std::cout << "incorrect indentation\n";

                  и после этого выравнивание идет по закрывающей фигурной скобке. Code->Reformat Code приводит все в порядок, то есть строка после цикла будет с тем же отступом, что и внешний for. Вставка пустой строки не помогает.

                    0
                    Похоже на багу. И кажется, оно так работало и в форматере на парсере, и в новом форматере на лексере( Занесли в трекер OC-17542
                    0
                    Я не знаю как правильно сформулировать вопрос, по этому попробую описать ситуацию…
                    Существует разрабатываемый энтузиастами плагин для IDEA I-Pascal, для поддержки языка pascal соответственно. При этом он строится на проектной (модульной) модели IDEA. Но на самом деле проекты pascal очень близки по своей структуре к C++. В них включенные в проект файлы определяются файлом системы сборки, там же указываются дополнительные зависимости, параметры. В Pascal так же активно применяется препроцессор (не такой функциональный как c++, но так же влияющий на поведение кода, его разбор, анализ и рефакторинг).
                    Сейчас вы активно развиваете проектную модель и я хотел бы спросить — попадут ли эти наработки в основную IDEA и станут ли доступны для написания языковых плагинов к языкам с похожим поведением? Конкретно — построение структуры проекта из условной сборочной системы и обслуживание препроцессора?
                      0
                      Пока не знаю, что Вам ответить. Это две разные задачи — сделать API для проектных моделей в CLion и перенести его в IntelliJ IDEA (тут просто исторически CLion отдельно развивается, поэтому это не просто). Но если, например, делать плагин из CLion к IntelliJ IDEA, то придется в любом случае переносить. Так что есть такая вероятность. А вот каких-то оценок по времени скорее нет.
                        0
                        Я правильно понимаю, что CLion функциональность не доступна из Idea в виде плагина (т.е. ситуация ближе к .NET/Rider чем, например к go/javascript?).
                          0
                          CLion действительно существует только как отдельная IDE, а как плагин — нет. Это не то, чтобы принципиальная позиция. Просто так сложилось исторически, а сейчас кажется не самой приоритетной задачей, при том, что технических вопросов/сложностей там много, а ресурсы ограничены.
                            0
                            Позиция понятна и мне кажется разумной. Пусть уж лучше будет один хороший продукт для работы с C++ чем два плохеньких. Просто хотелось уточнить. Спасибо за ответ.

                            Кстати еще вопрос. Последний раз когда пробовал что-то делать с Arduiono в Clion — интеграция была слабовато. Есть ли это направление в каких-нибудь roadmaps?
                              0
                              Embedded направление достаточно приоритетно. Но конкретных задач пока не поставлено, там сначала надо решить пачку общих задач по отладчику: memory view сделать (он в процессе), hex view переделать (текущее решение нам не очень нравится и потому по умолчанию не включено), и тп.

                              Люди вроде пользуются Platform.io вполне успешно для Arduino + CLion. Там есть некоторая интеграция.
                      0
                      Существует средний-большой проект с многими десятками Makefiles, вызывающие друг-друга и с десятками способов/параметров как его строить на все случаи жизни. Менять их на Cmake никто не собирается, т.к. все работает, а Cmake у нас никто не знает.

                      Импортирую новый не-Cmake проект, как советует документация, создается cmakelists; попробовал также compilation database. В обоих случаях все вроде работает (ок, не могу скомпилировать изнутри, пишу руками «make ...» в шеле, переживу, потом добавлю макро). Рефакторинг и навигация вроде работают, и уже хорошо. Довольный иду домой.

                      На следующий день обновляем репу и видим, что коллеги за ночь добавили Х новых директорий и файлов с кодом. В уже созданный cmakelists они сами не попадают и clion начинает грязно ругатся на код который иx использует, не находит новые инклюды итд.
                      (Вроде в 2018.2 хотя-бы инклюды вроде должны были работать? Или только из уже известных директорий?)

                      Как вы предлагаете работать в таком случае?

                      После каждого git pull импортировать проект с начала, стирая старый cmakelists?
                      Вручную добавлять новые директории каждый раз, выискивя их по одной?
                      Всегда гнатъ make с генерацией новой compilation database и опять открывать по-новой?

                      Вы понимаете, что все эти методы не масштабируются и уважающие свое время люди не будут это все время делать?
                      Я пропустил какой-то метод работы с такими проектами, который все таки оправдает переход на clion?

                      Если способ есть, рекомендую подробно описать его в доках, т.к. терпение и время находить его самим есть не у всех. Я, например, пока что плюнул и вернулся к бесплатному эклипсу, который сам находит все изменения (у эклипса свои проблемы, конечно).
                        +1
                        Я пропустил какой-то метод работы с такими проектами, который все таки оправдает переход на clion?
                        Да, пропустили. Потому что это не в CLion'е должно быть.

                        У нас, к примеру, вообще своя собственная распределённая система сборки. Нужно было всего лишь научить её порождать CMake-проекты и поддерживать их и всё. Но это только вы можете сделать.

                        Если у вас Makefiles вообще без всяких ограничений, то это, строго говоря, не делается в принципе: Makefile в принципе не даёт ответа на простой вопрос «а какие, собственно, файлы входят в ваш проект».

                        Но в это я не верю. Обычно в проекте есть какая-то дисциплина, которая позволяет сделать соотвествующий конвертор.

                        А вообще, похоже, CMake — это будущее. Уже и Visual Studio с ними научился работать и даже поверх них свою систему управления пакетами получил и всякие проекты нативно его поддерживают. Так что учить придётся.

                        Мне лично немного грустно, так как CMake — тот ещё кусок… добра. Но лучше уже CMake через разброд и шатание, когда в каждом проекте своя система сборки.

                        Я, например, пока что плюнул и вернулся к бесплатному эклипсу, который сам находит все изменения (у эклипса свои проблемы, конечно).
                        К эклипсу у нас тоже плагин, так как его способность находить изменения… ограничена, да…
                          0
                          Все верно, но «все работает и так», значит пока менять систему сборки никто не будет. Мой вопрос был с позиции, что такой раскад — аксиома, и в данном проекте не меняется.
                          Я не говорил, что согласен с этим — но тут так заведено ©.

                          Makefiles вполне (иногда — на основании параметров командной строки) определяют какие файлы когда использовать для билда, а также из какой суб-директории брать версию под конкретную железку.
                          И я не говорил, что эклипс все правильно парсит — но он смотрит, как я понимаю, на все дерево и пытается резолвить из всех файлов вообще.
                            0
                            И я не говорил, что эклипс все правильно парсит — но он смотрит, как я понимаю, на все дерево и пытается резолвить из всех файлов вообще.
                            Правильно. Но в нашем случае он пытается затащить себе все исходники всего-всего-всего, несколько часов грузит всё это, сжирает 64GB оперативки и умирает.

                            Так что в любом случае нужен плагин.
                              0
                              Все верно (правда иногда спасают фильтры директорий).
                              Но это — в корпоративный блог Эклипса :-)
                              А тут мы хотим что-то лучше, чем эклипс.
                                0
                                А тут мы хотим что-то лучше, чем эклипс.
                                Что лучше, чем экслипс — это среда, понимающая разные види проектов. CMake, Automake, Bazel, etc.

                                Но «голый» make — слишком низкоуровневая штука, чтобы оттуда выудить нужную информацию…
                          +1
                          Начнем с вводной, что CLion для работы всегда нужна хоть какая-то проектная модель, описывающая проектные файлы, связи между ними, флаги там всякие и пр. Вся эта информация нужна для резолва. Поэтому в целом, конечно, ситуация, что используется проектная модель А, а для CLion из нее генерируется проектная модель B, и при этом другие члены команды в проектную модель А часто вносят значительные изменения она не самая удобная. В проект ведь могли добавить каких-то новых файлов, никак не связанных и не используемых в предыдущих, новых флагов, и пр. и IDE надо об этом как-то узнать. То есть такие изменения должны отразиться в проектной модели B.

                          Теперь больше конкретики по вопросам:

                          На следующий день обновляем репу и видим, что коллеги за ночь добавили Х новых директорий и файлов с кодом. В уже созданный cmakelists они сами не попадают и clion начинает грязно ругатся на код который иx использует, не находит новые инклюды итд.
                          (Вроде в 2018.2 хотя-бы инклюды вроде должны были работать? Или только из уже известных директорий?)

                          Если новые директории попали под project root и если новые файлы включены в старые (которые уже расцененные CLion-ом как проектные) файлы посредством директивы include, то новые файлы будут расценены как проектные автоматически. Все должно работать в такой ситуации. Если это не так — это бага, пишите тикет в наш трекер. Мы вот только что попробовали у тебя добавить новую директорию с файлами под project root — все заработало и для CMake, и для compilation database.

                          Compilation database при этом кажется более легко поддерживаемым и точным способом получения допустимой CLion-ом проектной модели, чем Import Project, который генерирует CMake проект. Мы к тому же думаем, как инкрементальный аптейт в его случае ускорить.
                            0
                            Спасибо за ответ, попробую в следущий раз отловить больше подробностей.

                            Compilation database при этом кажется более легко поддерживаемым и точным способом получения допустимой CLion-ом проектной модели, чем Import Project, который генерирует CMake проект. Мы к тому же думаем, как инкрементальный аптейт в его случае ускорить.
                            т.е. вы да предлагаете
                            Всегда гнать make с генерацией новой compilation database и опять открывать по-новой?
                            Попробую понятъ или так можно работать постоянно…

                            Вопрос о теории авто-резолва:

                            Если начали с:
                            project123
                            ....src
                            ........dir1
                            ............file11.c
                            ............file11.h

                            Это попало в CLion.
                            Потом репа обновилась до:
                            project123
                            ....src
                            ........dir1
                            ............file11.c
                            ............file11.h
                            ............file12.c
                            ............file12.h
                            .......dir2
                            ............file21.c
                            ............file21.h

                            Также старый file11.c заинклюдил новые file12.h и ../dir2/file22.h

                            Как я понимаю, все 3 .h файла найдутся и распарсятся? или file21.h не найдут, ибо из неизвестной директории?
                            А как насчет новых file12.c и dir2/file21.c?
                            dir2 не под project root, а глубже — значит его содержимое без моей помощи (или нового Compilation database) никогда не найдут?
                            Мне кажется, поиск новых директорий и файлов должен быть рекурсивным всюду, а не только из project root. Есть причины так не делать?
                            (можно добавить диалог со списком ново-найденного, где можно выбрать что взять в проект, а что выкинуть; результат выбора где-то запомнить, чтоб не спрашивать в следующий раз; я не утверждаю, что это легко хорошо сделать :-))
                              0
                              Поиск, конечно, рекурсивный, по файлам в дереве под project root. Все должно находиться в вашем случае.
                              Не найдутся те файлы, которые за пределами дерева под project root. Это как раз специально, чтобы не лезть с рефакторингами во всякие библиотеки, которые где-то сбоку проекта лежат.
                                0
                                Согласен.
                                Проверю, у меня сложилось впечатление, что именно в похожем случае не нашлись новые файлы овсем. Если повторю, открою баг.
                                Спасибо!
                                  0
                                  Хорошо бы пример нам показать. Может, я что-то упускаю в вашей конфигурации.
                                    0
                                    Без проблем, как только индусы коллеги накоммитят еще, проверим. Возможно я ошибся, или не дождался пока все распарсится в тот раз.
                                    Файле никакие прислать не смогу, все секретно. Но если удастся повторить на синтетическом примере — пожалуйста.

                                    Другой вопрос: сделал Compilation database для двух разных проектов. Оба открылись в CLion, но в одном все файлы показаны, как в оригинальном дереве (как надо), а в другом — все в одном длинном однородном списке (== невозможно ориентироватся и не понятно как и где потом можно создавать новые).
                                    В обоих проектах файлы сидят в похожих, достаточно глубоких структурах директорий (т.е. принципиальную разницу не вижу).

                                    Думаю, виноваты разные стили Makefiles (а не CLion). Есть идеи на что где смотреть, чтобы это починить? Я пропустил какую-то опцию CLion чтоб он сам файлы как-то рассортировал по path?
                                      0
                                      Попробуйте изменить project root.

                                      Например,
                                      Если у меня структура:
                                      папка 1
                                      … файлы проекта
                                      … папка 2
                                      ........compilation database
                                      и файлы проекта в папке 1, а json файл, который я открываю в папке 2, то все файлы окажутся в одном длинном списке и CLion будет считать именно папку 2 (где лежит compilation database файл) проектным рутом. Tools | Compilation Database | Change project root, указываем папку 1 и наступает счастье.

                                      Похоже на ваш случай?
                                        0
                                        Точно, он самый, спасибо!
                                        Вот это тех. поддержка :-)
                                        Думаю, стоит добавить замечание об этом в доки. Там уже написано как менять project root, но не написано зачем это надо.
                                          0
                                          Спасибо, я передам техническому писателю ваш комментарий.
                            +1
                            Кстати, тут наш технический писатель, отчасти по мотивам этого треда, написала вот такой полезный пример: www.jetbrains.com/help/clion/using-file-watchers.html#CompDBExample
                              0
                              Да, полезно, рекомендую всем. Еще появилась подробная статья (на английском) про работу с Makefile проектами при помощи Compilation Database:
                              blog.jetbrains.com/clion/2018/08/working-with-makefiles-in-clion-using-compilation-db.

                              Что-бы строить проект, добавляем External Tool с, в котором даем командную строку нашего make, добавляем туда Output Filter, чтобы ошибки подчеркивались (и по ним можно было переходить на нужную строчку в файле с ошибкой), уговариваем наш компилятор выдавать ошибки с полным путем до файлов (например, "-fdiagnostics-absolute-paths" для clang), т.к. при дефолтном относительном пути CLion [пока?] не может найти их сам (https://youtrack.jetbrains.com/issue/IDEA-197135), если проект на Compilation Database.
                              Теперь, если не забывать делать ״Tools->Compilation Database>Reload Compilation Database Project״ при каждом значительмом изменении структуры проекта, уже можно работать.

                              Возможно не помешает статья с переводом той статьи на русский (можно даже с моими добавками про External Tool выше) — если кого-то еще это интересует.
                                0
                                Теперь, если не забывать делать ״Tools->Compilation Database>Reload Compilation Database Project״ при каждом значительмом изменении структуры проекта, уже можно работать.

                                Вроде почти запилили автоматический reload. Попробуем после тестирования померджить в 2018.2. Но в 2018.3 уже точно появится!
                            0
                            Ну не все же, что просили :)
                            Жду с нетерпением эту задачу
                            youtrack.jetbrains.com/issue/CPP-744
                              0
                              Это в процессе. Думали успеть прототип показать в 2018.2, но не успели. Целимся в 2018.3 сейчас
                              0

                              Нет в жизни счастья, с одной стороны clion с rust плагином, с другой qt creator с поддержкой .ui файлов, qt документации и стилей из clang-format

                                0
                                Кстати про Rust обновление мы отдельный пост написали.

                                qt документации

                                В смысле именно по Qt встроенная документация?

                                стилей из clang-format

                                Это мы давно планируем сделать. Может, в 2018.3 что-то успеем.
                                  0
                                  В смысле именно по Qt встроенная документация?

                                  Да, документация пример которой можно увидеть здесь: http://doc.qt.io/
                                  Поставляется с Qt (для linux часто отдельным пакетом), ее можно посмотреть
                                  либо в отдельном приложении (Qt assistant) или просто нажав F1 на классе в Qt Creator.

                                    0
                                    Ага, поняла. Согласна, было бы удобно. Даже вот такая общая задачка под это есть в трекере, но руки пока не дошли.
                                0
                                Странно, после апдейта Pycharm и Clion видят проект из python и c файлов как одно целое, что ведёт к незначительным ошибкам. Ну и набор вкладок для редакторов теперь один, что очень неудобно.
                                  0
                                  Не очень поняла, если честно, что имеется в виду. Можно чуть поподробнее?

                                  проект из python и c файлов как одно целое

                                  А это на самом деле один проект?

                                  набор вкладок для редакторов теперь один

                                  Можно скриншот приложить? Я, к сожалению, не очень поняла, про какие вкладки речь.
                                    0
                                    Да, я несколько сумбурно объяснил: у меня один проект содержит C и Python код в одной директории. Теперь, когда я открываю Pycharm, я получаю:
                                    Cannot determine module type («CPP_MODULE») for the following module:

                                    Вдобавок, если открыть несколько файлов в соответствующем редакторе, например, main.c в Clion, а потом закрыть сам редактор и открыть тот же проект в Pycharm, то я снова получу main.c. Раньше я мог работать отдельно с .py и .c файлами, а теперь получается каша. Я не профессиональный программист и не работаю с IDE ежедневно, так что могу что-то упускать.
                                      0
                                      А пример проекта сможете дать?
                                        0
                                        А как он должен выглядеть?
                                          0
                                          Более или менее замкнутый проект, который мы сможем у себя открыть. При этом он может ничего не делать, кроме как демонстрировать проблему.
                                  +1
                                  Не подскажете, а есть ли вариант в CLion полностью отключить уведомления о том, что в коде есть какие-то ошибки, но оставив при это автодополнение, переход к обьявлениям функций и так далее? просто чтобы в IDE красным цветом не выделялось то, что парсер не смог распарсить (конечно я понимаю, что в данном случае часть невалидного кода тоже перестанет подсвечиваться красным). Причина — слишком большое количество красного кода на моём проекте.
                                    0
                                    Красный код отключить нельзя. Это весь на самом деле, не просто так красный код, а звоночек, что вообще весь code insight будет не правильно работать. И то же автодополнение, и навигация.

                                    А много красного кода на какой версии/платформе? 2018.2 с clangd включенным пробовали?

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

                                  Самое читаемое