| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
|
| |
|
|
|
|
|
| |
Fixes #142
Fixes #146
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
167: Attempt to extract useful comments from function signatures r=matklad a=kjeremy
I'm trying to extract useful function comments for signature info. This will also be useful for hover. This is a WIP (and actually works pretty well!) but I don't think it's the right approach long term so some guidance would be appreciated so that we could also get comments for say types and variable instances etc.
Currently `test_fn_signature_with_simple_doc` fails due to a bug in `extend` but we probably shouldn't use this approach anyway. Maybe comments should be attached to nodes somehow? I'm also thinking that maybe the markdown bits should live in the language server.
Thoughts?
Co-authored-by: Jeremy A. Kolb <[email protected]>
|