Reorder compile errors for #[derive(GodotClass)]
#773
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
API docs are being generated and will be shortly available at: https://godot-rust.github.io/docs/gdext/pr-773 |
Bromeon
reviewed
Jun 22, 2024
Comment on lines
357
to
359
| // This needs to be separate from parse_fields because it needs to | ||
| // run before parse_struct_attributes since error from here demands | ||
| // a larger refactor than from there, so should be seen first. |
There was a problem hiding this comment.
Maybe split this sentence, it's a bit hard to understand. And feel free to use longer lines 😉
There was a problem hiding this comment.
What width do you prefer? This is already wider than the 72 characters I normally use
There was a problem hiding this comment.
Oh excuse me, I always forget that my editor opens narrower than 80 chars. I need to adjust that.
There was a problem hiding this comment.
Exactly, https://godot-rust.github.io/book/contribute/conventions.html:
Line width is 120-145 characters (mostly relevant for comments).
| } | ||
| } | ||
|
|
||
| /// Returns field names and 1 base field, if available |
There was a problem hiding this comment.
Suggested change
| /// Returns field names and 1 base field, if available | |
| /// Returns field names and 1 base field, if available. |
Comment on lines
353
to
355
| /// Fetches data for all named fields for a struct | ||
| /// | ||
| /// Errors if `class` is a tuple struct |
There was a problem hiding this comment.
Suggested change
| /// Fetches data for all named fields for a struct | |
| /// | |
| /// Errors if `class` is a tuple struct | |
| /// Fetches data for all named fields for a struct. | |
| /// | |
| /// Errors if `class` is a tuple struct. |
Comment on lines
314
to
328
| // Requires #[class(tool, base=EditorPlugin)]. | ||
| if !is_tool { | ||
| if base_ty != ident("EditorPlugin") { | ||
| return bail!( | ||
| attr_key, | ||
| "#[class(editor_plugin)] requires additional key `tool`" | ||
| "#[class(editor_plugin)] requires additional key-value `base=EditorPlugin`" | ||
| ); | ||
| } | ||
| if base_ty != ident("EditorPlugin") { | ||
| if !is_tool { | ||
| return bail!( | ||
| attr_key, | ||
| "#[class(editor_plugin)] requires additional key-value `base=EditorPlugin`" | ||
| "#[class(editor_plugin)] requires additional key `tool`" | ||
| ); | ||
| } |
There was a problem hiding this comment.
Maybe write a comment about the reasoning behind the order, to avoid that future refactors change it again. You can also link to this PR for details.
f0856b3 to
8c52f6b
Compare
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 {}
```
8c52f6b to
5bb8ff5
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
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
classmacro needs all three ofeditor_plugin,tool, andbase=EditorPlugin. I prioritized the message forbasebecause it is complex, implementingWithBaseFieldfor the struct, and could also involve non-local changes.toolis 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.
Addresses #545