Skip to content
This repository has been archived by the owner on Apr 14, 2022. It is now read-only.

PLS doesn't resolve relative paths correctly #510

Closed
erictraut opened this issue Dec 26, 2018 · 3 comments
Closed

PLS doesn't resolve relative paths correctly #510

erictraut opened this issue Dec 26, 2018 · 3 comments
Assignees
Milestone

Comments

@erictraut
Copy link

The analyzer sometimes does not resolve relative paths correctly. See the screen shot below.

screen shot 2018-12-26 at 1 53 04 am

The problem appears to be in PathResolverSnapshot.TryFindName which contains the following lines of code:

if (lastEdge.End.IsModule) {
    return false;
}

I don't understand why this logic is needed. When I comment out these three lines, the relative paths resolve correctly and other imports also appear to resolve as expected.

@MikhailArkhipov
Copy link

@AlexanderSher owns the import subsystem.

@AlexanderSher
Copy link
Contributor

AlexanderSher commented Jan 2, 2019

I don't understand why this logic is needed.

It is required for the case when there is a folder with the name of the module.
For example, for the following file structure:

├─ package
   ├─ module
   │  └─ submodule.py
   ├─ module.py
   └─ test.py

and test.py:

from .module.submodule import TEST

import should be highlighted as invalid import.

In your case, what is the value of lastEdge.End.ModulePath in that piece of code?

if (lastEdge.End.IsModule) {
    return false;
}

@erictraut
Copy link
Author

In the example you gave above, if the module directory contained an __init__.py file, the import from test.py should succeed. Would you expect lastEdge.End.IsModule to evaluate to false if __init__.py is present?

To answer your question. lastEdge.End.IsModule evaluates to true in my case, which is what causes the .exceptions and '.image_builder` imports to be incorrectly flagged as errors.

AlexanderSher added a commit to AlexanderSher/python-language-server that referenced this issue Jan 2, 2019
…t is found in another root directory

- Fix microsoft#510: PLS doesn't resolve relative paths correctly
AlexanderSher added a commit that referenced this issue Jan 2, 2019
- Fix #509: PLS doesn't flag error in a relative import if it is found in another root directory (#519)
- Fix #510: PLS doesn't resolve relative paths correctly
AlexanderSher added a commit to AlexanderSher/python-language-server that referenced this issue Feb 4, 2019
- Fix microsoft#509: PLS doesn't flag error in a relative import if it is found in another root directory (microsoft#519)
- Fix microsoft#510: PLS doesn't resolve relative paths correctly
AlexanderSher added a commit that referenced this issue Feb 4, 2019
* Fix #470 (#478)

* Fix various common exceptions, log on a failed directory load (#498)

* rethrow exception after telemetry instead of disposing

* log an error instead of crashing when hitting some exceptions loading files, fix nullref when shutting down without an idle tracker

* fix short circuiting of question mark checks to prevent null from being returned

* print name of exception instead of relying on ToString

* don't use MaybeEnumerate

* upgrade message to Show

* Mitigate some of #495 via MRO member selection and analysis set optimization (#517)

This isn't a complete fix, but does seem to improve #495 in some cases. Adds back the early MRO return removed in #277, so now large class hierarchies won't over-propagate types (where some of the trouble with fastai happens do to the Transform class). I also optimized AnalysisHashSet a little to do length checks when possible.

There are still times when things get caught up comparing unions for a while, but it seems to be nondeterministic.

* Two path resolution bug fixes

- Fix #509: PLS doesn't flag error in a relative import if it is found in another root directory (#519)
- Fix #510: PLS doesn't resolve relative paths correctly

* Catch exceptions when importing from search paths (#525)

* catch exceptions when importing from search paths

* retry instead of not found
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants