Hola Habr!
El verano fuera de la ventana vuela para nosotros casi imperceptiblemente, porque hemos dedicado todos estos meses a trabajar en la nueva versión 2019.2 de nuestro entorno de desarrollo multiplataforma para C ++ - CLion. Logramos hacer muchas cosas: llevar a cabo un Hackathon interno, probar nuevas ideas y llevar una serie de correcciones y nuevas características a un lanzamiento inmediato. Pero lo primero es lo primero.
En resumen, en esta versión nosotros:
- Continuamos refinando el soporte para el desarrollo de sistemas integrados: aparecieron nuevas capacidades de depuración y visualización de periféricos.
- El depurador experimental para MSVC se ha llevado a una calidad aceptable.
- Reescribimos por completo la verificación del código en Incluye sin usar en clangd, agregando la capacidad de configurar diferentes estrategias.
- Sugerencias implementadas para argumentos de llamada a funciones y lambdas para mejorar la legibilidad del código.
- Llevamos a cabo un Hackathon dentro del equipo para mejorar la productividad, ideamos un montón de nuevos enfoques y logramos implementar varias mejoras.
- Implementamos el resaltado de sintaxis para más de 20 idiomas, creamos un complemento de Shell Script y actualizamos el complemento Rust.
Esto, por supuesto,
no es todo . Hablaremos con más detalle a continuación, pero si está listo para probarlo ahora, entre y descargue la compilación de
nuestro sitio . Como de costumbre, hay disponible una prueba gratuita durante 30 días.
Nuevas características para desarrollo integrado
En la versión anterior, por alguna razón, muchos pensaron que nos centramos solo en las placas STM32. Este, por supuesto, es uno de los mercados más interesantes y extensos en muchos estudios (incluido nuestro mercado interno), pero ahora estamos tratando de resolver problemas más generales. Por ejemplo, ampliamos las capacidades de depuración en varios tableros de CLion.
Anteriormente, la única opción era la configuración del depurador OpenOCD: OpenOCD Download & Run. Ahora ha aparecido otro: el servidor GDB incorporado. De hecho, si la placa admite la depuración a través de algún servidor GDB compatible, puede depurarla a través de CLion. La configuración cubre casos como OpenOCD, servidores ST-Link GDB, servidor Segger J-Link GDB, QEMU y más.
Es suficiente crear y configurar la configuración adecuada: especifique la ruta al servidor GDB, los argumentos que le pasa, quizás algunas configuraciones más avanzadas. ¡Ahora ejecute la depuración en esta configuración, y puede depurar en el tablero directamente desde CLion!
Hay una limitación importante que ahora afecta a ambas configuraciones para depurar sistemas embebidos: ambos solo funcionan actualmente con proyectos en CMake. En el futuro, planeamos agregar la capacidad de ejecutarlos para modelos de diseño personalizados (
CPP-16079 ).
Para ambas configuraciones de depuración existentes de sistemas integrados (Embedded GDB Server y OpenOCD Download & Run), la nueva versión ahora tiene la capacidad de ver periféricos durante la depuración. En general, los periféricos se especifican para dispositivos de la familia ARM en
archivos de formato
.svd . Estas especificaciones ahora se pueden cargar en CLion y ver los periféricos seleccionados directamente en la ventana del depurador:
Todos los periféricos todavía están disponibles en modo de solo lectura, mientras que hay una búsqueda por nombre, la capacidad de ver valores en diferentes modos (hexadecimal, decimal, octal y binario). Puedes leer un poco más sobre esto en nuestro
blog (en inglés).
Depurador experimental para MSVC
Lo has leído bien: en la versión 2019.2, ¡CLion introdujo un depurador experimental para el código compilado usando MSVC! Ahora comprendamos un poco más de detalle y en orden.
Durante mucho tiempo en CLion, puede usar no solo la cadena de herramientas MinGW y Cygwin, sino también Visual Studio al desarrollar en la plataforma Windows. Usted especifica la ruta al VS instalado en CLion, y desde allí tomamos el compilador y los scripts de MSVC para configurar el entorno. Pero hubo problemas con el depurador durante mucho tiempo. El hecho es que el depurador que Visual Studio usa es propietario. En pocas palabras, en ninguna parte, excepto las herramientas de Microsoft, se puede usar bajo licencia. Existe una tecnología alternativa:
dbgeng.dll , en la que se implementan los depuradores de CDB y WinGDB. Lo primero que probamos fue ella. Pero nos pareció que lidiar con la cantidad de bloqueos críticos y el bajo rendimiento en los archivos binarios con una gran cantidad de archivos PDB no es muy prometedor (aunque lo intentamos al principio). Y luego resultó que hay una tercera opción: implementar un depurador sobre LLDB. Ya había logros, y solo teníamos que continuar este trabajo. Lo que hicimos! Por cierto, hemos puesto todos nuestros cambios (excepto el soporte de visualizadores de datos nativos por ahora) en el asistente de LLVM.
¿Cómo habilitar? Como ya escribí, la oportunidad aún es experimental. Es demasiado pronto para llamar a un depurador de pleno derecho, tiene muchas limitaciones y deficiencias, y el rendimiento requiere optimizaciones significativas. Esta característica experimental está habilitada en el cuadro de diálogo Mantenimiento (
Shift+Ctrl+Alt+/ en Linux / Windows,
⌥⇧⌘/ en macOS) | Características experimentales |
cidr.debugger.lldb.windows . Ahora hay un nuevo depurador disponible para la cadena de herramientas de Visual Studio:
El depurador tiene soporte inicial para visualizadores nativos, tanto suministrados con el estudio como personalizados personalizados que se encuentran en el proyecto. Por ahora, la función requiere una inclusión explícita en la configuración: Configuración | Construcción, Ejecución, Implementación | Vistas de datos del depurador | Habilita los procesadores NatVis para LLDB. En una de las primeras actualizaciones, planeamos solucionar varios problemas críticos con los visualizadores y luego, probablemente, activarlos de forma predeterminada.
Si planea probar un nuevo depurador experimental, le recomendamos que se familiarice con la lista de limitaciones y problemas conocidos en
nuestro blog .
Otras mejoras de depurador
Además del nuevo depurador experimental, realizamos otras mejoras:
- En la consola GDB / LLDB incorporada, en la ventana del depurador en CLion, la autocompletación de los comandos del depurador ahora funciona (use
Tab o Ctrl+Space ). - Los puntos de interrupción de las cadenas ahora se validan sobre la marcha , y su estado se actualiza y se muestra al usuario en forma de un icono correspondiente. El tipo más interesante es Inválido , que se agregó para identificar puntos de interrupción que no están disponibles en el código ejecutable actual o para los que no hay símbolos de depuración (en este caso, después de cargarlos, el estado del punto de interrupción se actualizará automáticamente):
- Al visualizar la memoria en el depurador (Vista de memoria) en la nueva versión, se hizo posible cambiar a una dirección arbitraria (por dirección numérica o nombre / dirección de variable), así como presentar la memoria en formato ASCII:
Mejoras del editor de código
Hay varias mejoras importantes en esta área. Primero, reescribimos por completo la verificación del código
Incluye sin usar y la activamos de manera predeterminada. Anteriormente, también estaba allí, pero daba una gran cantidad de falsos positivos, por lo que lo desactivamos de forma predeterminada. ¿Por qué está mejorando? Reescribimos completamente la verificación en función de la segunda herramienta adicional para analizar el código, que, a su vez, se basa en Clangd. Entonces, esta es una limitación clara: la nueva versión funcionará solo si Clangd no está deshabilitado para usted (de manera predeterminada, está habilitado). Pero ahora, al verificar la inclusión no utilizada, han aparecido varias estrategias, entre las cuales puede elegir:
De forma predeterminada,
se utiliza Detectar no utilizado directamente , que es esencialmente el principio más cercano al conocido principio de
Incluir lo que usa , es decir, si las declaraciones del archivo de encabezado no se utilizan directamente en este archivo, dicho archivo de encabezado se marca como no utilizado.
En la configuración de inspección (Configuración / Preferencias | Editor | Inspecciones | C / C ++ | Código no utilizado | Directiva de inclusión no utilizada), también puede elegir si ejecutar la verificación en los archivos de encabezado. Es cierto que solo funcionará en aquellos archivos de encabezado donde estén presentes
#pragma o protectores de encabezado. También es importante saber que si hay errores de compilación en el archivo fuente, la verificación no mostrará los archivos no utilizados.
Desde la última versión, CLion ha admitido
ClangFormat como una herramienta alternativa de formato de código, además de la integrada. En esta versión, agregamos un esquema JSON incorporado para archivos de configuración en formato .clang. Y gracias a esto, pudimos agregar varias características que pueden ser útiles para aquellos que modificarán los archivos de formato .clang en CLion:
- La finalización automática ha aparecido para las opciones y sus valores.
- En la ventana de autocompletado de opciones, ahora hay una descripción de las opciones.
- La ventana de documentación de documentación rápida (
Ctrl+Q en Windows / Linux, F1 en macOS) muestra la documentación de las opciones y sus significados, con ejemplos. - Se agrega la validación de opciones para valores válidos.
Consejos para argumentos
¿Qué sucede si la función está escrita (quizás no por usted) de modo que se le pasen 3 enteros como argumentos? ¿Cómo entender por una función llamada qué significan los valores transferidos? Por supuesto, puede ver la firma de la función en la ventana de documentación, ir a la definición de la función o consultar la información del parámetro (Información del parámetro). ¿Y si no haces estas acciones explícitas?
En la versión CLion 2019.2, aparecían sugerencias de herramientas para argumentos: cuando se llama a una función, lambda, constructor, lista de inicialización o cuando se usa una macro, CLion muestra los nombres de los parámetros antes de que pasen los argumentos:
Las sugerencias se muestran en los casos en que es realmente difícil entender qué valores se pasan a qué parámetros, a saber, si se usan literales o expresiones con más de un operando como argumentos.
Más detalles en la publicación del blog .
Rendimiento
Por supuesto, a menudo se nos pregunta sobre las mejoras de rendimiento. Repito, para nosotros esta es la tarea más prioritaria, pero resulta que no hay muchos cambios de puntos, y los globales requieren más tiempo que 1-2 ciclos de lanzamiento. Ahora hay varios cambios tan grandes en el trabajo. Básicamente, están relacionados con la forma en que el analizador en CLion interactúa con la arquitectura de la plataforma (que no siempre calcula que un código de resolución largo está oculto detrás de una acción simple, en el caso de C ++).
Este verano, el equipo y yo decidimos realizar un Hackathon interno para identificar los puntos más vulnerables en la arquitectura y plataforma de CLion, probar nuevas ideas audaces y probar algunas hipótesis antiguas. Nos gustaron los resultados. Si es posible, planeamos aportar nuevas ideas para el lanzamiento en 2019.3.
Pero la versión 2019.2 no se quedó sin mejoras de rendimiento:
- Nos deshicimos de muchas de las ralentizaciones y congelaciones en la refactorización del cambio de nombre in situ.
- Rendimiento de autocompletado mejorado para expresiones calificadas.
- En el caso del trabajo remoto, redujimos el número de operaciones de E / S, lo que aceleró significativamente la recopilación de información sobre el compilador y, por lo tanto, la velocidad de descarga del proyecto CMake.
- Y otras mejoras.
No solo C ++
Desde la plataforma IntelliJ en CLion 2019.2, se han realizado muchas mejoras para trabajar con otros idiomas.
El resaltado de sintaxis de más de
20 idiomas ahora lo proporcionan las gramáticas de TextMate (se puede encontrar una lista completa de idiomas en Configuración / Preferencias | Editor | Paquetes de TextMate). Por supuesto, si para este lenguaje hay soporte extendido en CLion (Python, JavaScript, HTML, Objective-C, SQL), entonces se usará, pero para lenguajes como Ruby, el resaltado más simple puede ser útil:
A menudo, en proyectos de C ++ hay una variedad de
scripts . El complemento Shell Script ahora está integrado en CLion. Proporciona no solo resaltado de código, sino también autocompletado y cambio de nombre de texto:
El complemento Rust ha recibido muchas actualizaciones útiles. Desde una nueva herramienta experimental de expansión de macros (Configuración / Preferencias | Lenguajes y marcos | Óxido | Expandir macros declarativas) a
Duplicar fragmentos de código , varias nuevas soluciones rápidas y autocompletado en el depurador en
Evaluar expresiones . Por cierto, ¡es en CLion que el mayor uso de este complemento se encuentra ahora entre todos los IDE de JetBrains!
Demo
Video tradicional sobre las nuevas características de CLion 2019.2 (en inglés):
Eso es todo por una vez. ¡Gracias por leer hasta el final! ¡Preguntas, deseos, informes de errores y solo pensamientos expresados en los comentarios! Nosotros, como siempre, estaremos encantados de responder.
Su equipo JetBrains CLionEl impulso para desarrollar