CLion 2020.2: suporte a modelo de design Makefile, mais C ++ 20 e mais

Olá, Habr!



Nossa equipe teve um verão muito agitado, cujos resultados hoje temos pressa em compartilhar. Portanto, dê as boas-vindas à nova versão do CLion 2020.2!







Resumidamente sobre o que está incluído na nova versão :

• Suporte ao modelo de design Makefile.
• Últimas atualizações no CMake.
• C++20: explicit(bool), (designated initializers), for .
• : (dangling pointers), , , , .
• -: doctest, Catch2 Google Test. .
• PlatformIO .
• .
• .
• .

Makefile

Tendo marcado o quinto aniversário do CLion nesta primavera , imediatamente nos envolvemos na conclusão ativa do recurso mais esperado no IDE - suporte para projetos baseados no Makefile. Antes disso, tínhamos apenas um protótipo rudimentar, que demos aos nossos usuários mais ousados ​​para experimentar em particular. Graças a eles, fomos capazes de testar o protótipo em uma ampla seleção de projetos Makefile, corrigir muitos problemas nele e entender as limitações atuais (esperançosamente temporárias) de nossa solução. Nosso objetivo é permitir que os usuários trabalhem com um projeto Makefile no CLion com todos os recursos do IDE inteligente, como navegação, refatoração, análise de código estático e muito mais.



A abordagem atual em resumo se parece com isto: CLion executa um comando makeem seu projeto com uma opção adicional--just-printpara economizar tempo na montagem real. Se o CLion puder analisar a saída do comando com sucesso, o projeto será aberto e tudo funcionará!



Vamos fazer uma reserva imediatamente que o trabalho no suporte a Makefile no CLion ainda está longe de ser concluído - ainda existem muitas limitações e imperfeições conhecidas. Mais notável:

• Projetos usando libtool ( CPP-19549 ), distcc e ccache ( CPP-19305 ) e outros wrappers que "ocultam" sinalizadores de compilação da saída ou interferem na saída do comando não são suportados make.
• CLion ainda não é capaz de lidar com saídas não GNU Makes (por exemplo, NMake, BSD) ( CPP-18723 ).
• Ele não suporta projetos que desabilitam a listagem de nomes de diretório durante o processo de construção, portanto, o CLion não pode determinar quais arquivos são específicos para quais comandos de construção.

Mas mesmo a solução atual já permite que você abra o kernel do Linux ou código do servidor de banco de dados PostgreSQL no CLion. Caso tenha interesse, a lista atual de projetos onde nosso protótipo funciona (assim como alguns projetos onde não funciona, com os problemas indicados) pode ser encontrada nesta página .



É muito fácil experimentar em seu projeto:

1. Prepare um projeto para obter um Makefile para ele (por exemplo, em muitos casos você precisa iniciá-lo ./configure, já que o próprio CLion ainda não sabe como fazer isso).
2. Abra um projeto com Arquivo | Abra e especifique o diretório que contém o Makefile do projeto principal ou diretamente este próprio arquivo. Confirme que deseja abrir como um projeto.
3. CLion , Clean. , make , .
4. , , ! Build.

A saída pode conter alguns avisos, mas se o download foi concluído com sucesso (deve haver uma marca verde ao lado da primeira tarefa), então você pode trabalhar com o projeto no CLion.



As configurações do argumento do comando de inicialização, o conjunto de ferramentas usado para a inicialização e outras opções podem ser encontradas em Configurações / Preferências | Compilação, execução, implantação | Makefile:







para executar e depurar aplicativos Makefile, você precisará criar configurações adicionais do aplicativo Makefile. Nesse caso, o destino pode ser selecionado na lista suspensa - o CLion dirá quais opções existem:







Em nosso blog em inglês, você pode encontrar mais informações sobre como trabalhar com projetos Makefile no CLion. Também recomendamos assistir a uma breve demonstração (em inglês):

Últimas atualizações no CMake

Como mostram as estatísticas , os três modelos de design mais populares agora entre os desenvolvedores C ++ são CMake, msbuild e Makefile. E é o CMake que lidera essa classificação há três anos e continua crescendo. Portanto, estamos constantemente atualizando a versão do CMake que está proibida no CLion e trabalhando para oferecer suporte às últimas inovações no próprio CMake. Desta vez, atualizamos a versão para 3.17 e, em conformidade, adicionamos suporte para dois novos recursos úteis do CMake:

• Ninja Multi-Config ( Debug Release) Ninja ( -G "Ninja Multi-Config"). CLion , CMake . UI, .
• Os cabeçalhos pré-compilados do CMake merecem mais atenção. Em geral, a ideia de arquivos de cabeçalho pré-compilados (PCH) não é nova e é suportada pelos compiladores há muito tempo. CLion também já existe com o PCH há algum tempo. Agora você não precisa se lembrar dos sinalizadores do compilador para PCH e passá-los ao CMake para cada compilador específico de sua própria maneira, mas simplesmente adicionar arquivos de cabeçalho às variáveis ​​de destino PCH por meio do comando target_precompile_headers. O CLion 2020.2 agora é capaz de trabalhar com isso:
  
  
  
  

Também digno de nota é a capacidade de abrir um projeto CMake no CLion a partir do diretório com o resultado da geração CMake, agora não só para o gerador de Makefile, mas para qualquer outro! Economize tempo - abra projetos já construídos no CLion sem reiniciar o comando CMake no projeto.

C ++ 20

Você sabia que, de acordo com nossos dados , este ano já 12% dos desenvolvedores C ++ utilizam o padrão C ++ 20 ?! Portanto, é claro, estamos trabalhando ativamente para oferecer suporte aos novos recursos do CLion. Mas vamos primeiro lembrar o que temos com os motores de linguagem no CLion.



Portanto, no momento existem dois deles - um integrado baseado em Java / Kotlin e um relativamente novo baseado em Clangd, respectivamente, em C ++ (usamos CLion para desenvolvê-lo). Todos os esforços agora estão sendo colocados em um mecanismo baseado em Clangd. Parece ser uma boa perspectiva, embora ações em todo o projeto (como refatorações) não possam ser feitas nele ainda - aqui mesmo um mecanismo baseado em Java imperfeito e às vezes lento ganha devido a quaisquer otimizações específicas e resoluções adiadas e, é claro, devido à presença de um cache símbolos necessários para refatorações.



Mas o Clangd tem uma grande vantagem - toda a comunidade está trabalhando lá para oferecer suporte aos padrões C ++ mais recentes no Clang, porque o projeto é aberto. Isso, é claro, não significa que não precisamos fazer nada - esse apoio ainda precisa ser adaptado às necessidades de CLion. Mas isso já é mais fácil do que escrever o suporte para recursos C ++ do zero! E com base no suporte do Clang, você pode escrever sua própria análise específica ou fazer alguns recursos especiais (por exemplo, fizemos o preenchimento automático para Conceitos há alguns lançamentos).



Certificamo-nos de que a última atualização do mecanismo Clangd, que veio com o LLVM, se comporta de forma mais estável no código C ++ 20 e, em geral, de acordo com nossas estatísticas integradas, o mecanismo Clangd se tornou mais estável. Portanto, a capacidade de desabilitar completamente o mecanismo Clangd foi removida das configurações. Mas adicionado a Configurações / Preferências | Idiomas e estruturas | C / C ++ | Informações do Clangd sobre a revisão com a qual nosso motor foi construído. Agora você sabe o que esperar dele em termos de suporte para C ++ e análise do Clang-Tidy integrado:







A propósito, em nossa ajuda online há um excelente artigo com uma análise comparativa dos dois motores em termos de suporte para recursos de C ++.



E agora sobre o que realmente foi adicionado do suporte C ++ 20:

• Conclusão de código para C ++ 20 palavras-chave: char8_t, constevale constinit, co_await, co_return, e co_yield.
• Preenchimento para campos da classe base em inicializadores designados:
  
  
  
  
• A construção explicit(bool)agora está devidamente destacada, dicas de nome, navegação e refatoração funcionam nela:
  
  
  
  
• Para loops forbaseados em intervalo com inicializadores, a refatoração Renomear para variáveis ​​de loop funcionou.

Analisador de código estático

Na última versão, transferimos nossa análise mais “pesada” - Data Flow Analysis - para um mecanismo baseado em Clangd. Isso é principalmente para melhorar o desempenho. Mas, como costuma acontecer, durante a refatoração, muitos problemas e imprecisões foram encontrados. Portanto, na versão 2020.2, continuamos aprimorando essa análise e corrigindo bugs nela:

• , , .
• DFA Simplify code Loop condition is never updated. , :
  
  
  
  
  
  
  
  , :
  
  
  
  
  
  
  
  - , . , Clang-Tidy (clang-tidy:bugprone-infinite-loop), - . CLion :
  
  
  
  
• CLion (dangling pointers)! (, ), :
  
  
  
  
• , Concepts C++20, - auto, :
  
  
  
  

Neste lançamento, o Inspection Hector favorito de todos (de quem alguns de nossos usuários até tentaram em vão zombar ) se transformou em um novo Inspection Widget localizado no canto superior direito da área do editor. Agora é lá que as opções para definir o nível de luz de fundo estão localizadas (desde mostrar todos os problemas até desabilitar completamente o analisador de código), e quando você clica, uma janela de resultados da análise estática para este arquivo é aberta:

Teste de unidade

A pesquisa já mencionada aqui mais de uma vez mostra que 34% dos desenvolvedores C ++ não escrevem nenhum teste de unidade . Eu gostaria de acreditar que, em troca, eles conduzem os testes de outra maneira. Parte do problema é que C ++ não tem um modelo de design padrão ou um gerenciador de dependência padrão, o que significa que adicionar uma estrutura de teste de unidade ao seu projeto não é fácil. Mas agora os chamados frameworks apenas de cabeçalho estão se tornando especialmente populares, que são fáceis de conectar ao seu projeto - adicione um arquivo de cabeçalho e escreva testes você mesmo. De nossa parte, no IDE tentamos oferecer suporte ao maior número de opções possível. Nesta versão, doctest foi adicionado ao conjunto de Google Test, Catch, Boost.Test. A propósito, tivemos uma postagem no blog de um convidado há um tempode seu autor, onde Viktor falou sobre as vantagens deste framework.



O suporte do CLion inclui as coisas usuais:

• Detecção automática de teste.
• Criação automática de configurações para execução e depuração de testes.
• Saída dos resultados do teste em uma janela embutida especial com várias opções de filtragem e ordenação, bem como com uma transição para o código-fonte do teste em um clique.
• Ícones no editor, no painel esquerdo, para executar testes e identificar o status da última execução de testes.

O suporte do Google Test e Catch2 também foi atualizado:

• Suporte para testes de modelo foi adicionado para Catch2.
• E para Google Test, suporte para macro GTEST_SKIP(), que pode ser muito útil se você quiser poder pular alguns testes, por exemplo, em ambientes específicos.

Um pequeno vídeo de visão geral sobre melhorias no suporte de teste de unidade de nosso advogado (a propósito, o autor da estrutura Catch / Catch2):





Advertindo suas dúvidas sobre o CTest: tornando um pouco mais difícil, pois este não é um framework “normal”, mas um certo nível de abstração para executar qualquer coisa na forma de um teste. Mas estamos planejando alguma integração já em 2020.3!

E

O mais interessante, talvez, discutido, agora brevemente sobre o resto. Eu deveria ter começado com isso, mas o CLion 2020.2 inclui muitas melhorias pequenas, mas importantes para o desempenho do editor e correções de trava do editor. Uma dessas melhorias, por exemplo, é a inserção de uma barra invertida quando pressionada Enter dentro de uma definição de macro . Parece que isso ajuda a produtividade do editor? O fato é que muito provavelmente a nova linha faz parte da definição da macro atual, e inserir uma barra invertida permite evitar uma nova revisão desnecessária de um monte de código e, portanto, os freios do editor.



Além disso:

• PlatformIO — , platformio.ini CMake .
• , IntelliJ . : GitHub Pull Requests Git WSL2 ( WSL2, CLion Git ).
• Em termos de depuradores em 2020.2, conseguimos fazer menos do que o planejado. Basicamente, todas as grandes tarefas foram adiadas para 2020.3 (depuração como root, depuração de core dumps). Mas nesta versão, atualizamos a versão banida do GDB para 9.2 e também atualizamos as lindas impressoras GDB STL. Muitas melhorias, tanto funcionais, desempenho e estabilidade, foram feitas em nosso depurador baseado em LLDB para o conjunto de ferramentas Microsoft Visual C ++.

Isso é tudo por hoje. Você leu até o fim? Muito obrigado pela atenção! Experimente , escreva perguntas, sugestões, exclamações nos comentários - estamos sempre dispostos a ler e responder!



Equipe CLion

A motivação para desenvolver