You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 15, 2022. It is now read-only.
Through some examinations in the code, I’ve seen that the way functions are captured and tokenized in the current implementation makes kind'o sense but very problematic at the same time.
Basically it does it like this (I’m simplifying unrelated details here):
Assumes words followed by a “(” as functions and treats them differently according to their location in the code.
If they are outside curly braced blocks “{}” it treats them as function declarations/implementations and apply special tokenizing which is to consume until a “}”(for a function implementation) or “;”(for a function declaration).
If they are inside curly braced blocks “{}” it treats them as “function calls” and has a different tokenizing implementation (which could and should be improved – but does not play a role at the issue at the moment).
At first all these may make sense according to the c-programming principals… but if you think twice it is quite problematic for macros (especially outside “{…}” blocks at the moment)…
Firstly (details simplified) a word followed by a “(” can also be a macro with variables rather than a function.
The problem is that it matches the regex used for function declarations/implementations in the current implementation of the grammar but unfortunately a macro with variables does not necessarily has to end with a “;” or “}” (it can either be a macro inside another macro or have the “;” present in its definition).
In such situations the meta.function scope floods until it finds an unrelated “;” or the end of the document.
When using multiple lines things can get even worse with flooding of the meta.parens scope.
SOLUTION:
A first idea of creating more scopes like meta.macro to consume all word() patterns that doesn’t have a following “;” or “{}” can be attractive but we still should not assume for the remaining ones to be functions!
Let me give a hypothetical example: SCOPE declare(struct Names* names, FirstName f_name, SurName s_name);
The above line looks exactly like a function declaration that returns a typedef of SCOPE.
But in its context...:
…it actually is a macro that evaluates to the declaration of another function with the given return value and name, and conditionally a local one or an external one: struct Names* names(FirstName f_name, SurName s_name);
…or… extern struct Names* names(FirstName f_name, SurName s_name);
This kind of code may seem to you unusual but infact it is being used very often in multi-platform development headers.
So we should assume such patterns neither as macros nor functions.
My humble suggestion is to scope and tokenize functions/macros beginning at “word(”(details simplified) and ending at “)” and leave the following {} block or “;” as optional to the coder.
That would eventually solve this issue and following issues are all related to this: #186 , #185 , #173 , #160 , #152 , #111 , #75
I can write a re-implementation for this as soon as my last PR 188 gets approved. Thanks.
The text was updated successfully, but these errors were encountered:
Through some examinations in the code, I’ve seen that the way functions are captured and tokenized in the current implementation makes kind'o sense but very problematic at the same time.
Basically it does it like this (I’m simplifying unrelated details here):
At first all these may make sense according to the c-programming principals… but if you think twice it is quite problematic for macros (especially outside “{…}” blocks at the moment)…
Firstly (details simplified) a word followed by a “(” can also be a macro with variables rather than a function.
The problem is that it matches the regex used for function declarations/implementations in the current implementation of the grammar but unfortunately a macro with variables does not necessarily has to end with a “;” or “}” (it can either be a macro inside another macro or have the “;” present in its definition).
In such situations the meta.function scope floods until it finds an unrelated “;” or the end of the document.
When using multiple lines things can get even worse with flooding of the meta.parens scope.
SOLUTION:
A first idea of creating more scopes like meta.macro to consume all word() patterns that doesn’t have a following “;” or “{}” can be attractive but we still should not assume for the remaining ones to be functions!
Let me give a hypothetical example:
SCOPE declare(struct Names* names, FirstName f_name, SurName s_name);
The above line looks exactly like a function declaration that returns a typedef of SCOPE.
But in its context...:
…it actually is a macro that evaluates to the declaration of another function with the given return value and name, and conditionally a local one or an external one:
struct Names* names(FirstName f_name, SurName s_name);
…or…
extern struct Names* names(FirstName f_name, SurName s_name);
This kind of code may seem to you unusual but infact it is being used very often in multi-platform development headers.
So we should assume such patterns neither as macros nor functions.
My humble suggestion is to scope and tokenize functions/macros beginning at “word(” (details simplified) and ending at “)” and leave the following {} block or “;” as optional to the coder.
That would eventually solve this issue and following issues are all related to this:
#186 , #185 , #173 , #160 , #152 , #111 , #75
I can write a re-implementation for this as soon as my last PR 188 gets approved. Thanks.
The text was updated successfully, but these errors were encountered: