The grow_stgbuffer() function, which grows the staging buffer, was
not updating the buffer size after reallocating the buffer itself.
This caused lots of reallocations because stgwrite() calls this
function for every character (!).
This also decreases compile times by ~20% (from 10s down to 8s in
my setup).
The get_string() function becomes a major bottleneck (around 80% of
the time) when debug info is on because it uses a linked list for
storage and it's mostly called in for loops iterating over the whole
list by index. That's a quadratic complexity.
This patch rewrites all stringlist functions to use an array instead
of a linked list. It decreased my test script's compile time from 84s
to 10s, or by 730%(!). The script is just 100,000 lines of print()
statements. If debug info is turned off the times are the same for both
implementations.
They are useful most of the time but also a pain in the ass if you have
multiple files with the same name but in different directories (e.g. YSI).
Even worse, they didn't work with non-native directory separators in
#include directives, but that actually turned out to be useful and helped
defeat the first bug!
See issue #6.
This fixes a bug where if you use '/' in an #include directive on Windows
the _inc_XXX symbol will contain not only the file name but also its path
as the compiler didn't count '/' as a path separator.
This patch introduces a new built-in constant called "__line" that is set
to the current line number during compile time. I've taken the code from
Pawn 4.0 though I'm pretty sure it was implemented prior to 4.0 as I've
seen __line mentioned in the language documentation for 3.x.
Make it possible to specify multiple warning numbers in #pragma warning
enable/disable. The values must be separated with commas (possibly with
whitespace in between).
This pragma lets you to enable or disable a specific warning by its
unique number (same as in error messages).
Syntax: #pragma warning (push|pop|enable XXX|disable XXX)
#pragma warning push - save current warnings
#pragma warning pop - restore warnings
#pragma warning enable XXX - enable warning XXX
#pragma warning disable XXX - disable warning XXX
When applied to a function #pragma naked merely disables the "should return
a value" warning for the function. It's intended to be used with functions
that return a value via #emit instead of the normal return statement.
This pragma works only on function definitions, not declarations. It's also
pretty stupid - the function may be defined way after this directive and it
won't stop on things coming in between.
For example, here all declarations between #pragma naked and f() are
effectively ignored:
#pragma naked
new x; // ignored
forward g(); // ignored
native n(); // ignored
f() {
// f() becomes naked
}
Note that #pragma naked does not affect generated code in any way, unlike
e.g. __declspec(naked) or __attribute__((naked)) in C/C++ where the compiler
omits the code for the prolog and epilog.
Make the assembler fail with a fatal error 104 "invalid assembler instruction"
if met an unknown instruction. It won't tell a correct line number though.
This hopefully fixes a bug where code for a custom assignment operator
wasn't being generated because the compiler thought that it's not used
but it still generated a call (which resulting in infinite recursion).
It happened only if some function returned a tagged result and wasn't
forwarded before its first use. Interestingly the compiler didn't issue
a reparse when it encountered the forward declaration and no warning
was printed. Perhaps the authors forgot to do this when they were adding
the forward syntax (it certainly was added after what is now called
"old-style prototypes").
See 8) here: http://forum.sa-mp.com/showthread.php?t=355877
--------- test code --------
#include <a_samp>
_:operator=(Taggg:a)
{
return _:a + 5;
}
main()
{
new a = d();
printf("%d", a);
}
forward Taggg:d();
Taggg:d()
{
return Taggg:5;
}
----- end of test code -----
This fixes a bug where returning a string from a variadic function caused
an invalid memory access error during runtime. It seems like they forgot
to update existing string return code for variadic functions.
See 11) here: http://forum.sa-mp.com/showthread.php?t=355877
--------- test code --------
native print(const s[]);
stock f(...)
{
new a, b, c;
new str[] = "hello";
return str;
}
main() {
print(f(1, 2, 3));
}
----- end of test code -----
This fixes a bug where the compiler generated incorrect addresses for
functions in #emit code if they were defined after the point of use.
For example, you couldn't reliably get the address of a function with
"#emit CONST.pri XXX" unless you make sure that XXX is defined before
the function in which you have you are referencing it.
Now the resolution of the function's address is deferred until assembling
phase (as with CALL), and the assembler is guaranteed to see all symbols
with their final addresses. To distinguish between functions and numeric
operands I added a '.' (period) in front of function names for both #emit
and normal calls.
See also 5) here: http://forum.sa-mp.com/showthread.php?t=355877
--------- test code --------
#include <a_samp> // DO NOT REMOVE THIS
main() {
#emit const.pri foo
}
stock foo() {
printf("Hello, World!");
}
----- end of test code -----
It is possible to use natives in any instructions and their name should
evaluate to a native table index. But the patch in the previous commit
(bb4163ea456fab54385f7310b4e20949cda0aaa6) affected only SYSREQ.C
instructions, thus using natives with other instructions (for example,
with CONST.pri) would still result in an incorrect index.
This commit fixes a bug where the compiler generated incorrect native
index in assembly code for natives invoked via #emit sysreq.c and not
called elsewhere with the normal syntax.
See 4) here: http://forum.sa-mp.com/showthread.php?t=355877
--------- test code --------
native print(const s[]);
native printf(const format[], ...);
main() {
new string[] = "hi there!";
printf(string);
#emit push.adr string
#emit push.c 4
#emit sysreq.c print
#emit sysreq.c printf
#emit stack 8
}
----- end of test code -----
This fixes a crash when calling a function with the CALL instruction in #emit.
Instead of merely writing a symbol's address to the .asm file we check
if we are in a CALL instruction, and if so we output the function's name
rather than its address.
See 7) here: http://forum.sa-mp.com/showthread.php?t=355877
--------- test code --------
foo() {}
main() {
#emit call foo
}
----- end of test code -----
This fixes a crash during compile-time when returning a string or array
literal from a function. Now the compiler will give an error instead.
See 1) here: http://forum.sa-mp.com/showthread.php?t=355877
--------- test code --------
native use(...);
return_string() {
new string[] = "string";
return string;
}
return_string_literal() {
return "string"; // error 029: invalid expression, assumed zero
}
return_number() {
return 0;
}
main() {
new n = return_number(); // OK
new s[100];
s = return_string(); // OK
s = return_string_literal(); // error 033: array must be indexed (variable "s")
use(n, s);
}
----- end of test code -----
This fixes a crash that occurs if a global variable is initialized
with the result of a function call.
See 3) here: http://forum.sa-mp.com/showthread.php?t=355877
--------- test code --------
native use(...);
f() {
return 0;
}
new x = f();
main() {
use(x);
}
----- end of test code -----
The ':' symbol was not recognized as a separator in stringize mode
so you always got a weird compile error with a code like this:
(condition) ? "yes : "no"
error 001: expected token: "-string end-", but found "-identifier-"
See 2) here: http://forum.sa-mp.com/showthread.php?t=355877
Test code:
native print(const s[]);
main() {
new a = 5;
print((a == 5) ? "is five" : !"is not five");
print((a != 5) ? !"is not five" : "is five");
}
This fixes the "possibly non-terminated string" error when declaring an
array of packed strings (unpacked strings worked OK).
Test code:
new x[][] = {
!"hello",
!"world"
};
main() {
printf("%s", x[0]);
}
