You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, symbol kinds are parsed by comparing the kind string against a list of known symbol kinds, first as a whole and then with the first component discarded. However, this relies on the assumption that the first component of a symbol kind is a language identifier (e.g. `swift.func`). To prevent accidental loss of data, we should figure out a way to parse symbol kinds by taking their interface language into account.
The main problem here is the structure of the Decodable protocol: Each type's implementation is run in isolation, without taking into account the rest of the data being decoded. This will need to be handled somehow if we want to handle this.
The text was updated successfully, but these errors were encountered:
Additional Detail from JIRA
md5: a769a8f20a3a2a1a27d0ea7853785b56
Issue Description:
Currently, symbol kinds are parsed by comparing the kind string against a list of known symbol kinds, first as a whole and then with the first component discarded. However, this relies on the assumption that the first component of a symbol kind is a language identifier (e.g. `swift.func`). To prevent accidental loss of data, we should figure out a way to parse symbol kinds by taking their interface language into account.
The main problem here is the structure of the Decodable protocol: Each type's implementation is run in isolation, without taking into account the rest of the data being decoded. This will need to be handled somehow if we want to handle this.
The text was updated successfully, but these errors were encountered: