Added some more keywords when checking for naming conflicts within generated code. These conflicts can happen in many different ways, so a comment was added describing each type of conflict.
One particularly nasty kind of conflict that I'd like to highlight, however, is when a user-defined message/field name clashes with local variable names or parameter names INSIDE OF a generated function implementation.
Luckily, it seems that the actual chance of this happening in practice at current might be relatively low, since:
Field names are prepended with the object variable name in Rust (i.e. msg.field instead of just field)
Message names (which become struct/enum names in Rust) would be shadowed by the local declarations.
I have not yet found any case where this would lead to a hard error, even with rather contrived examples. Nevertheless, this might depend heavily on whatever the current generated function implementations happen to be, and seems to be a source of rather insidious future errors if we aren't careful.
This will probably mean that unless we make some more comprehensive improvements/automation to this name collision system, keywords might have to be updated every time the generated code implementation is updated, even if the public API of said codegen is not affected.
Added some more keywords when checking for naming conflicts within generated code. These conflicts can happen in many different ways, so a comment was added describing each type of conflict.
One particularly nasty kind of conflict that I'd like to highlight, however, is when a user-defined message/field name clashes with local variable names or parameter names INSIDE OF a generated function implementation.
Luckily, it seems that the actual chance of this happening in practice at current might be relatively low, since:
msg.fieldinstead of justfield)I have not yet found any case where this would lead to a hard error, even with rather contrived examples. Nevertheless, this might depend heavily on whatever the current generated function implementations happen to be, and seems to be a source of rather insidious future errors if we aren't careful.
This will probably mean that unless we make some more comprehensive improvements/automation to this name collision system, keywords might have to be updated every time the generated code implementation is updated, even if the public API of said codegen is not affected.