Symbol grammar clarifications

[kritzcreek]

• Forbids empty or 'local' scheme (this removes ambiguities from the grammar)
• Unifies "any UTF-8" wording
• Specifies that identifiers that can be encoded as simple identifiers, have to be encoded as simple identifiers

Unfortunately I can not get the "build process" to work on my local machine.

Test plan

Added checks to the lint command for checking canonical identifiers and that parsing succeeds

[varungandhi-src]

We could add checks to scip lint

Sure, that'd be great.

[kritzcreek]

Sure, that'd be great.

Allright, I think that should work. PTAL

[varungandhi-src]

Added some minor non-blocking comments

[varungandhi-src]

Writing the long symbol names makes writing tests tedious, ideally we'd have a config object to disable some checks in tests. Maybe you can use a global variable here? It'd be off by default, and only one test would set it when checking for this code path. The other tests wouldn't need to worry about producing grammatically correct symbol names.

[kritzcreek]

What about introducing a constructor function for the tests? Something like sym("a") that expands to . . . . a#?

[varungandhi-src]

Maybe we can move that logic to makeIndex or parseSymbolInfo? In hindsight, I'm not sure if adding a DSL to specify relationships was a good idea, but I didn't want to have large chains of functions/methods when writing test cases. 🙈

[kritzcreek]

Okay I tried... but the DSL was a bit too much too handle so I went with the global as you suggested :D

[kritzcreek]

Noticed one more difference between the spec and scip-clang while writing some benchmarks. scip-clang will generate descriptors like my_func()., while the spec does not make the disambiguator in the parenthesis optional.

Spec issue, or scip-clang issue?

[varungandhi-src]

Noticed one more difference between the spec and scip-clang while writing some benchmarks. scip-clang will generate descriptors like my_func()., while the spec does not make the disambiguator in the parenthesis optional.

Hmm, I don't see why the disambiguator should be forced to be non-empty -- the rationale for having the disambiguator is that different disambiguator values can correspond to different method overloads (there is no further sub-structure inside it). An empty string is just another string, which is different from other non-empty strings. Unless someone has a compelling reason otherwise, I think we should allow the disambiguator to be empty.

[kritzcreek]

Unless someone has a compelling reason otherwise, I think we should allow the disambiguator to be empty.

@olafurpg @keynmol Thoughts?

[olafurpg]

+1 to allowing empty disambiguators