Open Daniel-Cortez opened 3 years ago
Those missing specifier rules are causing YSI to stop building. I know I usually say that breaking YSI isn't a blocker for new compiler versions because it does a lot of silly things, but I'm not entirely sure this is a silly thing. If a forward declaration has stock
, it seems more sensible to me that the stock
rule is added to the function, regardless of what the definition then says. Leads to some interesting things like:
MAKE_STOCK(func);
func()
{
}
MAKE_STOCK(func); func() { }
Hmm... haven't seen such non-trivial application of keyword
stock
before (am I understanding this correctly thatMAKE_STOCK
is a macro that resolves into something likestock <name>()
?), but I guess it can be useful. I'll see if I can relax those new rules for that specifier.
EDIT: OK, done. Also rebased the changes to the current dev
so it would be easier to merge them.
This issue has been automatically marked as stale because it has not had recent activity.
To clarify why I added this new requirement for class specifiers in function implementations, my main concern was that in 3.10.10 (without this PR) class specifiers either had no effect in function declarations (see #624) or could even make the compiler generate invalid code (#621), so this new requirement was supposed to point users at the parts of their code that could cause problems in compiler versions up to 3.10.10.
@Y-Less I already removed that rule for specifier stock
, as it couldn't impact generated code (it only inhibits warning 204 in case the function is unused), but do you want me to remove it for static
and public
as well?
I'm actually not sure what the most sensible result is here. It seems there are equally good arguments for "all specifiers are additive", so this declares a static stock
function:
forward static Func();
forward stock Func();
Func()
{
}
"all specifiers must build", so only this is valid:
forward static Func();
forward static stock Func();
static stock Func()
{
}
"only the definition has specifiers":
forward Func();
forward Func();
static stock Func()
{
}
In that I don't think any one of them is obviously more "correct" than the others. Having said that, I'd vote for the first one as it gives the most options. Regardless of which is chosen the rule should be applied evenly to stock
, static
, and public
, not just having one special-cased as you did for stock
.
There is another option - remove old-style declarations, but that's a bigger change.
Or rahter that's a breaking change.
What this PR does / why we need it:
This PR does the following:
static stock
/stock static
in new-style function declarations (see #622).static
variables with a name starting with@
(see #623).static
on variables whose name starts with@
as an invalid combination of class specifiers (see #625).static Func2(); // Class specifier "static" is introduced. forward stock Func2(); // Class specifier "stock" is introduced; now the definition is required to have // both keywords "static" and "stock". stock static Func2(){} // OK (both class specifiers "static" and "stock" are in place).
__pragma
being expected twice in function/variable declarations starting with keywordspublic
,static
andstock
.Which issue(s) this PR fixes:
Fixes #621, #622, #623, #624, #625, #635
What kind of pull this is:
Additional Documentation: