Improve AsArg<T> compile error messages by using marker traits
#1460
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.




What this PR does solve?
Diagnostic on
AsArg<T>was ultra-confusing because of associated item type mismatch. Given snippet such as:One was getting following compile errors:
Compile errors!
Which is very unhelpful and confusing.
After changes in PR following compile errors are being reported:
Even more compile errors!
In short – the old error is still being preserved, but we spawn additional one with explanation and link to docs while compiler generates proper, helpful resolution how to make problem go away. It also always spawn first, which is nice.
Other cases:
Everything else stays the same. GString/StringName/NodePath shows error coming from AsArg diagnostic if passing one as an another might result in non-obvious implicit conversion:
Problems considerations etc.
Marker trait is independent from AsArg – firstly because it must be (duh), secondly to prevent more type silliness, thirdly to make sure that AsArg behavior won't change.
labelandnotefields on#[diagnostic(...)]attribute are being swallowed by compiler. It is probably a bug I should report, albeit rust reference states that The hints provided by these attributes are not guaranteed to be used. (fun!).Arguably it makes signature a little more cluttered, but it is good enough tradeoff I think.
Idk if ShouldBePassedByRef is good enough name 🤷
Some generic APIs (notably Arrays) are not covered because we can't do so in easy and convenient way.
And finally – ByValue/ByOption/ByObject are not covered since I haven't seen a need to do so