protoc: inconsistent name resolution behavior

[dsnet]

Consider the following proto file:

package foo.bar;
message M {    // declared as .foo.bar.M
    enum E {   // declared as .foo.bar.M.E
        M = 0; // declared as .foo.bar.M.M
    }
    optional M F1 = 1;
    extend M { optional string F2 = 2; }
    extensions 2 to 2;
}

There are two relative M references:

• optional M ...
• extend M { ... }

Both relative M references occur within the .foo.bar.M namespace.

Per the C++ scoping rules, the following absolute names should be tried in the following order:

• .foo.bar.M.M
• .foo.bar.M
• .foo.M
• .M

In our situation, both .foo.bar.M.M and .foo.bar.M are legal declarations.

However, the way resolution is handled is odd:

• For the case of optional M ..., it first finds .foo.bar.M.M, which is an enum value type. Since it's looking for an enum or message type, it ignore this. It continues on to then find .foo.bar.M. Since this is a message type, it returns that declaration.
• For the case of extend M ..., it first finds .foo.bar.M.M, which is an enum value type. Since it's looking for a message type, it throws an error complaining that it found the wrong type.

This is inconsistent. The relative name resolution logic should either:

• always ignore the declaration of the wrong type and keep searching
• always error when finding a declaration of the wrong type

What is the right behavior?

[ghost]

"always error when finding a declaration of the wrong type" seems like the more desirable behavior. At the minimum, it would highlight that there are some confusing types there, instead of magically resolve to some random type.

If we make it to always error, how many things will break?

[jhump]

FWIW, method input and output names behave the same as extendee -- resolution of these names does not skip over non-type elements as is done for field types.

[jhump]

Same goes for extension name resolution, when resolving option names. Though there is no "ResolveMode" that would work for this (i.e. there is no "LOOKUP_EXTENSIONS" value).

[jhump]

This is sort of related to #9550. Different root cause and symptom, but also about inconsistent behavior when it comes to resolving names from different contexts.

[github-actions]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

[github-actions]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please reopen it.

This issue was closed and archived because there has been no new activity in the 14 days since the inactive label was added.