Context manager bypasses resourceProvider when using package roots. #23909
Labels
analyzer-server
area-analyzer
Use area-analyzer for Dart analyzer issues, including the analysis server and code completion.
P3
A lower priority bug or feature request
type-bug
Incorrect behavior (everything from a crash to more subtle misbehavior)
Comments
|
Minor correction: the codepath isn't entirely bogus--it could also trigger in the event of a race condition where the package root existed at the time it was specified, but then disappeared before the contents of the folder could be read. |
stereotype441
added a commit
that referenced
this issue
Jul 24, 2015
This codepath was only exercised during unit tests and race conditions. The fact that it was executed during unit tests at all was due to a bug (see #23909). The behavior during race conditions was incorrect (it tried to set up package resolution using a folder that didn't exist). This CL fixes the race condition behavior and disables the affected tests. In a future CL I will fix the underlying bug that caused the unit tests to execute incorrectly, and re-enable the tests. R=brianwilkerson@google.com Review URL: https://codereview.chromium.org//1253803002 .
sethladd
added
the
area-analyzer
|
This bug was accidentally auto-closed because the commit message for cdfa46f says it "partially fixes" the bug. Re-opening since the bug is not yet completely fixed. |
kevmoo
added
P2
srawlins
added
P3
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The code in ContextManagerImpl._computePackageUriResolver which handles package roots uses the JavaFile class to read the contents of the package root, rather than the resourceProvider. Since the resourceProvider is used during unit tests to replace the true filesystem with a mock filesystem, this means that the normal code for handling package roots is not exercised by unit tests, and a separate bogus code path (which otherwise is dead code) is used instead.
I will shortly be submitting a CL which disables the tests and eliminates the bogus code path so that I don't have to maintain it while I'm refactoring the ContextManager. But the proper solution is to add the necessary functionality to ResourceProvider so that this code path doesn't have to use JavaFile, and then re-enable the tests.
The text was updated successfully, but these errors were encountered: