Dartc is too smart when dealing with variable declarations

[DartBot]

This issue was originally filed by ms...@unipro.ru

---

The spes in the section 11.3 says: "A variable declaration statement var id; or var id = e; introduces a new variable named id with static type Dynamic into the innermost enclosing scope.".
This means there should not be any static warnings in this test:

func(int p) {}

main() {
  var param = true;
  func(param);
}

But Dartc, r7976, produces a static warning: "bool is not assignable to int".

Changing code to

func(int p) {}

main() {
  var param;
  param = true;
  func(param);
}

solves this problem.

[kasperl]

Adding Gilad on the CC list. I guess the issue here is an extra static type warning based on inferred types reported by the analyzer (trying to be helpful).

---

cc @gbracha.
Added Area-Analyzer, Triaged labels.

[bwilkerson]

Set owner to @scheglov.

[peter-ahe-google]

It is very tricky to warn based on inferred types.

It is essential that developers have a way to opt-out of warnings without losing code-completion. Also, the inferred type should not prevent the developer from completing members that aren't in the narrow inferred type.

While the intent is to help the user, it is not possible to infer why he didn't put a type on a variable.

A much simpler approach is to use inference to make suggestions about type annotations, and possible add automatically add the annotations in the source code while editing. How to do this well is tricky, and requires good UI.

Adding to that approach, it is possible to track two types of an expression. The inferred and the declared. This allows an analyzer to provide great information for code completion, but still obey the language semantics.

[gbracha]

What Peter said. The current behavior is makes the spec meaningless. In general, we will need a much more nuanced interpretation of warnings in the tools. I would suggest that any warnings that go beyond the spec be packaged as a separate tool that can be run at the programmer's discretion, and displayed in a distinctive way.

[scheglov]

https://chromiumcodereview.appspot.com/10459012

---

Added Started label.

[scheglov]

https://code.google.com/p/dart/source/detail?r=8080

---

Added Fixed label.

[scheglov]

We are going to re-introduce these checks again, but now it will be disabled for command line and can be enabled/disabled in Editor preferences.

http://code.google.com/p/dart/issues/detail?id=4518

[DartBot]

This comment was originally written by rodion...@unipro.ru

---

command-line analyzer is still doing this:

  var varnotfunc = 1;
  try {
    varnotfunc();
    Expect.fail("NoSuchMethodError expected");
  } on NoSuchMethodError catch(ok) {}

WARNING|STATIC_TYPE|NOT_A_FUNCTION_TYPE|file:/media/sf_dart_local/co19/tests/co19/src/Language/11_Expressions/14_Function_Invocation/4_Function_Expression_Invocation_A02_t01.dart|55|5|10|"int" is not a function type

splitting variable declaration from initialization no longer works to suppress this warning either

[scheglov]

Added this to the M3 milestone.
Added Accepted label.

[scheglov]

https://codereview.chromium.org/11633024

---

Added Started label.

[scheglov]

https://code.google.com/p/dart/source/detail?r=16356

---

Added Fixed label.