Fix #2546. Add constant context tests

[sgrekhov]

No description provided.

[eernstg]

Looks good! Suggested a couple of adjustments.

[eernstg]

This is actually the initializing expression, not a subexpression of any other expression.

Perhaps?:

Suggested change

	const c1 = (){C(1);};
	const c1 = C((){});

c2 needs a similar adjustment, but c3 is fine (except that perhaps the ^^^ should be adjusted).

[sgrekhov]

Changed to C((){C(1);}). According to the description C(1) must be a subexpression of a function literal, therefore I added it to the body

[eernstg]

Oh, I misread that!

It's tricky because it seems to be a kind of negation of the following: e is in a constant context if "e is an immediate subexpression of an expression e0 which occurs in a constant context, where e0 is not a function literal".

However, the negation of that is something like "e is not in a constant context if e is not an immediate subexpression of any other expression, or it is an immediate subexpression of an expression e0 that doesn't occur in a constant context, or it is an immediate subexpression of an expression e0 that occurs in a constant context and which is a function literal".

But the latter is a compile-time error: It is always an error for a function literal to occur in a constant context (because it's never a constant expression).

That part should probably be taken out. I think it was included because I had a specific feature in mind, namely constant function literals.

If we had had support for constant function literals then we could have had constant expressions using them: const () { print('Hello, world!'); }. In the body of a constant function literal we can have arbitrary code (it can have side effects, it can change mutable state, etc), just like we can have arbitrary code in the body of a top-level function, and a tear-off of that function is still a constant expression. The constant function literal just cannot access any entities with a lifetime that isn't "infinite" (that is, it can refer to top-level declarations and static members of an enclosing class, if any, they cannot refer to instance variables or local scopes).

Anyway, we don't have constant function literals (yet!), so the last option just disappears.

It isn't particularly useful to test how we deal with a lot of different things inside a function literal that occurs in a constant context, because that function literal is always a compile-time error.

However, I don't see any compile-time errors here (except for function literals occurring in a location where a constant expression is required), I just see the distinction between "is in a constant context" and "is not in a constant context".

If we start negating the criterion (like, changing "is not a function literal" to "is a function literal") then we just get into a case where we have "is not in a constant context", which is a location where far, far fewer things are errors.

I guess I just don't get the point when I'm reading that description. ;-)

[sgrekhov]

Thank you. Updated, please take another look

[sgrekhov]

Changed to C((){C(1);}). According to the description C(1) must be a subexpression of a function literal, therefore I added it to the body

[eernstg]

Looks good!

Just one thing—there was a long comment. It still says 'pending', so it was probably never sent, but I hope it will be sent now.

It's mostly about me being confused. ;-)

The point is that we have a rule that says "e is in a constant context if blah-blah", and then we have a test that says something like "assume e and not-blah-blah", and the consequence would be that e is not in a constant context. However, the test description seems to assume that it is an error, but there are of course lots of situations where an expression isn't in a constant context, and it's not an error.

On top of that, it is an error for a function literal to be a subexpression of a constant expression, so we do get an error as claimed.

The whole thing is just a little unclear.

So please take a look at the comment 'Oh, I misread that!' and see if it makes sense to you. ;-)

[eernstg]

Oh, I misread that!

It's tricky because it seems to be a kind of negation of the following: e is in a constant context if "e is an immediate subexpression of an expression e0 which occurs in a constant context, where e0 is not a function literal".

However, the negation of that is something like "e is not in a constant context if e is not an immediate subexpression of any other expression, or it is an immediate subexpression of an expression e0 that doesn't occur in a constant context, or it is an immediate subexpression of an expression e0 that occurs in a constant context and which is a function literal".

But the latter is a compile-time error: It is always an error for a function literal to occur in a constant context (because it's never a constant expression).

That part should probably be taken out. I think it was included because I had a specific feature in mind, namely constant function literals.

If we had had support for constant function literals then we could have had constant expressions using them: const () { print('Hello, world!'); }. In the body of a constant function literal we can have arbitrary code (it can have side effects, it can change mutable state, etc), just like we can have arbitrary code in the body of a top-level function, and a tear-off of that function is still a constant expression. The constant function literal just cannot access any entities with a lifetime that isn't "infinite" (that is, it can refer to top-level declarations and static members of an enclosing class, if any, they cannot refer to instance variables or local scopes).

Anyway, we don't have constant function literals (yet!), so the last option just disappears.

It isn't particularly useful to test how we deal with a lot of different things inside a function literal that occurs in a constant context, because that function literal is always a compile-time error.

However, I don't see any compile-time errors here (except for function literals occurring in a location where a constant expression is required), I just see the distinction between "is in a constant context" and "is not in a constant context".

If we start negating the criterion (like, changing "is not a function literal" to "is a function literal") then we just get into a case where we have "is not in a constant context", which is a location where far, far fewer things are errors.

I guess I just don't get the point when I'm reading that description. ;-)

[sgrekhov]

I was in doubt if we need this text because a function literal in a constant context is an error itself. But eventually, I decided to add it because I was thinking that if we have this statement in the spec, that means there are some reasons to add it. No problem; I just deleted this test. Thank you.

[eernstg]

LGTM!

[a-siva]

'dart:mirrors' will not work in the VM AOT mode, this test needs to be skipped for AOT builds.

Also 'dart:mirrors' is an unsupported feature, not sure why we need to add new tests to test it's funcitonality

[sgrekhov]

@a-siva thank you! https://dart-review.googlesource.com/c/sdk/+/353522