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

function calls in compile {} blocks only accept variables as arguments #61

Open
driusan opened this issue Apr 24, 2019 · 8 comments
Open

Comments

@driusan
Copy link
Collaborator

driusan commented Apr 24, 2019

When there's a constant in a function call in a compile {} macro, the macro silently fails to compile because the func_call declaration in macros.yay only accepts variables as arguments.

This should probably be fixed (or at least documented.)

@ircmaxell
Copy link
Owner

This was an intentional choice (and yes, should be documented).

The reason is that an integer constant says nothing about the type. and adding support for casts to function arguments would increase complexity vastly. So instead, it's required to be in two lines:

compile {
    $value = (int64) 1;
    add($value, $value);
}

@driusan
Copy link
Collaborator Author

driusan commented Apr 24, 2019

I'm not sure that having the restriction prevents that, though, since the blocks can still reference things from the outer scope. ie. the macros happily generates code if you do:

$value = 1;
compile {
    add($value, $value);
}

@ircmaxell
Copy link
Owner

True, but that would result in a compile error, no?

@driusan
Copy link
Collaborator Author

driusan commented Apr 24, 2019

It didn't at 9116d50#diff-95e58c95e9cfcc3dc033dc60409d0f94R39, but I guess that might just mean we don't have a test testing the PHP memory allocator.

@marcioAlmada
Copy link

marcioAlmada commented Apr 26, 2019

@driusan @ircmaxell

When there's a constant in a function call in a compile {} macro, the macro silently fails to compile [...]

Just saw the thread. It's possible to make macros commit after a given prefix, like so:

<?php

$(macro) {
   sigil {
       $! // from now you should get a match or a ParserError error will be thrown 
       point of no $(either(return, chain(way, back))) or syntax error;
   }
} >> {
   // matched
}

sigil {
    point of no retrune or syntax error;
             // ^^^^^^^ intentional typo in the DSL /o\
}

Trying to expand this would result in:

Unexpected T_STRING(retrune) on line 13, expected T_RETURN(return) or T_STRING(way)...

I hope this helps to make your macros emit useful errors instead of failing secretly 😅

@ircmaxell
Copy link
Owner

Oh that's awesome!

@driusan
Copy link
Collaborator Author

driusan commented Apr 26, 2019

Should we close this now that it at least throws an error, or do you still want to document the reason for the restriction?

@ircmaxell
Copy link
Owner

Yeah, should add some docs...

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

No branches or pull requests

3 participants