| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|/ /
| |
| |
| | |
closes #205
|
|/ |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
199: Use closing paren as a trigger character r=matklad a=kjeremy
This seems counter-intuitive based on the concept of "trigger character" but it provides a better function signature experience.
Co-authored-by: Jeremy A. Kolb <[email protected]>
|
|/
|
|
|
| |
This seems counter-intuitive based on the concept of "trigger character"
but it provides a better function signature experience.
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
188: Introduce `SyntaxErrorKind` and `TextRange` to `SyntaxError` r=matklad a=aochagavia
Co-authored-by: Adolfo Ochagavía <[email protected]>
Co-authored-by: Adolfo Ochagavía <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
194: Introduce FilePosition r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
|/ / |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
193: Inline modules r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|/ / |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
192: grammar: for predicates in where r=matklad a=matklad
closes #191
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/
|
|
| |
closes #191
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
184: Basic validation for character literals r=aochagavia a=aochagavia
As part of #27 I would like to add a validator for characters that detects missing quotes and too long characters. I set up a dummy implementation to get my feet wet, which generates errors whenever it finds a character.
Right now I have the following questions:
1. The `SyntaxError` type seems too basic to me. I think it would make sense to have a `SyntaxErrorKind` instead of a `msg` field (we can implement `Display` for it so you can generate the string if desired). It should also have a `TextRange` instead of a `TextUnit`, so you can support errors that are longer than one character. Do you agree?
1. I am manually checking whether the literal is a character (see the `is_char` method). Ideally, I would like to have a `LiteralKind` enum with variants like `Int`, `Float`, `Char`, `String`, etc. but it seems cumbersome to write all that by hand. Is there a way to specify this in `grammar.ron` so that the code is generated (the same way the `Expr` enum is generated)?
By the way, there seems to be no error reporting of panics inside the language server. When I was developing this PR I accidentally introduced a panic, which resulted in no syntax errors being shown. I knew something was wrong, because normally the vscode highlights syntax errors, but I didn't know it was caused by a panic.
Co-authored-by: Adolfo Ochagavía <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
187: Use Default everywhere r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ |
|
|
|
|
|
| |
alphabetical ordering is no more consistent, and much less useful then
the ordering which arises naturally when you add import.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
183: update salsa r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
182: Module source r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|/ |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
179: Remove DOC_COMMENT r=matklad a=kjeremy
Closes #166
Co-authored-by: Jeremy A. Kolb <[email protected]>
|
| |
| |
| |
| | |
Closes #166
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Pin to a specific toolchain version
Format checking functionality
Add a test to check the code formatting.
Remove macro_use attribute
|
| |
|
| |
|