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
The following macro invocation seems to contain a valid Java class declaration, but duchess fails to parse it and the error message doesn't clearly explain why.
java_package!{
package foo
public interface Baz{}
public interface Bazz{}
public class Bar implements Baz, Bazz{}}
error: unexpected token `... ss Bar implements Baz <<< , >>> Bazz {}` at offset 33, expected one of `["r#/"[./]/"#"]`
The reason is that the parser currently expects a fully-qualified class name after the extends, and a fully-qualified name contains at least a dot. The fixed version of the macro invocation is the following:
java_package!{
package foo
public interface Baz{}
public interface Bazz{}
public class Bar implements foo.Baz, foo.Bazz{}// <-- Note the "foo."}
The error message above is one of the firsts that a user will encounter. Duchess should either report a more helpful error message, or the parser should accept the first code snippet. Note that a similar issue occurs when declaring the type of a field, a method parameter, or a return type. It would be great if a fix for this issue also addressed those cases.
The text was updated successfully, but these errors were encountered:
fpoli
changed the title
Confusing error when the parser expects a fully-qualified class name
Confusing error when a fully-qualified class name is expected
Jun 6, 2023
The following macro invocation seems to contain a valid Java class declaration, but duchess fails to parse it and the error message doesn't clearly explain why.
The reason is that the parser currently expects a fully-qualified class name after the
extends
, and a fully-qualified name contains at least a dot. The fixed version of the macro invocation is the following:The error message above is one of the firsts that a user will encounter. Duchess should either report a more helpful error message, or the parser should accept the first code snippet. Note that a similar issue occurs when declaring the type of a field, a method parameter, or a return type. It would be great if a fix for this issue also addressed those cases.
The text was updated successfully, but these errors were encountered: