Add type fields
#316
Add type fields
#316
Conversation
| var a = x is int; | ||
| // ^ type.builtin | ||
| var a = x is A; | ||
| // ^ |
There was a problem hiding this comment.
This is not highlighted due to #317.
| @@ -16,12 +16,11 @@ | |||
|
|
|||
| [ | |||
| (implicit_type) | |||
| (nullable_type) | |||
There was a problem hiding this comment.
I think this might have been a mistake in the query. I don't think we'd want to color System.Int32? differently than System.Int32 in the below:
void M(System.Int32? b, System.Int32 c) { }
There was a problem hiding this comment.
As I've said before, I'm not a big fan of making all elements in a simple list fields. The main reason is that it makes parse trees more verbose and more difficult to read, something one has to do quite often when developing queries. It also goes against my intuition that things are either like records (each field appears at most once) or like collections (all things are similar). I see that it does allow for blanket queries such as (_ type: (_)). And, given that @damieng agrees with this change, I'm not going to block it.
My experience is mostly with the parsing and tree-sitter side so I when it comes to fields and other magic to light up GH Semantic I'll defer to others. |
|
I've removed the two cases where field names were added in simple lists. I don't have a strong feeling about these, so let's go with the non questionable field names first, and then if we see value in having the others, we'll add them. I also added some more highlighting test cases to cover the type lists (base list, and type argument list). |
No description provided.