Analyzer reports mismatched types on Windows due to drive letter casing

[DanTup]

Copying this from Dart-Code/Dart-Code#261 as I don't think it's specific to Dart Code (however, I can't explain why Atom or DartAnalyzer wouldn't show the same issue).

Here is a smaller repro than attached to the Dart Code issue, it's basically:

lib/a.dart

import 'package:repro/b.dart';

class Renderer
{

}

class Mesh extends Renderable
{
    @override
    void render(Renderer r)
    {

    }
}

lib/b.dart

import 'package:repro/a.dart';

abstract class Renderable
{
    void render(Renderer r);
}

There's also a pubspec with just a name and I've run pub get.

The error reported is:

file: 'file:///c%3A/Users/danny/Desktop/repro/repro/lib/a.dart'
severity: 'Error'
message: 'Invalid override. The type of 'Mesh.render' ('(Renderer) → void') isn't a subtype of 'Renderable.render' ('(Renderer) → void').'
at: '11,5'
source: 'dart'

There's only one Renderer class so it seems like these should be the same and the error is incorrect, however the files reference each other, I'm not sure if that's supported?

The log from the AS server is this:

[11:47:34]: ==> {"id":"1","method":"server.setSubscriptions","params":{"subscriptions":["STATUS"]}}
[11:47:34]: ==> {"id":"2","method":"analysis.setAnalysisRoots","params":{"included":["c:\\Users\\danny\\Desktop\\repro\\repro"],"excluded":[]}}
[11:47:34]: <== {"event":"server.connected","params":{"version":"1.17.0","pid":12036,"sessionId":""}}
[11:47:34]: <== {"id":"1"}
[11:47:34]: <== {"event":"server.status","params":{"pub":{"isListingPackageDirs":true}}}
[11:47:34]: <== {"event":"server.status","params":{"pub":{"isListingPackageDirs":false}}}
[11:47:35]: <== {"id":"2"}
[11:47:35]: <== {"event":"server.status","params":{"analysis":{"isAnalyzing":true}}}
[11:47:35]: <== {"event":"analysis.errors","params":{"file":"c:\\Users\\danny\\Desktop\\repro\\repro\\lib\\a.dart","errors":[]}}
[11:47:35]: <== {"event":"analysis.errors","params":{"file":"c:\\Users\\danny\\Desktop\\repro\\repro\\lib\\a.dart","errors":[{"severity":"ERROR","type":"COMPILE_TIME_ERROR","location":{"file":"c:\\Users\\danny\\Desktop\\repro\\repro\\lib\\a.dart","offset":113,"length":39,"startLine":11,"startColumn":5},"message":"Invalid override. The type of 'Mesh.render' ('(Renderer) → void') isn't a subtype of 'Renderable.render' ('(Renderer) → void').","code":"strong_mode_invalid_method_override","hasFix":false}]}}
[11:47:35]: <== {"event":"analysis.errors","params":{"file":"c:\\Users\\danny\\Desktop\\repro\\repro\\lib\\a.dart","errors":[{"severity":"ERROR","type":"COMPILE_TIME_ERROR","location":{"file":"c:\\Users\\danny\\Desktop\\repro\\repro\\lib\\a.dart","offset":113,"length":39,"startLine":11,"startColumn":5},"message":"Invalid override. The type of 'Mesh.render' ('(Renderer) → void') isn't a subtype of 'Renderable.render' ('(Renderer) → void').","code":"strong_mode_invalid_method_override","hasFix":false}]}}
[11:47:35]: <== {"event":"analysis.errors","params":{"file":"c:\\Users\\danny\\Desktop\\repro\\repro\\lib\\b.dart","errors":[]}}
[11:47:35]: <== {"event":"analysis.errors","params":{"file":"c:\\Users\\danny\\Desktop\\repro\\repro\\lib\\b.dart","errors":[]}}
[11:47:35]: <== {"event":"analysis.errors","params":{"file":"c:\\Users\\danny\\Desktop\\repro\\repro\\lib\\b.dart","errors":[]}}
[11:47:35]: <== {"event":"server.status","params":{"analysis":{"isAnalyzing":false}}}

[lrhn]

The problem seems to be how you refer to your entry-point and the relation between the libraries.

If you refer to a.dart it as file:///..../a.dart (which you do, it says file: 'file:///c%3A/Users/danny/Desktop/repro/repro/lib/a.dart'), then it will be considered a different library than the one with URI package:repro/a.dart. That means that the Renderer in the entry-point library is different from the one imported by b.dart. You have two different versions of the same library. If you had given the library a name, you would get a warning here.

So either run/analyze using a package URI or stop doing absolute imports. I recommend the latter in any case. It's an unnecessary complication to hard-code your own package name into internal references, at least unless absolutely necessary. If nothing else, it makes it harder to rename the package, and it doesn't do anything good.

That is, either run/analyze it as dart package:repro/a.dart or try changing the imports from being absolute package-URIs to being relative: import "a.dart"; and import "b.dart";.

In the linked Dart-Code example, you say that changing the package-URIs work, and it is a solution.

As for Dart-Code, they might want to refer to files that are part of a package by its package-URI, not its file-location, if that is possible.

[DanTup]

@lrhn

The problem seems to be how you refer to your entry-point and the relation between the libraries.

If you refer to a.dart it as file:///..../a.dart (which you do, it says file: 'file:///c%3A/Users/danny/Desktop/repro/repro/lib/a.dart'),

That filename is what comes back from the analysis server and then gets passed to VS Code in the errors list; nowhere in the repro is importing it like this (nor do we pass it to the analyzer; only the workspace root). That path is (presumably) constructed by the analysis service based on the analysis root we pass to it; I don't believe there's anything I can change here to fix this.

As for Dart-Code, they might want to refer to files that are part of a package by its package-URI, not its file-location, if that is possible.

Dart Code doesn't invoke the analyzer directly; it spawns the analysis server from the snapshot in the SDK and then passes it the root folder. We don't parse any of the code at all. We just say "here's a folder of Dart code" and the analysis server gives us all the errors; how pubspec/lib/imports are handled are all internal to the analysis service. I believe this issue could be repro'd entirely without Dart Code (though I'm surprised it apparently doesn't occur in Atom, which uses the same service; though I don't have Atom to test it myself).

It's possible this code is incorrect and should be using relative paths; though the author expected it to work (and at first glance, I would to; though I'm not all that experience with Dart). I'm struggling to see how I can fix this in Dart Code though :(

[lrhn]

That sounds like it's probably an analyzer problem then.

If the analyzer sees the pubspec.yaml with name: repro and a lib/a.dart file, it should probably treat a.dart as having URI package:repro/a.dart when analyzing it. If it doesn't, problems like this will occur.
I'm tagging this as an analyzer issue.

The error report does need to show the file name - the analysis server can handle large directories with multiple package structures, so a package URI doesn't uniquely identify the file with the problem.

[bwilkerson]

If the analyzer sees the pubspec.yaml with name: repro and a lib/a.dart file, it should probably treat a.dart as having URI package:repro/a.dart when analyzing it. If it doesn't, problems like this will occur.

Yes, that's exactly what analysis server does. And as a consequence, we advise people to always use package: URIs when referring to libraries inside the lib directory of a package.

[bwilkerson]

I can't reproduce this behavior on bleeding edge. I created a directory structure containing the following:

repro
  lib
    a.dart
    b.dart
  pubspec.yaml

where a.dart and b.dart are identical to what's above, and pubspec.yaml contains

name: repro
version: 0.0.1
description: A test package.

I then ran pub get to produce a .packages file and a pubspec.lock file.

When I run the command-line analyzer on a.dart I get "No issues found!", and when I load repro in IntelliJ I see no errors being reported.

Could you enable the instrumentation log file, load a project like this into Dart Code, and then send me the log file? (Private e-mail is fine if you don't want to attach it.) That will let me see whether there's a mismatch between client and server.

[DanTup]

Yes, that's exactly what analysis server does.

Yeah, I figured this most generally work or there would be loads of issues!

Could you enable the instrumentation log file, load a project like this into Dart Code, and then send me the log file?

Yep, attached is the log for the zip file I attached at the top.

analyzer.instrum.txt

I'm puzzled about why it only seems to happen in Dart Code; it doesn't seem like Dart Code is doing much that could influence this, but the original reporter also tested in Atom and it didn't happen!

[bwilkerson]

Yeah, I'm puzzled too.

Unfortunately, the instrumentation log doesn't show anything that gives me any clues. There are only two requests, both perfectly reasonable, and there's nothing else that Dart Code needed to do. It might be interesting to get a similar log from Atom for comparison, but I honestly don't expect to see anything different.

Just for completeness...

Do you and the user both have a .packages file in repro?

Do either you, or the user, have any files or directories in either repro or any parent directory with any of the following names: .analysis_options, analysis_options.yaml, WORKSPACE, READONLY, or .jiri_root? If so, which?

[DanTup]

Do you and the user both have a .packages file in repro?

Yep; it was in the zip file up top, but here's the contents:

# Generated by pub on 2017-02-25 11:43:46.036993.
repro:lib/

Do either you, or the user, have any files or directories in either repro or any parent directory with any of the following names: .analysis_options, analysis_options.yaml, WORKSPACE, READONLY, or .jiri_root? If so, which?

I don't believe so, but just to be sure I moved the repro folder to the root of a drive (m:\repro) and tried again and see the same behaviour upon opening:

[19:48:51]: ==> {"id":"1","method":"server.setSubscriptions","params":{"subscriptions":["STATUS"]}}
[19:48:51]: ==> {"id":"2","method":"analysis.setAnalysisRoots","params":{"included":["m:\\repro"],"excluded":[]}}
[19:48:51]: <== {"event":"server.connected","params":{"version":"1.17.0","pid":3368,"sessionId":""}}
[19:48:51]: <== {"id":"1"}
[19:48:51]: <== {"event":"server.status","params":{"pub":{"isListingPackageDirs":true}}}
[19:48:51]: <== {"event":"server.status","params":{"pub":{"isListingPackageDirs":false}}}
[19:48:52]: <== {"id":"2"}
[19:48:52]: <== {"event":"server.status","params":{"analysis":{"isAnalyzing":true}}}
[19:48:52]: <== {"event":"analysis.errors","params":{"file":"m:\\repro\\lib\\a.dart","errors":[]}}
[19:48:52]: <== {"event":"analysis.errors","params":{"file":"m:\\repro\\lib\\a.dart","errors":[{"severity":"ERROR","type":"COMPILE_TIME_ERROR","location":{"file":"m:\\repro\\lib\\a.dart","offset":113,"length":39,"startLine":11,"startColumn":5},"message":"Invalid override. The type of 'Mesh.render' ('(Renderer) → void') isn't a subtype of 'Renderable.render' ('(Renderer) → void').","code":"strong_mode_invalid_method_override","hasFix":false}]}}
[19:48:52]: <== {"event":"analysis.errors","params":{"file":"m:\\repro\\lib\\a.dart","errors":[{"severity":"ERROR","type":"COMPILE_TIME_ERROR","location":{"file":"m:\\repro\\lib\\a.dart","offset":113,"length":39,"startLine":11,"startColumn":5},"message":"Invalid override. The type of 'Mesh.render' ('(Renderer) → void') isn't a subtype of 'Renderable.render' ('(Renderer) → void').","code":"strong_mode_invalid_method_override","hasFix":false}]}}
[19:48:52]: <== {"event":"analysis.errors","params":{"file":"m:\\repro\\lib\\b.dart","errors":[]}}
[19:48:52]: <== {"event":"analysis.errors","params":{"file":"m:\\repro\\lib\\b.dart","errors":[]}}
[19:48:52]: <== {"event":"analysis.errors","params":{"file":"m:\\repro\\lib\\b.dart","errors":[]}}
[19:48:52]: <== {"event":"server.status","params":{"analysis":{"isAnalyzing":false}}}

I can't reproduce this behavior on bleeding edge

Oh crap, I just realised when looking at the files that I totally neglected to mention that strong-mode is enabled via .analysis_options:

analyzer:
  strong-mode: true

It was in the zip, but I didn't mention it in the text so if you tried building your own repro you probably missed this.

I'm not sure how to enable logging in Atom; but if you think the log would be useful to compare, I'm happy to install it and try and figure it out. Since I haven't repro'd it myself I can't say for sure the OP didn't do something differently and maybe it can be repro'd there; so the "only happening in Dart Code" thing might be a red herring.

[bwilkerson]

I enabled strong-mode, but as I expected there was no difference.

[DanTup]

Could it be OS-related? I don't have easy access to a non-Windows machine to test, though maybe you have access to a Windows one?

Using the zip file I attached is probably easiest in case I described anything else incorrectly; just opening that folder in Dart Code immediately triggers the error.

If there's anything else you can think of that I can do to help debug, let me know!

[DanTup]

I opened the same repro folder on both my PC and Mac, both using 1.24.2 SDK. The PC reports this error and the Mac does not.

So I wonder whether there's some code that considers both the package import and the relative path as the same file that isn't working correctly on Windows (maybe because of path separators?).