Always map enry->bblfsh language names #251
Conversation
Signed-off-by: Alexander Bezzubov <bzz@apache.org>
| @@ -102,6 +102,8 @@ func (s *ServiceV2) selectPool(rctx context.Context, language, content, filename | |||
| return "", nil, err | |||
| } | |||
| language = lang | |||
There was a problem hiding this comment.
Does this one need a normalize call too?
There was a problem hiding this comment.
This one will already have it normalized after s.detectLanguage that calls normalize underneath
Co-Authored-By: bzz <bzz@users.noreply.github.com>
| // TODO(bzz): remove this as soon as language aliases are supported in bblfsh | ||
| // driver manifest. | ||
| func normalize(languageName string) string { | ||
| lang := strings.ToLower(languageName) | ||
| lang = strings.Replace(lang, " ", "-", -1) | ||
| lang = strings.Replace(lang, "+", "p", -1) | ||
| lang = strings.Replace(lang, "#", "sharp", -1) |
There was a problem hiding this comment.
This is an interesting way of solving this :)
Do you think making it an explicit map makes sense?
There was a problem hiding this comment.
This is an interesting way of solving this :)
Well, it's the smallest possible change consistent with current behavior :)
As this is a workaround, I would prefer to keep this change as least invasive as possible.
Given that we do not have much tests for it and that the current approach already works (TM) for API calls \wo the language - I would postponed changing implementation until proper alias support.
I think this would be out of scope of this PR/Issue - it only supposed to allow for consumption of enry names, as requested in original issue. And AFAIK such normalization is not even necessary for SupportedLanguages, as they already are a bblfsh names. In my understanding, as discussed elsewhere, the consensus is to add a workaround so clients can call |
|
OK, let's do it! |
This fixes https://github.com/bblfsh/client-go/issues/108
Before, we were mapping enry->bblfsh language name only in case it was detected by bblfshd itself (by calling to enry).
Now same change is applied on any user input, as the main use case for the clients is to detect language with Enry first and then call bblfshd with it, but language names are different (e.g
C#vscsharp)This is a workaround, until proper multiple
language_aliacesare supported by every driver in it's manifest.TEST PLAN:
$ bblfsh-cli -l 'C#'./some.cs