import ./modulename ignores the ./ path prefix

[tersec]

Description

import "."/tables
import ./tables

even in a directory with no tables.nim or other way of finding a tables module` to import, compiles.

https://nim-lang.org/docs/manual.html#modules-import-statement doesn't seem to explicitly document what should happen in this situation, but "." is a way of specifying a path. Indeed, attempting to import ./std/tables, for example, does not work, because it is being treated as a path, so there's an inconsistency here at least.

Nim Version

Nim Compiler Version 1.9.3 [Linux: amd64]
Compiled at 2023-06-10
Copyright (c) 2006-2023 by Andreas Rumpf

git hash: b2d77619757c73a8b14a8ccf127eaf3e630159cf
active boot switches: -d:release

Nim Compiler Version 1.6.12 [Linux: amd64]
Compiled at 2023-06-08
Copyright (c) 2006-2023 by Andreas Rumpf

git hash: 1aa9273640c0c51486cf3a7b67282fe58f360e91
active boot switches: -d:release

Current Output

/tmp/b.nim(2, 8) Hint: duplicate import of 'tables'; previous import here: /tmp/b.nim(1, 11) [DuplicateModuleImport]
/tmp/b.nim(1, 11) Warning: imported and not used: 'tables' [UnusedImport]
/tmp/b.nim(2, 8) Warning: imported and not used: 'tables' [UnusedImport]

Expected Output

Error: cannot open file: tables

Possible Solution

No response

Additional Information

No response

[metagn]

I think there is no special casing for relative paths, it just checks path / importedPath for every path supplied by --path:

import ../sugar # compiles because of lib/pure/collections/../sugar
import ../tables # fails

There might be related issues here or in https://github.com/nim-lang/RFCs with the keyword "relative"

[tersec]

Yeah, generally related RFCs:

• handling of relative path arguments in compiler flags should be consistent RFCs#73 is a kind of meta-issue around the inconsistency across different ways of specifying paths, but doesn't address import in any specific way
• import this/foo which resolves this to <current nimble root> RFCs#267 is especially related -- suggests this keyword which enforces the path aspect
• RFC: --path:prefix:path to resolve import prefix/suffix RFCs#291 notes other oddities/surprises about what kinds of paths/pseudo-paths are/aren't allowed in import

[arnetheduck]

+1 on this, . and other explicitly relative paths should not resolve in random locations .. this also opens for including nastiness like ../../etc/passwd and other security-sensitive files

[Araq]

That's the final thing I wanted to do for 2.0.