eolian: fix the nonsensical semantics for variables

Both variables and constants can have extern on them (it means the same thing
as in types, they won't get generated in C). This is different from the previous
semantics which only allowed extern on globals, which makes no sense.

Both globals and constants are allowed to have a value (previously only
constants were); constants are required to have a value. Globals having
a value is just a convenience for initialization during source generation.
This is unlike the previous behavior, where the value was optional for both
globals and constants and only allowed when not marked extern, which makes
no sense either.

Obivously, even when globals have a value, they're not allowed to be used
in expressions, as they cannot be evaluated at compile time (they're mutable).
This commit is contained in:
Daniel Kolesa 2016-10-19 15:24:26 +02:00
parent 73095ad7ad
commit 8c9fa54be4
1 changed files with 6 additions and 6 deletions

View File

@ -1006,19 +1006,15 @@ parse_variable(Eo_Lexer *ls, Eina_Bool global)
{
Eolian_Declaration *decl;
Eolian_Variable *def = calloc(1, sizeof(Eolian_Variable));
Eina_Bool has_extern = EINA_FALSE;
Eina_Strbuf *buf;
ls->tmp.var = def;
eo_lexer_get(ls);
if (ls->t.kw == KW_at_extern)
{
if (!global)
eo_lexer_syntax_error(ls, "extern constant");
has_extern = EINA_TRUE;
def->is_extern = EINA_TRUE;
eo_lexer_get(ls);
}
def->type = global ? EOLIAN_VAR_GLOBAL : EOLIAN_VAR_CONSTANT;
def->is_extern = has_extern;
buf = push_strbuf(ls);
eo_lexer_context_push(ls);
FILL_BASE(def->base, ls, ls->line_number, ls->column);
@ -1035,7 +1031,11 @@ parse_variable(Eo_Lexer *ls, Eina_Bool global)
check_next(ls, ':');
def->base_type = parse_type(ls, EINA_FALSE, EINA_FALSE);
pop_type(ls);
if ((ls->t.token == '=') && !has_extern)
/* constants are required to have a value */
if (!global)
check(ls, '=');
/* globals can optionally have a value */
if (ls->t.token == '=')
{
ls->expr_mode = EINA_TRUE;
eo_lexer_get(ls);