The type '((dynamic) → dynamic) → Iterable<dynamic>' is declared with 0 type parameters, but 0 type arguments were given

[alan-knight]

From Intl: test/date_time_format_test_core.dart:369

The code below, which was previously passing, now gives warnings.

 Map<int, DateTime> generateDates(int year, int leapDay) =>
      new Iterable.generate(365 + leapDay, (n) => n + 1)
          .map /*<DateTime>*/ ((day) {
        var result = new DateTime(year, 1, day);
        // TODO(alanknight): This is a workaround for dartbug.com/15560.
        if (result.toUtc() == result) result = new DateTime(year, 1, day);
        return result;
      }).toList().asMap();

WARNING: The type '((dynamic) → dynamic) → Iterable' is declared with 0 type parameters, but 0 type arguments were given ([intl] test/date_time_format_test_core.dart:369)

and also

WARNING: new Iterable.generate(365 + leapDay, (n) => n + 1).map((day) {var result = new DateTime(year, 1, day); if (result.toUtc() == result) result = new DateTime(year, 1, day); return result;}).toList().asMap() (Map<int, dynamic>) will need runtime check to cast to type Map<int, DateTime>

The second is more reasonable, although I'd have thought it could be inferred.

[jmesserly]

@alan-knight is this in the command line analyzer or IDE?

I've seen this too, and the command line analyzer side was recently fixed. What's going on is we're analyzing against the SDK without strong mode turned on, which means no generic methods.

[jmesserly]

Another guess, we don't do upward inference on constructors -- so new Iterable.generate won't infer. That is covered by #25220.

[alan-knight]

This is in Intellij, using, I think, 1.14.0_dev_7_2. It might be that it doesn't have that flag turned on for the SDK, not sure how to tell.

[bwilkerson]

If this in in IntelliJ, then you're running server and we're not setting this flag appropriately.

@jmesserly What would the effect be of setting strong-mode in the SDK context if it isn't set in the user's context? (I'm just wondering if, until we get it fixed, we can make life better for folks by reversing the default.)

[vsmenon]

@bwilkerson That may have unintended consequences? I don't think we have any testing of non-strong user code and against strong SDK. In theory, inferred elements in the SDK could change errors and warnings in non-strong user code.

How hard would a real fix be?

[bwilkerson]

In theory, inferred elements in the SDK could change errors and warnings in non-strong user code.

Good point.

How hard would a real fix be?

I working on it now, I just need to carve out enough time. I'm hoping to have it done by the end of the week unless other issues take priority.

[vsmenon]

General bug filed:
#25667

[jmesserly]

General bug is fixed. I'll double check where this is at now. Regardless we need to fix the "0 type args 0 type params" message

[jmesserly]

Confirmed Alan's bug is fixed. Here's a new repro:

f() {}
main() {
  // [warning] The type '() → dynamic' is declared with 0 type parameters, but 0 type arguments were given
  f/*<int>*/();
}

[jmesserly]

Found it. It's a silly bug :)

[jmesserly]

https://codereview.chromium.org/1683203002