Thread overview | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
June 17, 2009 is this right?? | ||||
---|---|---|---|---|
| ||||
void main() { int s; mixin("s") = 5; } ----- Line 4: found '=' when expecting ';' http://www.digitalmars.com/d/1.0/expression.html#MixinExpression |
June 17, 2009 Re: is this right?? | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | Hello BCS,
> void main()
> {
> int s;
> mixin("s") = 5;
> }
> -----
> Line 4: found '=' when expecting ';'
> http://www.digitalmars.com/d/1.0/expression.html#MixinExpression
>
(mixin("s")) = 5;
Given that the above works, it looks like the parser prematurely commits to a mixin declaration when it finds "mixin (" at function scope.
Unless someone spots a flaw in this, I'll post a bug.
|
June 17, 2009 Re: is this right?? | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | BCS escribió:
> Hello BCS,
>
>> void main()
>> {
>> int s;
>> mixin("s") = 5;
>> }
>> -----
>> Line 4: found '=' when expecting ';'
>> http://www.digitalmars.com/d/1.0/expression.html#MixinExpression
>>
>
> (mixin("s")) = 5;
>
> Given that the above works, it looks like the parser prematurely commits to a mixin declaration when it finds "mixin (" at function scope.
>
> Unless someone spots a flaw in this, I'll post a bug.
Yes, at that point the parser is parsing statements, so if it finds a "mixin(...)" it turns it into a statement.
I'm thinking about how to fix this. I think the parser should peek the next token after the closing parenthesis. If it's a semicolon, then treat it as a statement-mixin. Else, just invoke parseAssignExp and create a new ExpStatement.
I modified this in Descent and it seems to work. :-)
Here's the code (in Java, but the idea is simple to translate to C++):
// inside Parser::parseStatement
case TOKmixin: {
Dsymbol d;
t = peek(token);
if (t.value == TOKlparen)
{
if (peekPastParen(t).value != TOKsemicolon) {
Expression e = parseAssignExp();
s = new ExpStatement(loc(), e);
} else {
// mixin(string)
nextToken();
check(TOKlparen);
Expression e = parseAssignExp();
check(TOKrparen);
check(TOKsemicolon);
s = newCompileStatement(loc(), e);
}
break;
} else {
d = parseMixin();
s = newDeclarationStatement(loc(), d);
break;
}
}
|
June 17, 2009 Re: is this right?? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Borenszweig | Hello Ary, > BCS escribió: > >> Hello BCS, >> >>> void main() >>> { >>> int s; >>> mixin("s") = 5; >>> } >>> ----- >>> Line 4: found '=' when expecting ';' >>> http://www.digitalmars.com/d/1.0/expression.html#MixinExpression >> (mixin("s")) = 5; >> >> Given that the above works, it looks like the parser prematurely >> commits to a mixin declaration when it finds "mixin (" at function >> scope. >> >> Unless someone spots a flaw in this, I'll post a bug. >> > Yes, at that point the parser is parsing statements, so if it finds a > "mixin(...)" it turns it into a statement. > http://d.puremagic.com/issues/show_bug.cgi?id=3073 Hope you don't mind me quoting you. |
June 17, 2009 Re: is this right?? | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | BCS wrote:
> void main()
> {
> int s;
> mixin("s") = 5;
> }
> -----
> Line 4: found '=' when expecting ';'
>
>
> http://www.digitalmars.com/d/1.0/expression.html#MixinExpression
>
>
mixin *expression*
(4+3) = 5;
|
June 17, 2009 Re: is this right?? | ||||
---|---|---|---|---|
| ||||
Posted in reply to hasen | hasen wrote:
> BCS wrote:
>> void main()
>> {
>> int s;
>> mixin("s") = 5;
>> }
>> -----
>> Line 4: found '=' when expecting ';'
>>
>>
>> http://www.digitalmars.com/d/1.0/expression.html#MixinExpression
>>
>>
>
> mixin *expression*
>
> (4+3) = 5;
>
Oh, never mind,
AssignExpression can be of the form:
ConditionalExpression = AssignExpression
my bad.
|
June 17, 2009 Re: is this right?? | ||||
---|---|---|---|---|
| ||||
Posted in reply to hasen | Hello hasen, > hasen wrote: > >> BCS wrote: >> >>> void main() >>> { >>> int s; >>> mixin("s") = 5; >>> } >>> ----- >>> Line 4: found '=' when expecting ';' >>> http://www.digitalmars.com/d/1.0/expression.html#MixinExpression >>> >> mixin *expression* >> >> (4+3) = 5; >> > Oh, never mind, > > AssignExpression can be of the form: > > ConditionalExpression = AssignExpression > > my bad. Irony: I wrote a lib that abuses the grammer to allow exactly that kind of syntax <g> http://www.dsource.org/projects/scrapple/browser/trunk/backmath |
June 17, 2009 Re: is this right?? | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | BCS escribió:
> Hello Ary,
>
>> BCS escribió:
>>
>>> Hello BCS,
>>>
>>>> void main()
>>>> {
>>>> int s;
>>>> mixin("s") = 5;
>>>> }
>>>> -----
>>>> Line 4: found '=' when expecting ';'
>>>> http://www.digitalmars.com/d/1.0/expression.html#MixinExpression
>>> (mixin("s")) = 5;
>>>
>>> Given that the above works, it looks like the parser prematurely
>>> commits to a mixin declaration when it finds "mixin (" at function
>>> scope.
>>>
>>> Unless someone spots a flaw in this, I'll post a bug.
>>>
>> Yes, at that point the parser is parsing statements, so if it finds a
>> "mixin(...)" it turns it into a statement.
>>
>
> http://d.puremagic.com/issues/show_bug.cgi?id=3073
>
> Hope you don't mind me quoting you.
Not at all!
But later when I went to sleep I thought about that a little more, and look at this:
1. mixin("int x = 2;");
2. mixin("x = 2");
The first should be treated as a MixinStatement, because it ends with a semicolon. The second should be treated as a MixinExpression, because it doesn't end with a semicolon (and it's a perfectly valid expression, it's an assign expression). But according to my patch it'll be treated as a statement and it'll fail.
Now this:
3. mixin("int x = 2");
is neither of them.
You can only deduce that information if you can extract the contents of the mixin, paste it in the source file and treat the whole line as a statement, and you'd get things right. But now all of those lines can be:
mixin(secret());
and now you don't know, you'll have to wait for semantic anlaysis to know that, but then it's too late.
But I think my patch is reasonable because it allows you to do more things than before, it's backwards compatible and also you'd almost never do number 2 but instead use number 1.
|
Copyright © 1999-2021 by the D Language Foundation