Su código ya no se borra solo (1.60.10-1.60.11)

[Eslopes]

Correcciones de esta tanda, la mayoría nacidas de un informe concreto: se crea un procedimiento común, se guarda el formulario y el procedimiento desaparece.

1. Un procedimiento nuevo desaparecía al guardar

Guardar y Ejecutar barrían los procedimientos "huérfanos": aquellos cuyos controles referenciados ya no existen y a los que nadie llama. Un procedimiento que usted acaba de crear cumple la segunda condición por el simple hecho de ser nuevo: nadie llama a algo que hace un minuto no existía. Así que en cuanto un nombre de control de su cuerpo no resolvía, Guardar borraba el código antes de que usted terminara de escribirlo.

Ya nada borra un procedimiento salvo usted. Guardar y Ejecutar escriben lo que usted escribió. Borrar un control tampoco se lleva por delante un procedimiento común: borrar un control se lleva el código de ese control, que le pertenece, pero un procedimiento común es código aparte que solo lo menciona. Si un borrado deja un procedimiento apuntando a lo que ya no existe, el panel de Salida lo dice y el código se queda para que usted decida.

2. Borrar un procedimiento ahora pregunta

El botón de la papelera lo eliminaba en el acto, y desde el inspector de Ejecutar Formulario lo hacía sin pasar siquiera por la pila de deshacer. Ahora muestra qué va a destruir (el nombre y cuántas líneas de su COBOL), la opción por defecto es Cancelar, y se puede deshacer desde ambos sitios.

3. Un control dentro de un contenedor seguía siendo invisible

Un formulario es un árbol: un botón dentro de un GroupBox vive en los hijos de ese GroupBox. El análisis leía solo el primer nivel, así que un procedimiento que se dirigía a un control anidado parecía uno al que le habían borrado todos sus controles, y un procedimiento llamado desde el manejador de un control anidado parecía no tener quien lo llamara. El mismo defecto borraba enlaces de datos (data bindings) cuyo destino fuera, por ejemplo, un DataGrid dentro de un GroupBox: se perdía la configuración entera sin avisar.

4. Un bloque EXEC RUST dentro de TRY se compilaba en nada

El recorrido de sentencias tenía una rama comodín, de modo que nunca miraba dentro de TRY, CATCH, FINALLY, ON SIZE ERROR, INVALID KEY, ON OVERFLOW, AT END ni SEARCH ... WHEN. Un bloque escrito justo donde la guía recomienda ponerlo (dentro de un TRY, para poder capturar su fallo) se saltaba en silencio y luego fallaba en ejecución con "no compiled function", que parece un problema de compilación y no lo es.

La lista de sentencias hijas vive ahora en el AST como un match exhaustivo, sin comodín: una sentencia nueva que contenga otras sentencias no compilará hasta que se la declare, justo al lado de su definición.

5. Un elemento enlazado es ahora una referencia mutable

Estaba enlazado por valor, así que asignar a través del nombre no compilaba, aunque "*ws_count += 1;" sea la convención propia de este lenguaje desde antes. Ahora el bloque recibe &mut T, y el valor en propiedad se queda en la función generada para que se devuelva al puente incluso si el cuerpo entra en panic.

6. eframe y egui se prometían pero no se enlazaban

El análisis aceptaba "use eframe::egui;" en un bloque, pero el manifiesto solo enlazaba esas dependencias en programas con formularios. Un programa de consola que las usara fallaba con "unresolved import 'eframe'": un mensaje correcto para una promesa que habíamos roto. Cualquier programa con un bloque las enlaza ahora, que es justo lo que permite a un programa de consola abrir una ventana.

7. Un programa sin cambios se recompilaba en cada compilación

Cada compilación reescribía el Cargo.toml, el main.rs y el módulo de bloques generados, dándoles fecha nueva; la huella de cargo se basa en la fecha, así que reconstruía el crate del propio programa sin motivo. Ahora solo se escriben si su contenido cambió. Medido: la segunda compilación de un programa sin cambios compila 0 crates frente a 237 de la primera, y basta con editar el bloque para que vuelva a compilar 1.

Nota sobre el criterio

A partir de ahora, cuando un código sea inválido, inalcanzable o huérfano, se informa, nunca se elimina. Un heurístico que borra código está equivocado incluso cuando acierta, porque acertar el 95% de las veces sigue significando destruir trabajo en silencio.

Anthropic Claude Codex Agent