@:meta/@meta create "scopes" around variable declarations. #4450

Closed
YellowAfterlife opened this Issue Jul 29, 2015 · 8 comments

Projects

None yet

3 participants

@YellowAfterlife
Contributor

Having, say,

@meta var some = 1;
trace(some);

will raise "unknown identifier some", as it appears to essentially treat the code as

@meta {
    var some = 1;
}
trace(some);

Raises some questions of mine as to how would one attach metadata to variable declarations.

@Simn
Member
Simn commented Jan 7, 2016

It's not really clear what should happen here because we go from EVars (multiple) to a block of TVar (single). The current behavior is both consistent and silly.

@Simn Simn modified the milestone: 3.3.0-rc1 Feb 23, 2016
@Simn Simn self-assigned this Feb 23, 2016
@Simn
Member
Simn commented Mar 16, 2016

@ncannasse: You wouldn't happen to remember why type_vars has that in_block argument and essentially discards locals if that is false?

The original problem is that EVars doesn't match in type_block because there's EMeta in the way. The same would happen with a ECast as well.

@ncannasse
Member

@Simn the following syntax was originally considered invalid for haxe : if( cond ) var x = 0;, local vars had to be declared into a block. That was before I added sanitization, which might already be wrapping things into a TBlock

@ncannasse
Member

Ah, and yes, because EBlock is responsible for scoping, he is the one that save/restore locals. Not being into a EBlock means that you shouldn't add the local to the current scope, or else my previous example will make x accessible outside of the if

@Simn Simn added a commit to Simn/haxe that referenced this issue Mar 17, 2016
@Simn Simn add `Expr.ensure_block`
Use it in places where we expect a block:

* try (the catches already save their locals)
* for, while and do while body
* then and else

This allows us to remove EVars as a special case for block-typing (see #4450)
fbe58de
@Simn
Member
Simn commented Mar 17, 2016

What do you think about the linked commit? Instead of treating EVars as a special case in several places, we simply make sure that everything that should have an EBlock does in fact have an EBlock. This automatically addresses scoping problems like your if( cond ) var x = 0; example.

@Simn
Member
Simn commented Apr 2, 2016

@ncannasse: Forgot to ping you, see comment above.

@ncannasse
Member

There might be some exotic cases not taken care of, such as cond && var a but I guess we would get another error in these cases anyway Cannot use this expression as value. Ah, maybe not for cast var a = 0; a. Did you check ETernary?

@Simn
Member
Simn commented Apr 2, 2016

You cannot use cast var a = 0; a without using a block, can you?

ETernary is turned into EIf, so it's the same case.

@Simn Simn added a commit that closed this issue Apr 2, 2016
@Simn Simn add `ensure_block` (closes #4450) e536804
@Simn Simn closed this in e536804 Apr 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment