No complie time error for late field referencing itself

[dhruvjariwala123]

Thank you for taking the time to file an issue!

This tracker is for issues related to:

• Dart analyzer and linter

This Issue is in the repository :

• Dart language: https://github.com/dart-lang/language

Issue :
The Dart analyzer is not detecting errors for initializing fields by late in the declaration with the value of itself, making Stack Overflow condition. so it needs to disallow the fileds to late initialize by themselves.

example code :
void main() {
MyClass myClass = MyClass();
print(myClass.i);
}

class MyClass {
late int i = this.i;
}

[dhruvjariwala123]

Also this example :
void main() {
MyClass myClass = MyClass();
print(myClass.i);
print(myClass.j);
}

class MyClass {
//Should not allow to initialize by themselves.
late int i = this.i;
// And also should not allow to initialize by others who are dependent on it.
late int j = this.k;
late int k = this.j;
}

[lrhn]

An initializer not being self referential is probably a good warning.

I can write a successfull program with a self reference, so it's not necessarily a bug, but I can't find up with any reasonable reason for writing a program like that, so giving a warning unconditionally seems appropriate.

Marking as analyzer.
We could try to disallow the self reference in the language, but to do it properly, we'd want to catch mutually recursive declarations too, which is not trivial. A heuristic warning if the declaration contains direct self reference matches an analyzer warning better.

We can detect self references in constants because we actually evaluate them at compile time.

(A "successful" self-referential initializer could be:

class Weird {
  final int _defaultLevel;
  Weird(int defaultLevel) : _defaultLevel = defaultLevel;
  late String _levelString = (this._level, this._levelString).$2; // Initialize level if it isn't.
  late int _level = (_levelString = _defaultLevel.toString(), _defaultLevel).$2;
}

Here the initialil this._level will assign to _levelString, which it can then successfully read.
Just never do something like that, it's too hard to read.)

[dhruvjariwala123]

Thank you sir for updating the correct title for me :)
But, the analyzer needs to give a compile time error, not a warning. because the program is crashing due to a stack overflow situation.

[lrhn]

Stack overflow is a runtime error. There are lots of ways to write programs with runtime errors, that the analyzer cannot recognize at compiler time.

The analyzer doesn't generally introduce compile time errors, it only reports errors that are specified in the language specification.
And I don't see us trying to catch this error in the specification.
For "this is probably an error"-cases, the analyzer reports a warning. You can always change the diagnostic to an error if you want to.

[dhruvjariwala123]

ok sir, thanks for replying to my issue 😊.

[sgrekhov]

But, the analyzer needs to give a compile time error, not a warning. because the program is crashing due to a stack overflow situation.

According to the late fields specification

• If a variable or field is read from during the process of evaluating its own initializer expression, and no write to the variable has occurred, the read is treated as a first read and the initializer expression is evaluated again.

So, the StackOverflow in this case is an expected outcome.