Analyzer should analyze library when run on part file.

dart-lang / sdk

The Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.

https://dart.dev

BSD 3-Clause "New" or "Revised" License

10.31k stars 1.59k forks source link

Analyzer should analyze library when run on part file. #29593

Open lrhn opened 7 years ago

lrhn commented 7 years ago

If the analyzer is asked to analyze a part file, and that part file uses the new part of URI syntax, the analyzer should include the library of the part file in the files to analyze, and thereby analyzing the part file too.

Currently it just bails out if a part file is requested analyzed, unless the library it belongs to is also requested.

srawlins commented 1 year ago

+1. I think this makes a lot of sense for usability. WDYT @bwilkerson @scheglov ? This would perhaps solve https://github.com/dart-lang/sdk/issues/50889, https://github.com/dart-lang/sdk/issues/47025, https://github.com/dart-lang/sdk/issues/24446, https://github.com/dart-lang/sdk/issues/14743 (surely one of our oldest issues).

I don't think there are considerations for server, just for dart analyze.

The only weird weird case would be if a part file and it's library are in different analysis contexts 😨 , but I think we can ignore that case :).

scheglov commented 1 year ago

dart analyze is implemented using the server, so they are the same. And it works now.

scheglov commented 1 year ago

Actually, we analyze only the part, not the whole library, as requested here.

bwilkerson commented 1 year ago

I'm not sure I fully understand the request.

If the request is that we analyze the part file in the context of its library, then I completely agree.

If the request is that we report analysis results for the part file, the defining compilation unit, and any other parts of the library, then I'm not sure whether that's what the majority of our users would want.

What do we do if the user analyzes a defining compilation unit that has parts? Do we report all of the diagnostics from the part files? In either case, it seems consistent to treat every unit in the library the same way.

lrhn commented 1 year ago

The original request was to be able to do (effectively, using today's CLI) dart analyze partfile.dart and not have it refuse to do anything, because it wouldn't go to the main library file from the part file. I agree this is fixed. Huzzah! Feel free to close issue if you're satisfied too.

I'm not particularly hung up on which diagnostic messages to show, as long as:

If you point to a library main file, it shows diagnostics for the entire library, including all part files, by default. (And come augmentations, those too.)
If you point to a part file, it shows at least diagnostics for the code of that file, in the context of the entire library. (If there are errors in other files of the same library, that's probably relevant, since it can affect whether there is a consistent context for interpreting this part file.)