CLion 2020.2: compatibilidad con el modelo de diseño Makefile, más C ++ 20 y más

¡Hola, Habr!



Nuestro equipo tuvo un verano muy ocupado, cuyos resultados tenemos prisa por compartir hoy. ¡ Bienvenidos a la nueva versión de CLion 2020.2!







Brevemente sobre lo que se incluye en la nueva versión :

• Soporte de modelo de diseño de Makefile.
• Últimas actualizaciones en CMake.
• C++20: explicit(bool), (designated initializers), for .
• : (dangling pointers), , , , .
• -: doctest, Catch2 Google Test. .
• PlatformIO .
• .
• .
• .

Makefile

Habiendo celebrado el quinto aniversario de CLion esta primavera , nos involucramos de inmediato en la finalización activa de la función más esperada del IDE: soporte para proyectos basados ​​en Makefile. Antes de eso, solo teníamos un prototipo tosco, que les dimos a nuestros usuarios más atrevidos para que lo probaran en privado. Gracias a ellos, pudimos probar el prototipo en una amplia selección de proyectos Makefile, solucionar muchos problemas en él y comprender las limitaciones actuales (con suerte temporales) de nuestra solución. Nuestro objetivo es permitir que los usuarios trabajen con un proyecto Makefile en CLion con todas las funciones de IDE inteligentes, como navegación, refactorizaciones, análisis de código estático y más.



El enfoque actual en resumen se ve así: CLion ejecuta un comando makeen su proyecto con una opción adicional--just-printpara ahorrar tiempo en el montaje real. Si CLion puede analizar correctamente la salida del comando, entonces el proyecto se abre y todo funciona.



Hagamos una reserva de inmediato de que el trabajo sobre el soporte de Makefile en CLion está lejos de estar completo; todavía hay muchas limitaciones e imperfecciones conocidas. Más notable:

• Los proyectos que utilizan libtool ( CPP-19549 ), distcc y ccache ( CPP-19305 ) y otros contenedores que "ocultan" indicadores de compilación de la salida o interfieren con la salida del comando no son compatibles make.
• CLion aún no puede manejar salidas que no sean de GNU (por ejemplo, NMake, BSD) ( CPP-18723 ).
• No admite proyectos que deshabilitan la lista de nombres de directorio durante el proceso de compilación, por lo que CLion no puede determinar qué archivos son específicos de qué comandos de compilación.

Pero incluso la solución actual ya le permite abrir el kernel de Linux o el código del servidor de la base de datos PostgreSQL en CLion. Si está interesado, entonces la lista actual de proyectos en los que funciona nuestro prototipo (así como algunos proyectos en los que no funciona, con los problemas indicados) se puede encontrar en esta página .



Es muy fácil probar tu proyecto:

1. Prepare un proyecto para obtener un Makefile (por ejemplo, en muchos casos es necesario iniciarlo ./configure, ya que CLion todavía no sabe cómo hacerlo).
2. Abra un proyecto con Archivo | Abra y especifique el directorio que contiene el Makefile del proyecto principal o directamente este archivo. Confirma que quieres abrir como proyecto.
3. CLion , Clean. , make , .
4. , , ! Build.

La salida puede contener algunas advertencias, pero si la descarga se completó correctamente en general (debería haber una marca verde junto a la primera tarea), entonces puede trabajar con el proyecto en CLion.



La configuración de los argumentos del comando de inicio, la cadena de herramientas utilizada para el inicio y otras opciones se pueden encontrar en Configuración / Preferencias | Construcción, ejecución, implementación | Makefile:







para ejecutar y depurar aplicaciones Makefile, deberá crear configuraciones adicionales de la aplicación Makefile. En este caso, el objetivo se puede seleccionar de la lista desplegable - CLion le dirá qué opciones están disponibles:







En nuestro blog en inglés puede encontrar más información sobre cómo trabajar con proyectos Makefile en CLion. También recomendamos ver una breve demostración (en inglés):

Últimas actualizaciones en CMake

Como muestran las estadísticas , los tres modelos de diseño más populares ahora entre los desarrolladores de C ++ son CMake, msbuild y Makefile. Y es CMake quien ha estado liderando esta calificación durante tres años y continúa creciendo. Por lo tanto, estamos actualizando constantemente la versión de CMake que está prohibida en CLion y estamos trabajando para respaldar las últimas innovaciones en CMake. Esta vez actualizamos la versión a 3.17 y, en consecuencia, agregamos soporte para dos nuevas funciones útiles de CMake:

• Ninja Multi-Config ( Debug Release) Ninja ( -G "Ninja Multi-Config"). CLion , CMake . UI, .
• Los encabezados precompilados de CMake merecen más atención. En general, la idea de archivos de encabezado precompilados (PCH) no es nueva y los compiladores la han apoyado durante mucho tiempo. CLion también ha existido con PCH durante bastante tiempo. Ahora no tiene que recordar los indicadores del compilador para PCH y pasarlos a CMake a cada compilador específico a su manera, simplemente agregue archivos de encabezado a las variables de destino de PCH a través del comando target_precompile_headers. CLion 2020.2 ahora puede trabajar con esto:
  
  
  
  

También es destacable la posibilidad de abrir un proyecto CMake en CLion desde el directorio con el resultado de la generación CMake, ahora no solo para el generador Makefile, ¡sino para cualquier otro! Ahorre tiempo: abra proyectos ya construidos en CLion sin reiniciar el comando CMake en el proyecto.

C ++ 20

¿Sabías que, según nuestros datos , este año ya el 12% de los desarrolladores de C ++ utilizan el estándar C ++ 20? Por lo tanto, por supuesto, estamos trabajando activamente para admitir nuevas funciones en CLion. Pero primero recordemos lo que tenemos con los motores de lenguaje en CLion.



Entonces, por el momento hay dos de ellos: uno incorporado basado en Java / Kotlin y uno bastante nuevo basado en Clangd, respectivamente en C ++ (usamos CLion para su desarrollo). Ahora se están poniendo todos los esfuerzos en un motor basado en Clangd. Parece ser una buena perspectiva, aunque todavía no se pueden realizar acciones en todo el proyecto (como refactorizaciones); en este caso, incluso un motor basado en Java imperfecto y a veces lento gana debido a optimizaciones específicas y resoluciones diferidas y, por supuesto, debido a la presencia de un caché símbolos necesarios para las refactorizaciones.



Pero Clangd tiene una gran ventaja: toda la comunidad está trabajando allí para admitir los últimos estándares de C ++ en Clang, porque el proyecto está abierto. Esto, por supuesto, no significa que no necesitemos hacer nada en absoluto; de todos modos, este soporte aún debe adaptarse a las necesidades de CLion. ¡Pero esto ya es más fácil que escribir soporte para características de C ++ desde cero! Y sobre la base del soporte en Clang, puede escribir su propio análisis específico o hacer algunas características especiales (por ejemplo, hicimos el autocompletado para Concepts hace algunas versiones).



Nos aseguramos de que la última actualización del motor Clangd, que venía con LLVM, se comportara de forma más estable en el código C ++ 20 y, en general, según nuestras estadísticas integradas, el motor Clangd se ha vuelto más estable. Por lo tanto, la capacidad de deshabilitar completamente el motor Clangd se eliminó de la configuración. Pero agregado a Configuración / Preferencias | Idiomas y marcos | C / C ++ | Clangd información sobre la revisión con la que está construido nuestro motor. Ahora ya sabe qué esperar de él en términos de soporte para C ++ y análisis de Clang-Tidy incorporado:







Por cierto, en nuestra ayuda en línea hay un excelente artículo con un análisis comparativo de los dos motores en términos de soporte para capacidades de C ++.



Y ahora sobre lo que realmente se agregó del soporte de C ++ 20:

• Finalización de código para C ++ 20 palabras clave: char8_t, consteval, y constinit, co_await, co_return, y co_yield.
• Finalización de campos de la clase base en inicializadores designados:
  
  
  
  
• La construcción explicit(bool)ahora está resaltada correctamente, las sugerencias de nombres, la navegación y las refactorizaciones funcionan en ella:
  
  
  
  
• Para forlos bucles basados ​​en rangos con inicializadores, la refactorización de cambio de nombre para las variables de bucle funcionó.

Analizador de código estático

En la última versión, transferimos nuestro análisis más "pesado", el análisis de flujo de datos, a un motor basado en Clangd. Esto es principalmente para mejorar el rendimiento. Pero, como sucede a menudo, durante la refactorización, se encontraron muchos problemas e inexactitudes. Entonces, en la versión 2020.2, continuamos mejorando este análisis y corrigiendo errores en él:

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

En esta versión, el Héctor de Inspección favorito de todos (del que algunos de nuestros usuarios incluso intentaron en vano burlarse ) se ha convertido en un nuevo widget de inspección ubicado en la esquina superior derecha del área del editor. Ahora es allí donde se encuentran las opciones para configurar el nivel de retroiluminación (desde mostrar todos los problemas hasta deshabilitar completamente el analizador de código), y al hacer clic, se abre una ventana de resultados del análisis estático para este archivo:

Examen de la unidad

La investigación ya mencionada aquí más de una vez muestra que el 34% de los desarrolladores de C ++ no escribe ninguna prueba unitaria . Me gustaría creer que, a cambio, realizan pruebas de alguna otra manera. Parte del problema es que C ++ no tiene un modelo de diseño estándar o un administrador de dependencias estándar, lo que significa que agregar un marco de pruebas unitarias a su proyecto no es fácil. Pero ahora los llamados marcos de solo encabezado se están volviendo especialmente populares, que son fáciles de conectar a su proyecto: agregue un archivo de encabezado y escriba pruebas usted mismo. Por nuestra parte, en el IDE intentamos dar soporte a la mayor cantidad de opciones posibles. En esta versión, doctest se ha agregado al conjunto de Google Test, Catch, Boost.Test. Por cierto, tuvimos una publicación de blog invitada hace un tiempo.de su autor, donde Viktor habló sobre las ventajas de este marco.



El soporte de CLion incluye las cosas habituales:

• Detección de prueba automática.
• Creación automática de configuraciones para ejecutar y depurar pruebas.
• Salida de los resultados de la prueba en una ventana especial incorporada con varias opciones de filtrado y ordenación, así como con una transición de un clic al código fuente de la prueba.
• Iconos en el editor, en el panel izquierdo, para ejecutar pruebas e identificar el estado de la última ejecución de pruebas.

También se ha actualizado el soporte de Google Test y Catch2:

• Se ha agregado soporte para pruebas de plantilla para Catch2.
• Y para Google Test, soporte para una macro GTEST_SKIP(), que puede resultar muy útil si quieres poder saltarte algunas pruebas, por ejemplo, en entornos específicos.

Un pequeño video general sobre las mejoras en el soporte de pruebas unitarias de nuestro abogado (por cierto, el autor del marco Catch / Catch2):





Advertencia a sus preguntas sobre CTest: haciéndolo un poco más difícil, porque este no es un marco "regular", sino un cierto nivel de abstracción para ejecutar cualquier cosa como una prueba. ¡Pero estamos planeando una integración a partir de 2020.3!

Y

Lo más interesante, quizás, comentado, ahora brevemente sobre el resto. Debería haber comenzado con esto, pero CLion 2020.2 incluye muchas mejoras pequeñas pero importantes en el rendimiento del editor y correcciones de bloqueos del editor. Una de esas mejoras, por ejemplo, es la inserción de una barra invertida cuando se presiona Enter dentro de una definición de macro . ¿Parecería que esto ayuda a la productividad del editor? El hecho es que lo más probable es que la nueva línea sea parte de la definición de la macro actual, y la inserción de una barra invertida le permite evitar el reparsing innecesario de un montón de código y, por tanto, los frenos del editor.



Además:

• PlatformIO — , platformio.ini CMake .
• , IntelliJ . : GitHub Pull Requests Git WSL2 ( WSL2, CLion Git ).
• En términos de depuradores en 2020.2, logramos hacer menos de lo planeado. Básicamente, todas las tareas importantes se han retrasado hasta 2020.3 (depuración como root, depuración de volcados de núcleo). Pero en esta versión hemos actualizado la versión prohibida de GDB a 9.2 y también hemos actualizado las bonitas impresoras GDB STL. Se han realizado muchas mejoras, tanto funcionales como de rendimiento y estabilidad, en nuestro depurador basado en LLDB para la cadena de herramientas de Microsoft Visual C ++.

Eso es todo por hoy. ¿Has leído hasta el final? ¡Muchas gracias por su atención! Pruébelo , escriba preguntas, sugerencias, exclamaciones en los comentarios, ¡siempre estaremos encantados de leerlos y responderlos!



Equipo CLion

El impulso para desarrollar