-
Notifications
You must be signed in to change notification settings - Fork 1
Define text format #14
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
Comments
Interesting idea! I didn't even consider that we would have that option. But it would certainly make those annotations much more readable than the cryptic string encoded binary data. I could imagine something like this:
I'm not sure if the It would also allow for better readability of special values
|
@ecmziegler while it can be a good idea to define a more "structured" syntax for the text format, it should have a different identifier than The intention of the even for branch hinting, the idea was to potentially add something like But this means adding extra logic for the parsing specifically for it in the tools, while the metadata.code syntax is simpler and general. |
@yuri91 I would see this as an alternative way to describe it. The binary syntax is still allowed. But of course, it means that tools which don't understand this format, cannot parse it. On the other hand, tools that don't understand the alternative identifier also wouldn't be able to parse it, so nothing is won by it using a different one. Round trips also just work for simple cases. If e.g. a tool decides to reorder function indices, a lot of the annotations will be garbled anyway. Realistically, a tool that doesn't understand an annotation is likely better off dropping than keeping it. |
as long as there is no ambiguity, sure, the same identifier could be used with different syntactical variants. And about the round-tripping: absolutely, it has limited uses without any knowledge of the semantics of the section, but I would argue that being able to convert to text even just for reading and/or doing a minor tweak to a module is valuable. It was especially crucial for adding some form of testing in the official test suite. |
Yes, conversion to/from text should be possible in a straightforward way. The way I see it, we could make
and
mean the same thing. |
One thing we should update in this proposal is spec text for the syntax of function annotations. @yuri91 mentions in the previous discussion that branch hinting added syntax for instructions, and this is the first proposal that adds functions. I think all we need is one or two lines of text that say something similar for functions as for instructions, namely, ".. function annotations are considered attached to the first function that follows them .." |
In discussion it was clarified that the custom annotations spec says nothing about how future proposals use annotations in the text format. We may define non-spec conventions, but I think that means that this proposal needs to define how the hints appear in the text format.
The text was updated successfully, but these errors were encountered: