CFE doesn't allow void to void assignment

[MichaelRFairhurst]

The following should have no errors:

void f(void x) {}                                                                
void voidFn() {}                                                                 
                                                                                 
void main() {                                                                    
  f(voidFn());                                                                   
}

This is critical for mockito, which uses a template argument to accomplish the same thing:

void f<T>(T x) {}                                                                
void voidFn() {}                                                                 
                                                                                 
void main() {                                                                    
  f(voidFn());                                                                   
}   

Both of these should work. @peter-ahe-google

[srawlins]

When was this introduced. dev.68.0 is happy. I haven't tried later than that.

[MichaelRFairhurst]

I think 69.1

[MichaelRFairhurst]

@pq is running into it in this case:

void x() {
  return print('foo'); // this is legal
}

As I understand it, this is complicating the latest fix of package:analyzer

[MichaelRFairhurst]

I don't think this ever got documented anywhere. I remember thinking I should update the language tests to test this stuff, but did not because it can be so much work to just mark all those new tests as failing.

[pq]

Thanks @MichaelRFairhurst!

Actually, this time it's not analyzer but related to coveralls which is breaking on a linter PR:

https://travis-ci.org/dart-lang/linter/jobs/406425911

Failed to precompile dart_coveralls:dart_coveralls:
file:///home/travis/.pub-cache/hosted/pub.dartlang.org/dart_coveralls-0.6.0+1/bin/src/report.dart:16:29: Error: This expression has type 'void' and can't be used.
    if (res["help"]) return print(parser.usage);

Still investigating.

[MichaelRFairhurst]

Actually, this time it's not analyzer but related ... breaking on a linter PR

Well that's a big improvement!

[pq]

😄

Some more context:

https://github.com/pq/dart-coveralls/blob/de6c86184e247c92b89dd314ec00e98b30b52f07/bin/src/report.dart#L22

TL;DR coveralls is returning void in an async context which should be OK?

[pq]

More specifically, the case is:

Future foo() async {
  return print('whoops');
}

[MichaelRFairhurst]

Note that this works fine:

dynamic voidFn() {                                                          
  return print('foo');                                                           
}

[MichaelRFairhurst]

This also should not have been an error:

pkg/analyzer/lib/src/dart/analysis/library_context.dart : 98

      logger.run('Append library files', () {                                    
        return appendLibraryFiles(targetLibrary);                                       
      }); 

I don't think this should have been an error; the type of run should have been inferred as () -> dynamic, and then appendLibraryFiles should have been OK to return, as void values are OK to return within a dynamic context.

It was fixed in the analyzer source, and the change is certainly a fair change, but this may affect other packages.

I'm less sure on this one though. May have been an analyzer bug? In any case this would be a breaking change compared to the previous behavior so we'd want to be very sure it needed to change if we want to change it. @eernstg @lrhn

[eernstg]

@MichaelRFairhurst said:

I don't think this ever got documented anywhere.

Just a drive-by comment, if I understood correctly what 'this' refers to here, it is actually covered in the feature spec. We have the following rule:

An actual parameter expression corresponding to a formal
parameter whose statically known type annotation is the type
void may have the type void.

and there is a similar rule for void v = voidExpression;. Those rules were added in order to allow for "assigning void to void" in several situations. For return e, we have had such a rule for a long time, because it was already a consequence of the type rules in Dart 1.