[Semantic API] Service Symbol is not visible in Semantic Model

[rasika]

With the current design decisions of the Semantic-API, we cannot retrieve a symbol for the Services defined in the source file. While the Syntax-API node for the service seems to be an alternative, it is unable retrieve following information through the ServiceDeclarationNode node.

@pubudu91 @hasithaa please share your ideas on this.

1. Service is a documentable construct. Unable to get parsed documentation MarkdownDocAttachment/BallerinaDocumentation in Service Symbol ? - this is required for the CodeActions
2. Unable to get Type Descriptors of the service level path parameters? - this is required for the code completion suggestions and code actions.

Related issue #27493

[pubudu91]

For 1) I think we would need a symbol to be able to provide that given that that's the model we have followed for other documentable constructs. I guess it would be possible to provide an anonymous/unnamed symbol for service decls if we want to. But a concern I have regarding doing that is for the symbol() method which takes the position as an arg, what should we give as the position? Or should this be "invisible" to the symbol() API (i.e., can't be looked up by position), but can be accessed through APIs such as moduleLevelSymbols()? Or if you have a module symbol, maybe through an API like module.serviceDeclarations()?

For 2) didn't quite get what you meant by "type descriptors of the service level path parameters". Is it the type descriptor in the following?

service-decl :=
   metadata [isolated-qual]
   service [type-descriptor] [attach-point] on expression-list object-constructor-block

If so, this should be available in the symbol, should we decide to provide a symbol for service decls.

[rasika]

1. Yes, if we agree to support service symbol we can decide the implementation details later.
2. I was referring resource-path-segment-params for the attach-point of the service. Seems only resource-path-segment-name are allowed.

[rdhananjaya]

I think something like module.serviceDeclarations() is suitable for service declarations. Look up by position is also fine but I can't think of a use case for this, in the same time I don't find any reason to make it invisible too though.

[rasika]

We depend on syntaxTree nodes only to find relevant positioning details to invoke Semantic-API. I am afraid that we can fall back between Parser-API and Semantic-API here-and-there just to support Service construct. If a Symbol requires a name; considering the current implementation can't we use serviceNameLiteral as the name?

[pubudu91]

The with that is serviceNameLiteral corresponds to the attach-point of a service decl, which happens to be optional. Adding a method to the module symbol to get the service decls of that module sounds appealing. Also, can also maybe allow looking up the service symbol using the service decl syntax node, now that we have the overloaded version of symbol() which takes syntax tree nodes.

[pubudu91]

Planning on adding a symbol for service decls. The design would be as follows. WDYT?

[pubudu91]

The behaviour of this symbol would be a bit different from other regular symbols. This would not be visible through the symbol(document, pos) and visibleSymbols() methods. To get a list of symbols for service decls in the module, one would have to call moduleSymbols() and filter the service decl symbols. Additionally we can consider returning this symbol through symbol(node) method as well.

[pubudu91]

@hasithaa @rasika @rdhananjaya @prabushi

[rasika]

I am -1 to differ behavior of the apis for service decl symbols 😞. @pubudu91 regarding the symbol(document, pos) call; are we not having a location for service-declr-symbol?

[pubudu91]

It's not exactly differing the behaviour though. Currently, that's the same case for type descs such as records and objects. The issue with symbol(doc, pos) is that it's a cursor position that it takes, not a range. For other module level symbols, since they are named, we always associate the cursor position as any position within the name. So for constructs like service decl, record and object typedescs, not the case since they have other constructs with symbols nested within them. I suppose the starting pos of the construct itself would make some sense

[rasika]

@hasithaa @pubudu91 can we use the same approach that being used for distributed tracing in PR #28776 to get service name?

[pubudu91]

Had a discussion with @hasithaa @nadeeshaan and @rasika regarding the above mentioned design and decided to proceed with it. The methods in SemanticModel which supports this symbol would be symbol(Node node) and moduleSymbols(). Decided to restrict the symbol(Document srcFile, LinePosition pos) to returning symbols which are associated with an identifier.

Created the following to track a further improvement to these type of symbols: #28854

[pubudu91]

Hi all, a slight change in the design. Note the change to typeDescriptor() and the addition of two new methods.