Within erlex, the lexer and parser are generically named as :lexer and :parser. This generic naming has led to conflicts with other libraries that employ :lexer and :parser modules in their own implementations.
A particular example of such a conflict is the clash with the lexer and parser in the SPARQL.ex library. This issue came to my attention after extensive troubleshooting, highlighting the difficulty in diagnosing such conflicts.
Historically, in older versions of Elixir, the SPARQL lexer and parser seemed to be preferentially loaded, which led to concealed issues when using dialyxir. These issues typically manifested as legacy warnings, triggered by the unsuccessful use of the SPARQL parser in parsing Dialyzer data. Given that legacy warnings are also commonly produced for unsupported formats (notably, dialyxir currently has 74 issues related to legacy warnings), this underlying conflict between parsers remained unrecognized for a considerable duration.
The conflict became evident with recent changes in the compilation process introduced in Elixir 1.15. These modifications in module loading behavior brought the previously unnoticed conflict to light, where the erlex parser was unexpectedly employed in parsing SPARQL queries. Intriguingly, this issue did not arise consistently but only manifested from the second attempt after a recompilation and was still not immediately recognizable as a parser conflict, since the parser errors were translated to regular SPARQL.ex parser errors.
Although I have already addressed this issue in SPARQL.ex by adopting more unique names for the lexer and parser, I believe that a similar resolution should be implemented in erlex. Considering its widespread use, primarily as a transitive dependency of dialyxir, many projects may unknowingly be at risk of similar conflicts.
Within erlex, the lexer and parser are generically named as
:lexerand:parser. This generic naming has led to conflicts with other libraries that employ:lexerand:parsermodules in their own implementations. A particular example of such a conflict is the clash with the lexer and parser in the SPARQL.ex library. This issue came to my attention after extensive troubleshooting, highlighting the difficulty in diagnosing such conflicts.Historically, in older versions of Elixir, the SPARQL lexer and parser seemed to be preferentially loaded, which led to concealed issues when using dialyxir. These issues typically manifested as legacy warnings, triggered by the unsuccessful use of the SPARQL parser in parsing Dialyzer data. Given that legacy warnings are also commonly produced for unsupported formats (notably, dialyxir currently has 74 issues related to legacy warnings), this underlying conflict between parsers remained unrecognized for a considerable duration.
The conflict became evident with recent changes in the compilation process introduced in Elixir 1.15. These modifications in module loading behavior brought the previously unnoticed conflict to light, where the erlex parser was unexpectedly employed in parsing SPARQL queries. Intriguingly, this issue did not arise consistently but only manifested from the second attempt after a recompilation and was still not immediately recognizable as a parser conflict, since the parser errors were translated to regular SPARQL.ex parser errors.
Although I have already addressed this issue in SPARQL.ex by adopting more unique names for the lexer and parser, I believe that a similar resolution should be implemented in erlex. Considering its widespread use, primarily as a transitive dependency of dialyxir, many projects may unknowingly be at risk of similar conflicts.