Repository navigation
Implement multi-language support - #130
Conversation
|
wondering about the common lexical scope and an option to have a lexer per entry rule |
78988e1 to
9f6d652
Compare
|
@cdietrich Thanks for the input. I plan to finish implementing this once #127 lands, since it refactors a lot of the lexer infrastructure. |
ssmifi
left a comment
There was a problem hiding this comment.
Looks solid, thanks. I have a couple of questions to get a better understanding before merging and some documentation seems to be stale.
sailingKieler
left a comment
There was a problem hiding this comment.
Thanks @msujew for this effort! Great step forward.
Actually, I doubt the necessity and benefit for the additional language build customization for the multi language aspect. Other concerns might justify that.
I left some comments inline.
The other aspect is the documentation of impact of multiple entry rules on the lexer.
That is something I didn't expect in the first place, and others (newbies) probably also don't. See also below.
|
|
||
| // LanguageSelector resolves a document URI to the index of the owning language | ||
| // (into the configured languages), or -1 if none match. | ||
| type LanguageSelector interface { |
There was a problem hiding this comment.
On the first impression this felt a bit over engineered to me.
After thinking about it for a moment or tow, I came to the conclusion that this mainly bridges the lack of multi-bindings in our dependency container, here, multiple DocumentSelectors, correct?
I would appreciate a corresponding hint on that here in the docs.
There was a problem hiding this comment.
Let's adhere the common pattern of naming this file doc.go.
//go:generate go run ./gen
can go to services.go, like in the other languages.
There was a problem hiding this comment.
Forgot about this one, changing it before merging 👍
72f6899 to
dd2fdc6
Compare
f9c1cd9 to
a42044f
Compare
Lotes
left a comment
There was a problem hiding this comment.
Great, that you have also added the multi-file support!
9a07595 to
a650095
Compare
There was a problem hiding this comment.
Quite impressive contributions Mark, great job!
However, the setup of the language selectors that sometimes are generated to services_gen.go and sometimes have been put to services.go caused quite some headache for me.
I've made a proposal inline to improve that situation.
1528f27 to
6c0e1a4
Compare
^ Conflicts: ^ cmd/fastbelt/generate.go ^ Conflicts: ^ internal/grammar/utils.go ^ parser/completion_parser.go
6c0e1a4 to
3665b17
Compare
sailingKieler
left a comment
There was a problem hiding this comment.
Looks very good to me 🚀
(I assume you wanna keep the name mentioned in https://github.com/TypeFox/fastbelt/pull/130/changes#r3879863202?)
3665b17 to
b8c7f63
Compare
Closes #96
Does as the title says, similar to how it is outlined in the issue:
fastbelt/cmdpackage adopters can use to write their own CLIs to generate Fastbelt code.LanguageSelectorservice that is used to determine during runtime what language a URI/document belongs to.multilangexample that shows that this is working as expected (including parser, lexer and completion tests).FYI, while this has a
Pluginsfield in the API, plugins aren't actually supported in this PR. This will need a follow-up.