Skip to content
This repository has been archived by the owner on Dec 15, 2022. It is now read-only.

Scope floods because of macros being matched as functions. #189

Closed
alpyre opened this issue Dec 16, 2016 · 0 comments · Fixed by #206
Closed

Scope floods because of macros being matched as functions. #189

alpyre opened this issue Dec 16, 2016 · 0 comments · Fixed by #206
Labels

Comments

@alpyre
Copy link
Contributor

alpyre commented Dec 16, 2016

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.
floodingfunction

When using multiple lines things can get even worse with flooding of the meta.parens scope.
parensflood

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...:

#define declare(func_id, param1, param2) func_id(param1, param2)
#if NATIVE == FALSE
  #define SCOPE extern
#else
  #define SCOPE
#endif

…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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants