You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This addresses an issue where relatively major compile errors would be
shown only after smaller errors were fixed. This is problematic since
fixing a large error has a high chance of invalidating the work for the
small error.
In my eyes, the error priority goes with each of these, in order.
1. Scale - if the error requires a larger change
2. Locality - if the error requires changes away from the error site
3. Complexity - if the change for the error carries a lot of meaning
There were two main cases addressed, unsupported tuple structs and
editor plugins. Replacing a tuple struct with a regular struct is a
very large change. It would require rewriting the struct definition and
possibly also distant trait definitions. Because of the large scale, I
made the lack of tuple struct support the highest priority error.
Editor plugins can error a lot because the `class` macro needs all three
of `editor_plugin`, `tool`, and `base=EditorPlugin`. I prioritized the
message for `base` because it is complex, implementing `WithBaseField`
for the struct, and could also involve non-local changes. `tool` is
easy to fix, so doesn't need priority.
Since this isn't easily testable, here's a couple cases that gave errors
in the wrong order before.
```rs
// fix the tuple struct, and then an error would occur on rename
\#[derive(GodotClass)]
\#[class(rename = "Not an identifier")]
struct TupleStructErrorsBeforeRename(String);
// the error is no base, then no tool, and last nonsense is invalid
\#[derive(GodotClass)]
\#[class(editor_plugin, nonsense)]
struct EditorPluginNoBaseErrorsBeforeNoTool {}
```
0 commit comments