No way to create symbol representing private setter name

[sjindel-google]

According to the documentation, the constructor for const Symbol() does not accept private names. The only other way to construct a constant symbol is via the #... notation, e.g. #_x. However, this doesn't work for names of setters, e.g. _x=, because #_x= isn't syntactically correct.

How can the name of a private setter be expressed as a constant symbol?

For reference, I'm updating the mock_writable_final_private_field_test.dart which is currently exploiting an incorrect behavior in the VM to do this. The VM currently allows creating a private symbol in this way, but it is not correctly mangled.

[lrhn]

I'm not sure there is a way.

Our Symbol story is somewhat incomplete.
The const Symbol constructor cannot create private names since it has no library reference.
The #_foo literals are limited to operators and (qualified) names. It's unspecified whether #_foo.bar or #foo._bar are mangled or not (well, actually, it's specified to not be mangled, but the implementations disagree).

So, we cannot create a private setter symbol, and currently we cannot create a symbol for foo._bar that is mangled, and we can't make a symbol for _foo.bar that is not mangled (it is a valid library name, and library names are not mangled).

We can allow = after symbol literals. We already allow #[]= as a symbol, and I don't see any syntactic issues with allowing = after #foo or #foo.bar. It's not an assignable expression, and we will still parse #foo==#bar as a == operator (symbol literals allow whitespace between tokens, so = vs == would be tokenized the usual way, with the longer token winning).
We probably should.

To handle the other cases, we could change the rules so that #foo._bar is mangled if any identifier in the sequence is private, and const Symbol("_foo.bar") is allowed - we currently throw if the input starts with _.
We could even allow any string as input to the Symbol constructor. Most of them just cannot refer to program entities.

That would allow all the possible combinations of symbols that are currently being used, except perhaps #_foo._bar where foo and bar are private in different libraries. That can occur in reflection where qualified identifier symbols are used as "paths" representing both a class name and a member name. If the class is private and it mixes in a mixin from a different library which has a private member, then the qualified name of that would not be representable.

[sjindel-google]

To handle the other cases, we could change the rules so that #foo._bar is mangled if any identifier in the sequence is private, and const Symbol("_foo.bar") is allowed - we currently throw if the input starts with _.

The VM currently doesn't throw in this case, but it also doesn't mangle the symbol either. I think mangling the input to const Symbol() is the best solution here to achieve consistency.

This is not directly related, but in obfuscation, do you think we should obfuscate symbols created via const Symbol()? Currently we obfuscate constant symbol literals but not constant symbols via const Symbol() or symbols created dynamically via new Symbol() (the last is obviously infeasible).

[lrhn]

We should never mangle for a const Symbol(...) invocation. It is a normal constant invocation, it should be canonicalized globally if you pass the same argument, and it should behave the same for new Symbol(...), except without the canonicalization.
The only thing special about the const Symbol constructor is that it is intended to validate the input. We should probably just stop doing so. The inputs that are currently invalid will just not create a symbol that is equal to any symbol representing a source name.

The only way to make a constant private (mangled) symbol is a symbol literal. (The other ways to create non-constant private symbols are dart:mirrors and noSuchMethod).

[sjindel-google]

Ok, then the original problem remains, because a mangled private symbol is not equal to a non-mangled symbol with the same identifier.

The use case is recognizing a private setter within a NSM implementation, for example the test language_2/mock_writable_final_private_field_test.

[mraleph]

@lrhn @leafpetersen @eernstg there are few bugs essentially about the same thing in the tracker. Could language team make a decision about this and deduplicate all bugs into a single place?

[leafpetersen]

Closing this in favor of the language tracking issue here.