compiler
compiler copied to clipboard
error unknown directive
Issue description:
Minimal complete verifiable example (MCVE):
main()
{
// This work
f(#AA);
// This give the error, unknown directive
f(
#AA
);
}
f(const a[]) {}
Workspace Information:
- Compiler version: 3.10.10
- Command line arguments provided (or sampctl version):
- Operating System: linux
You should append \ after f(
I'm not sure how to classify this, because the compiler is sort of right. #
at the start of a line is used for pre-processor directives, so that's how it is interpreted here. On the other hand, you can't have pre-processor directives in the middle of expressions.
You should append \ after f(
F(
"A",
#B,
"C"
);
I think this should work this way, once is valid.
Well, no. As eyeless mentioned, # at the start of a line is used for pre-processor directives, so that's how it is interpreted here.
If you really want to script that way you really should just append \
to tell the compiler that it's part of the same line (except on a new line).
I'm not sure how to classify this
Well, perhaps I can help by saying I would classify it as something inconvenient. I wouldn't say it's a bug tho;
#include <a_samp>
#include <YSI_Coding\y_va>
#pragma option -E+
main()
{
f(
"a%s%s",
#pragma option -E-
InvalidTag:"x",
#pragma option -E+
"c"
);
}
f(const s[], va_args<>) printf(s, va_start<1>);
It's an inconvenient script that makes little sense (I can't really think of a way where you would use a directive inside function parameters), but it is a very valid thing.
The only directives I've wanted mid-function are in some case like:
Function(
long, list, of, complex, parameters,
#if COMPILE_OPTION
1
#else
2
#endif
);
Yes, there are other ways of doing it, but its come up at least twice (in clearly more complex cases than this example).