Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

There are two different module resolution for same code. #19402

Closed
zakuro9715 opened this issue Sep 21, 2023 · 1 comment
Closed

There are two different module resolution for same code. #19402

zakuro9715 opened this issue Sep 21, 2023 · 1 comment
Labels
Bug This tag is applied to issues which reports bugs. Module Lookup Problem Bugs/feature requests, that are related to looking up modules/mismatches in module names/paths.

Comments

@zakuro9715
Copy link
Member

zakuro9715 commented Sep 21, 2023

Describe the bug

When compiling the same code, module resolution changes depending on whether absolute or relative paths are specified.

Reproduction Steps

files:

cmd/foo/main/main.v
cmd/foo/foo.v
foo/foo.v
v.mod

cmd/foo/main.v:

module main
import foo

fn main() {
 println(foo.name)
}

cmd/foo/foo.v:

module foo

pub const name = '/cmd/foo'

foo/foo.v:

module foo

pub const name = '/foo'

$ v run cmd/foo/main/main.v
/foo
$ v run $(pwd)/cmd/foo/main/main.v
/cmd/foo

Expected Behavior

Always resolve to foo, not cmd.foo.

Current Behavior

There are two different module resolution

Possible Solution

This problem is caused by qualify_import.

v run cmd/foo/main/main.v -> import res 3

>  qualify_import: foo                | file_path: cmd/foo/main/main.v                                                     | =>   import_res 3: foo                ; ---, mod_path: foo

v run $(pwd)/cmd/foo/main/main.v -> import res 2

>  qualify_import: foo                | file_path: /home/zakuro/src/github.com/zakuro9715/v/same_name_mod/cmd/foo/main/main.v | =>   import_res 2: cmd.foo            ; /home/zakuro/src/github.com/zakuro9715/v/same_name_mod/cmd/foo/main/main.v

Additional Information/Context

This is the cause of #18993 #11348

V version

V 0.4.1 4f7dbbf

Environment details (OS name and version, etc.)

OS: linux, Ubuntu 22.04.1 LTS (WSL 2)
Processor: 16 cpus, 64bit, little endian, AMD Ryzen 7 3800X 8-Core Processor

getwd: /home/zakuro/src/github.com/zakuro9715/v
vexe: /home/zakuro/src/github.com/zakuro9715/v/v
vexe mtime: 2023-09-21 10:56:34

vroot: OK, value: /home/zakuro/src/github.com/zakuro9715/v
VMODULES: OK, value: /home/zakuro/.vmodules
VTMP: OK, value: /tmp/v_1000

env VFLAGS: "-cc clang"

Git version: git version 2.34.1
Git vroot status: weekly.2023.35-139-g4f7dbbfa
.git/config present: true

CC version: cc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
thirdparty/tcc status: thirdparty-linux-amd64 12f392c3

Important

You can vote for this issue using the 👍 reaction. More votes increase the issue's priority
for developers.

Take into account that only the 👍 reaction counts as a vote.
Only reactions to the issue itself will be counted as votes, not comments.

@zakuro9715 zakuro9715 added the Bug This tag is applied to issues which reports bugs. label Sep 21, 2023
@ArtemkaKun ArtemkaKun added the Module Lookup Problem Bugs/feature requests, that are related to looking up modules/mismatches in module names/paths. label Sep 22, 2023
@ttytm
Copy link
Member

ttytm commented Mar 10, 2024

Closing as I cannot reproduce this anymore.

Please reach out if you still encounter a problem like this, then we can reopen or work on it in a separate issue.

@ttytm ttytm closed this as completed Mar 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug This tag is applied to issues which reports bugs. Module Lookup Problem Bugs/feature requests, that are related to looking up modules/mismatches in module names/paths.
Projects
None yet
Development

No branches or pull requests

3 participants