digitalmars.D.bugs - [Issue 11451] New: import statements don't work when compiling several files at once
- d-bugmail puremagic.com (34/34) Nov 06 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11451
- d-bugmail puremagic.com (12/12) Nov 06 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11451
- d-bugmail puremagic.com (11/11) Nov 06 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11451
- d-bugmail puremagic.com (13/20) Nov 06 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11451
- d-bugmail puremagic.com (13/13) Nov 06 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11451
- d-bugmail puremagic.com (18/27) Nov 06 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11451
- d-bugmail puremagic.com (26/29) Nov 07 2013 I'm still confused. So when is the module's fully qualified name ever us...
- d-bugmail puremagic.com (20/25) Nov 07 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11451
- d-bugmail puremagic.com (10/10) Nov 07 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11451
- d-bugmail puremagic.com (12/18) Nov 07 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11451
- d-bugmail puremagic.com (9/9) Nov 26 2013 https://d.puremagic.com/issues/show_bug.cgi?id=11451
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
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
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
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
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
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
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
https://d.puremagic.com/issues/show_bug.cgi?id=11451So 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
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
https://d.puremagic.com/issues/show_bug.cgi?id=11451 Dicebot <public dicebot.lv> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |enhancementI 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
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