Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parse use bounds (precise capture syntax) #252

Merged
merged 2 commits into from
Feb 28, 2025

Conversation

m4rch3n1ng
Copy link
Contributor

@m4rch3n1ng m4rch3n1ng commented Feb 18, 2025

fn capture(&self) -> impl Iterator<Item = usize> + use<'_> {}

currently tree-sitter-rust says that the use capture bound is a generic_type type_identifier, but after this it is a use_bounds use.

announced here, documented here and specified here and here.

@m4rch3n1ng m4rch3n1ng force-pushed the precise-capture-bounds branch 2 times, most recently from 489d164 to db24a34 Compare February 22, 2025 15:06
@m4rch3n1ng
Copy link
Contributor Author

m4rch3n1ng commented Feb 22, 2025

i realized that my first attempt didn't properly parse empty use<> bounds, and then i forgot that type identifiers are also allowed, but now it should work properly i think.

theoretically speaking this syntax also allows const generic parameters, but i couldn't find a way to disambiguate between these two, so i just left those to be parsed as type_parameter. while it's impossible to disambiguate a use<N, T> and figure out if N is a type or a const parameter, it should be possible to take a good guess for something like use<LEN, Type>, but i don't know how to do that. (apparently that is already actually something that editors do in their own highlights.scm queries.)

@m4rch3n1ng
Copy link
Contributor Author

one (hopefully) last quick comment: the reference calls this both precise captures and UseBounds. i initially chose the first one because that was how it was announced, but i think the latter name makes more sense. should i change it? or should i leave it as precise_capture?

@maxbrunsfeld
Copy link
Contributor

I agree with you that use_bounds makes more sense.

@m4rch3n1ng m4rch3n1ng force-pushed the precise-capture-bounds branch from db24a34 to 865f01c Compare February 27, 2025 21:17
@m4rch3n1ng m4rch3n1ng changed the title parse precise capture bounds parse use bounds (precise capture syntax) Feb 27, 2025
@m4rch3n1ng
Copy link
Contributor Author

m4rch3n1ng commented Feb 27, 2025

changed the name to use_bounds and rebased.

@m4rch3n1ng m4rch3n1ng force-pushed the precise-capture-bounds branch from 865f01c to 00b6772 Compare February 27, 2025 21:29
@m4rch3n1ng m4rch3n1ng force-pushed the precise-capture-bounds branch from 8d0d859 to d571acb Compare February 28, 2025 02:03
@m4rch3n1ng
Copy link
Contributor Author

rebased on master again and fixed one of the tests that i added here cause that used a type parameter

@maxbrunsfeld maxbrunsfeld merged commit 6e883a2 into tree-sitter:master Feb 28, 2025
4 checks passed
@m4rch3n1ng m4rch3n1ng deleted the precise-capture-bounds branch February 28, 2025 02:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants