www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11451] New: import statements don't work when compiling several files at once

reply d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11451

           Summary: import statements don't work when compiling several
                    files at once
           Product: D
           Version: D2
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: atila.neves gmail.com



---
This code reproduces the problem:

./foo/bar/baz.d:
void bazFunc() {
}

./bazuser.d: {
void userFunc() {
    bazFunc();
}



dmd -c foo/bar/baz.d bazuser.d
bazuser.d(1): Error: module baz from file foo/bar/baz.d must be imported as
module 'baz'

dmd -c bazuser.d foo/bar/baz.d 
bazuser.d(1): Error: module baz from file foo/bar/baz.d must be imported as
module 'baz'


This despite any "module" declaration. This makes using rdmd impossible with
the above code.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 06 2013
next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11451


Dicebot <public dicebot.lv> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |public dicebot.lv



Looks like "accepts invalid" for the first (separate compilation) case. You
always must have either import statement or explicit "extern" declaration to
use the symbol. Should be compilation error in both cases.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 06 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11451




Ah, I see what you mean, you examples are actually incomplete (it will fail to
compile with no import statements as expected)

Most likely you are trying to import baz.d from bazuser via `import
foo.bar.baz` and getting this error. This is expected and by design as module
name equals to file name by default and you are importing it via qualified
(package) name. Adding `module foo.bar.baz;` at top for baz.d will fix it.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 06 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11451




---


 Ah, I see what you mean, you examples are actually incomplete (it will fail to
 compile with no import statements as expected)
 
 Most likely you are trying to import baz.d from bazuser via `import
 foo.bar.baz` and getting this error. This is expected and by design as module
 name equals to file name by default and you are importing it via qualified
 (package) name. Adding `module foo.bar.baz;` at top for baz.d will fix it.


Yeah, sorry, I forgot to include `import foo.bar.baz` at the top of
`bazuser.d`. I know that adding `module foo.bar.baz` to `baz.d` will "fix it",
unless I decide to import it from somewhere else. Basically now the module
needs to know where it will be compiled from to declare itself properly, which
doesn't make any sense.

And besides, separate compilation works as intended, why would passing in both
file names make a difference?

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 06 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11451




D module system is tightly tied to the filesystem. When you change the root of
import path, module names change by design / spec. All existing D projects that
have packages define single "correct" import path for application to compile
and assign module names relative to it, it is intended way to go.

Now that you say it, it is quite interesting that separate compilation works
here. IMHO it shouldn't. For some reason compiling `dmd -c a.d` emits
unqualified `U` symbol into symbol file, this is why it does work. As far as I
understand, it really should emit a qualified one.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 06 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11451




---


 D module system is tightly tied to the filesystem. When you change the root of
 import path, module names change by design / spec. All existing D projects that
 have packages define single "correct" import path for application to compile
 and assign module names relative to it, it is intended way to go.
 
 Now that you say it, it is quite interesting that separate compilation works
 here. IMHO it shouldn't. For some reason compiling `dmd -c a.d` emits
 unqualified `U` symbol into symbol file, this is why it does work. As far as I
 understand, it really should emit a qualified one.


I know the module system is tied to the filesystem. I think it's an excellent
idea. I also understand that the module name changes depending on where you
compile it from. This is why when I'm at the root of the fictional project
above I import foo.bar.baz, not baz or bar.baz. That's all good, and it works
when I compile the files separately.

What doesn't work is compiling the files together, for some strange reason. I
went back to TDPL after I ran into this my understanding is that if you want to
control what name will be used to import it, then go ahead and use "module
blah". But that's not what I want, I want to use the directory structure.
Which, again, works when invoking dmd separately for each file but not when
passing multiple files in.

Am I missing something?

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 06 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11451




---

 http://dlang.org/module.html
 
 "The module name is the file name with the path and extension stripped off."


I'm still confused. So when is the module's fully qualified name ever used in
the absence of a module declaration? From the link above:

ImportDeclaration:
    import ImportList ;
    static import ImportList ;

ImportList:
    Import
    ImportBindings
    Import , ImportList

Import:
    ModuleFullyQualifiedName
    ModuleAliasIdentifier = ModuleFullyQualifiedName

and:

ModuleDeclaration:
    module ModuleFullyQualifiedName ;

ModuleFullyQualifiedName:
    ModuleName
    Packages . ModuleName

The way I still read it is if the module declaration is not present, then
ModuleName is the filename without the path or extension, but
ModuleFullyQualifiedName would depend on where compilation takes place.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 07 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11451






 So when is the module's fully qualified name ever used in
 the absence of a module declaration? 


Never. It is only used when provided explicitly.


 The way I still read it is if the module declaration is not present, then
 ModuleName is the filename without the path or extension, but
 ModuleFullyQualifiedName would depend on where compilation takes place.


I guess you may assume that `import` statement and module name are synchronized
in some way. This is not true. This is how import happens:

1) `import` statement gets directly converted into relative file path (dots
replaced with "/" and ".d" extension added)

2) If file with such relative path exists when searching from one of `-I`
paths, its module name is checked.

3) If `module` statement is present in file, it is used as module name.
Otherwise it is _always_ unqualified file name stripped from extension.

4) If module name does not match name in import statement, compilation error
happens. Comparison is fully qualified, so "src.mymod" != "mymod".

Your quoted text is not a language spec, it is just a grammar definition which
simply describes what statements are allowed to include qualified module name
(== "stuff with dots"). It says nothing about semantics.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 07 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11451




---
I think I finally got it, but it took some experimentation with different
directory and file names.

If I have it right, the only time I can get away with not using a module
declaration is when the file will only be imported by files in the same
directory as itself. Correct?

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 07 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11451


Dicebot <public dicebot.lv> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |enhancement





 I think I finally got it, but it took some experimentation with different
 directory and file names.
 
 If I have it right, the only time I can get away with not using a module
 declaration is when the file will only be imported by files in the same
 directory as itself. Correct?


Yep, exactly. This is exactly what I have meant by "not a bug, but good
enhancement request".

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 07 2013
prev sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11451




As a possible enhancement on this topic I'd propose to infer module name by
default to name qualified from base import path that was used to find the .d
file. Assuming that it later will be compiled with same path as base directory,
most simple layout should just work without redundant name duplication.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 26 2013