-
-
Notifications
You must be signed in to change notification settings - Fork 570
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
Add a file tag parser to core:odin/parser #4009
Conversation
50e8f42
to
3f700e2
Compare
Actually I see that parsing project names is incorrect because it doesn't allow for groups |
This looks like a good addition, we did add Also about your last comment on project names, I honestly have no clue what that even does 😆 , I do think it should be handled the same way as the cpp parser if possible. |
Additionally, some of these constants may make a lot of sense in These 2 bit sets: https://github.com/odin-lang/Odin/pull/4009/files#diff-7f423f935d8ea5cace97cde5364d6c20ac9f5f09680eba4a274891039b0a83f8R17-R18 And these LUTs and The LUTs could also be removed entirely and replaced with reflection, but I am not for or against it. @require_results
get_build_os_from_string :: proc(str: string) -> Odin_OS_Type {
fields := reflect.enum_fields_zipped(Odin_OS_Type)
for os in fields {
if strings.equal_fold(os.name, str) {
return Odin_OS_Type(os.value)
}
}
return .Unknown
} |
I've just been told what they are for and having groups does make sense. Let's say you have 3 projects |
thanks for the review
The way they are being handled in cpp parser is pretty simple Also what I meant with my last comment was that the particular syntax of For example here, the fist one will match either foo or bar, and the second will match none because a project cannot be named both foo and bar.
And here there will be no difference between the two:
Also combining negative with positive names doesn't have much sense:
Especially this:
While all of the above parse with no errors. So theoretically the parser could still return project names as
Thanks, I had no idea about this. |
Ah I see, thanks for the clarification, the way you do it here looks fine then. |
3f700e2
to
a28d574
Compare
Having a way to parse
+build
,+private
and other flags will be useful forols
and possibly other meta-programming tools.I tried to copy the implementation from the cpp parser, but the important difference is that the parser in the compiler parses the tags to match the current target and stop parsing if not matched, when this added parser builds a custom structure to let the user handle the tags as needed. For example in ols we probably want to parse all of the files, but use the build tags to decide when to not show the autocomplete.
Currently the implementation is missing error handling and the
+vet
tag.Also it is not integrated into the
parse_file
proc, and provided as a separate helper.