[Issue 8858] DMD's -v option doesn't output dependencies with imports inside functions

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=8858

--- Comment #5 from Jonathan Marler  ---
This PR (https://github.com/dlang/dmd/pull/7400) adds the "-deps-" option to
dmd so that it will analyze dependencies without printing them.  This will
allow rdmd to get the imports via "-v" without adding extra work to create the
dependency file or print them to stderr.

This PR will add the "-deps-" option when rdmd calls dmd
(https://github.com/dlang/tools/pull/268).

--

[Issue 8858] DMD's -v option doesn't output dependencies with imports inside functions

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=8858

Jonathan Marler  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--

[Issue 8858] DMD's -v option doesn't output dependencies with imports inside functions

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=8858

Jonathan Marler  changed:

   What|Removed |Added

 CC||johnnymar...@gmail.com

--- Comment #4 from Jonathan Marler  ---
>From what I understand, getting all dependencies for a module requires more
overhead than it takes to just compile the file.  Compiling a single file only
requires loading the imports that the file references directly, the compiler
also loads indirect imports so long as they are global, but it isn't required
to do this.  That leaves local imports inside other imports to go unnocited. 
To force the compiler to load all the imports even when it just needs to
compile a single file would have a bad performance impact, therefore, it makes
sense to make this an option to be passed to the compiler.  This command line
option "-deps" already exists and already signals the compiler to load all the
modules.

Given this, I would mark this as "not a bug" saying that if you need to get all
the imports you should include the "-deps" flag to the compiler.

--

[Issue 8858] DMD's -v option doesn't output dependencies with imports inside functions

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=8858

--- Comment #3 from Timothee Cour  ---
*** Issue 8856 has been marked as a duplicate of this issue. ***

--

[Issue 8858] DMD's -v option doesn't output dependencies with imports inside functions

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=8858

Timothee Cour  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||timothee.co...@gmail.com
 Resolution|DUPLICATE   |---

--- Comment #2 from Timothee Cour  ---
Re-opening since https://issues.dlang.org/show_bug.cgi?id=7016 dealt with -deps
(cf title) whereas this issue deals with -v; 
7016 has been fixed but this issue is still there as of DMD64 D Compiler
v2.077.0.

This bug also affects rdmd, which is based on -v : rdmd does not use -deps
output - it uses -v (because -v includes more information); see also
https://www.bountysource.com/issues/44926161-fix-issue-7016-local-import-does-not-create-deps-dependency


a.d : import b; void main() { f(); }
b.d : int f() { import c; return i; }
c.d : int i = 42;

dmd -v -o- a.d
predefs   DigitalMars Posix OSX darwin LittleEndian D_Version2 all D_SIMD
D_InlineAsm_X86_64 X86_64 D_LP64 D_PIC assert D_HardFloat
binarydmd
version   v2.077.0
config/Users/timothee/homebrew/etc/dmd.conf
parse a
importall a
importobject   
(/Users/timothee/homebrew/opt/dmd/include/dlang/dmd/object.d)
importcore.attribute   
(/Users/timothee/homebrew/opt/dmd/include/dlang/dmd/core/attribute.d)
importb (b.d)
semantic  a
entry main  a.d
semantic2 a
semantic3 a

--

[Issue 8858] DMD's -v option doesn't output dependencies with imports inside functions

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8858


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||andrej.mitrov...@gmail.com
 Resolution||DUPLICATE


--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-01-11 
19:14:58 PST ---
Caused by same issue as in 7016.

*** This issue has been marked as a duplicate of issue 7016 ***

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

[Issue 8858] New: DMD's -v option doesn't output dependencies with imports inside functions

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8858

   Summary: DMD's -v option doesn't output dependencies with
imports inside functions
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: thelastmamm...@gmail.com


--- Comment #0 from thelastmamm...@gmail.com 2012-10-20 10:49:48 PDT ---
this issue is the cause of issue
http://d.puremagic.com/issues/show_bug.cgi?id=8856 (import inside function
sometimes causes link errors)

I'm reproducing here Andrej Mitrovic's comment to the above issue:

DMD's -v option doesn't output dependencies when an import is
function local.

test.d:
module test;
import foo;
void main() { }

foo.d:
module foo;
import bar;

bar.d is empty

$ dmd -c -v test.d
 importfoo   (foo.d)
 importbar   (bar.d)

Now use a local import in foo.d:

foo.d:
module foo;
void loc() { import bar; }

$ dmd -c -v test.d
 importfoo   (foo.d)

DMD doesn't output the import to bar.d when using -v. That has to be fixed.

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

[Issue 7622] Qualified imports inside functions don't work for real

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7622


SomeDude lovelyd...@mailmetrash.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||lovelyd...@mailmetrash.com
 Resolution||DUPLICATE


--- Comment #1 from SomeDude lovelyd...@mailmetrash.com 2012-04-21 06:07:41 
PDT ---
*** This issue has been marked as a duplicate of issue 7494 ***

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

[Issue 7622] New: Qualified imports inside functions don't work for real

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=7622

   Summary: Qualified imports inside functions don't work for real
   Product: D
   Version: D2
  Platform: x86
OS/Version: Windows
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2012-03-01 14:19:31 PST ---
This is almost a regression, this used to work, for a short time.

In DMD 2.059head this compiles with no errors, so it looks like qualified
imports are allowed inside functions:


void main() {
import std.stdio: writeln;
}



But it seems you can't use them:

void main() {
import std.stdio: writeln;
writeln(hello);
}


test.d(3): Error: 'writeln' is not defined, perhaps you need to import
std.stdio; ?

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

Re: imports in functions

[Jacob Carlborg]

On 2011-06-20 05:18, Ary Manzana wrote:

On 6/19/11 5:20 AM, Andrej Mitrovic wrote:

This is such a great debugging tool. I mean ddbg is great on its own.
But being able to quickly import std.stdio and do a few debug writes
in some library function is fantastic.


print-debugging is so common... in Ruby you always have puts
available, no need to require anything. Why not do the same for D?


puts, don't you use p? Shorter and prints better information.

--
/Jacob Carlborg

Re: imports in functions

[Ary Manzana]

On 6/20/11 3:04 PM, Jacob Carlborg wrote:

On 2011-06-20 05:18, Ary Manzana wrote:

On 6/19/11 5:20 AM, Andrej Mitrovic wrote:

This is such a great debugging tool. I mean ddbg is great on its own.
But being able to quickly import std.stdio and do a few debug writes
in some library function is fantastic.


print-debugging is so common... in Ruby you always have puts
available, no need to require anything. Why not do the same for D?


puts, don't you use p? Shorter and prints better information.



Ah, yes, you are right. I use it. p ! is my battle horse.

Re: imports in functions

[Nick Sabalausky]

Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message 
news:mailman.1030.1308543325.14074.digitalmar...@puremagic.com...
I think I've just found the first bug:

 module test;
 void main()
 {
 }

 void foo()
 {
import std.utf;
bla.toUTF16z;
 }

 Error: undefined identifier module test.toUTF16z

 UFCS doesn't work with function imports. This is a bug, right?

UFCS barely works at all in D2. Another example:

Regression(2.020) Array member call syntax can't find matches in current 
class
http://d.puremagic.com/issues/show_bug.cgi?id=4525

Re: imports in functions

[Andrej Mitrovic]

On 6/21/11, Nick Sabalausky a@a.a wrote:
 UFCS barely works at all in D2. Another example:

Couple that with the classically buggy 'with' statement and you've got
yourself a party! \o/

Re: imports in functions

[Andrej Mitrovic]

Aaaargh, I've used function imports, completely disregarding that
they're not present in 2.053 and now I can't deploy code to github
because people won't be able to compile it.

Ahh the joys.. Well I'm glad I caught this now before embarrassing myself.

Re: imports in functions

[Ary Manzana]

On 6/19/11 5:20 AM, Andrej Mitrovic wrote:

This is such a great debugging tool. I mean ddbg is great on its own.
But being able to quickly import std.stdio and do a few debug writes
in some library function is fantastic.


print-debugging is so common... in Ruby you always have puts 
available, no need to require anything. Why not do the same for D?

Re: imports in functions

[Andrej Mitrovic]

I think I've just found the first bug:

module test;
void main()
{
}

void foo()
{
import std.utf;
bla.toUTF16z;
}

Error: undefined identifier module test.toUTF16z

UFCS doesn't work with function imports. This is a bug, right?

Re: imports in functions

[Andrej Mitrovic]

This is such a great debugging tool. I mean ddbg is great on its own.
But being able to quickly import std.stdio and do a few debug writes
in some library function is fantastic.

Re: imports in functions

[Jacob Carlborg]

On 2011-06-12 23:15, Walter Bright wrote:

Nobody seems to have noticed yet, but yesterday I removed the
restriction preventing import declarations from being used in functions.
These now work:

void test1()
{
import std.c.stdio;
printf(hello world\n);
}

void test2()
{
static import std.c.stdio;
std.c.stdio.printf(hello world\n);
}

https://github.com/D-Programming-Language/dmd/commit/d5fbd53aa8d8452dce2514944575e654d387477a


I believe this can lead to better encapsulation of code, especially when
using mixins, versioning and other conditional compilation constructs.


This is awesome.

--
/Jacob Carlborg

Re: imports in functions

[Robert Clipsham]

On 12/06/2011 22:15, Walter Bright wrote:

Nobody seems to have noticed yet, but yesterday I removed the
restriction preventing import declarations from being used in functions.
These now work:

void test1()
{
import std.c.stdio;
printf(hello world\n);
}

void test2()
{
static import std.c.stdio;
std.c.stdio.printf(hello world\n);
}

https://github.com/D-Programming-Language/dmd/commit/d5fbd53aa8d8452dce2514944575e654d387477a


I believe this can lead to better encapsulation of code, especially when
using mixins, versioning and other conditional compilation constructs.


I did notice this - I think it's awesome. So many times when debugging 
code I've attempted to write import std.stdio; in the function, then had 
to move it away from the code I was debugging - of course this left a 
stray import because I forgot about it :3


--
Robert
http://octarineparrot.com/

Re: imports in functions

[Andrej Mitrovic]

I'm having some fun with this.

import std.array;

void main()
{
with (namespace!(std.stdio std.algorithm std.range))
{
auto squares = map!(a * a)([2, 4, 6]);
writeln(squares);
}
}

template namespace(string x)
{
mixin(namespaceImpl(x));
}

string namespaceImpl(string x)
{
string result;
auto mods = split(x);
foreach (val; mods)
{
result ~= import  ~ val ~ ;;
}
return result;
}

Re: imports in functions

[Andrej Mitrovic]

Btw, it's disappointing that I can't call split with a separator at
compile-time:

enum result = split(bla, bla);  // ok
enum result = split(bla, bla, ,);  // nope

Re: imports in functions

[KennyTM~]

On Jun 14, 11 03:55, Andrej Mitrovic wrote:

Btw, it's disappointing that I can't call split with a separator at
compile-time:

enum result = split(bla, bla);  // ok
enum result = split(bla, bla, ,);  // nope


That's due to (at least) http://d.puremagic.com/issues/show_bug.cgi?id=4047.

Re: imports in functions

[Andrej Mitrovic]

Walter, it looks like this addition inadvertently fixes the issue of
DLLs not linkable due to Phobos imports.

I've had this DLL (alongside with dllmodule.d which had initialization
calls inside DLLMain):
module EdrLib;

import std.utf;

pragma(lib, gdi32.lib);
pragma(lib, comdlg32.lib);
import win32.windef;
import win32.wingdi;

export extern(Windows) BOOL EdrCenterText(HDC hdc, PRECT prc, string pString)
{
 SIZE size ;
 GetTextExtentPoint32(hdc, pString.toUTF16z, pString.length, size) ;
 return TextOut(hdc, (prc.right - prc.left - size.cx) / 2,
 (prc.bottom - prc.top - size.cy) / 2,
pString.toUTF16z, pString.length);
}

The header file produced from this would cause any client code which
imports the header to look for ModuleInitZ, which wouldn't exist in
the generated import library since it's an import library and not a
static library.

But, if I move the phobos import inside the EdrCenterText function:

export extern(Windows) BOOL EdrCenterText(HDC hdc, PRECT prc, string pString)
{
 import std.utf;

 SIZE size ;
 GetTextExtentPoint32(hdc, pString.toUTF16z, pString.length, size) ;
 return TextOut(hdc, (prc.right - prc.left - size.cx) / 2,
 (prc.bottom - prc.top - size.cy) / 2,
pString.toUTF16z, pString.length);
}

Then it works. My related bug report about this (and its complicated
to read due to various misunderstanding on my part) is
http://d.puremagic.com/issues/show_bug.cgi?id=6019.

But it's great that there's an actual workaround now!

Re: imports in functions

[Brad Roberts]

On 6/13/2011 8:28 PM, Andrej Mitrovic wrote:
 Walter, it looks like this addition inadvertently fixes the issue of
 DLLs not linkable due to Phobos imports.
 
 I've had this DLL (alongside with dllmodule.d which had initialization
 calls inside DLLMain):
 module EdrLib;
 
 import std.utf;
 
 pragma(lib, gdi32.lib);
 pragma(lib, comdlg32.lib);
 import win32.windef;
 import win32.wingdi;
 
 export extern(Windows) BOOL EdrCenterText(HDC hdc, PRECT prc, string pString)
 {
  SIZE size ;
  GetTextExtentPoint32(hdc, pString.toUTF16z, pString.length, size) ;
  return TextOut(hdc, (prc.right - prc.left - size.cx) / 2,
  (prc.bottom - prc.top - size.cy) / 2,
 pString.toUTF16z, pString.length);
 }
 
 The header file produced from this would cause any client code which
 imports the header to look for ModuleInitZ, which wouldn't exist in
 the generated import library since it's an import library and not a
 static library.
 
 But, if I move the phobos import inside the EdrCenterText function:
 
 export extern(Windows) BOOL EdrCenterText(HDC hdc, PRECT prc, string pString)
 {
  import std.utf;
 
  SIZE size ;
  GetTextExtentPoint32(hdc, pString.toUTF16z, pString.length, size) ;
  return TextOut(hdc, (prc.right - prc.left - size.cx) / 2,
  (prc.bottom - prc.top - size.cy) / 2,
 pString.toUTF16z, pString.length);
 }
 
 Then it works. My related bug report about this (and its complicated
 to read due to various misunderstanding on my part) is
 http://d.puremagic.com/issues/show_bug.cgi?id=6019.
 
 But it's great that there's an actual workaround now!

This makes me think that there's actually a bug in the function-local imports.  
I'm guessing they don't run module-level
ctors and dtors for the imported modules.  Would you mind putting together a 
test case to check?

Thanks,
Brad

Re: imports in functions

[Andrej Mitrovic]

When I add module ctors/dtors, I get the ModuleInfoZ shenanigans again.

Re: imports in functions

[Andrej Mitrovic]

And they do run, I've tested it in a non-DLL example.

Re: imports in functions

[Andrej Mitrovic]

I'm guessing this is what you're after:

http://codepad.org/TCtG68Fw
http://codepad.org/65GBDjPS

rdmd main.d
shared ctor!
ctor!
foo.test
dtor!
shared dtor!

Re: imports in functions

[Andrej Mitrovic]

Should DLLs even have module ctors/dtors?

I think this is what DLLMain's DLL_PROCESS_ATTACH, DLL_THREAD_ATTACH
and their detach counterparts are for.

Re: imports in functions

[Brad Roberts]

On 6/13/2011 8:48 PM, Andrej Mitrovic wrote:
 I'm guessing this is what you're after:
 
 http://codepad.org/TCtG68Fw
 http://codepad.org/65GBDjPS
 
 rdmd main.d
 shared ctor!
 ctor!
 foo.test
 dtor!
 shared dtor!

Actually, not what I was thinking.  I was thinking something like this:

file 1:
import std.stdio; // or inside this, not what I'm testing.
static this()
{
writeln(foo);
}

file 2:
void main()
{
import file1;
}

Re: imports in functions

[Andrej Mitrovic]

Well it seems to work fine. :)

imports in functions

[Walter Bright]

Nobody seems to have noticed yet, but yesterday I removed the restriction 
preventing import declarations from being used in functions. These now work:


void test1()
{
import std.c.stdio;
printf(hello world\n);
}

void test2()
{
static import std.c.stdio;
std.c.stdio.printf(hello world\n);
}

https://github.com/D-Programming-Language/dmd/commit/d5fbd53aa8d8452dce2514944575e654d387477a

I believe this can lead to better encapsulation of code, especially when using 
mixins, versioning and other conditional compilation constructs.

Re: imports in functions

[Andrei Alexandrescu]

On 06/12/2011 04:15 PM, Walter Bright wrote:

Nobody seems to have noticed yet, but yesterday I removed the
restriction preventing import declarations from being used in functions.
These now work:

void test1()
{
import std.c.stdio;
printf(hello world\n);
}

void test2()
{
static import std.c.stdio;
std.c.stdio.printf(hello world\n);
}

https://github.com/D-Programming-Language/dmd/commit/d5fbd53aa8d8452dce2514944575e654d387477a


I believe this can lead to better encapsulation of code, especially when
using mixins, versioning and other conditional compilation constructs.


Fabulous. std.benchmark already uses the feature, and from a mixin no less:

https://github.com/andralex/phobos/commit/c5f2778a0fc393d6bd17ebec4765b28937575c31

One interesting aspect of the feature is that if import is used from 
within a template, it's not actually imported unless the template is 
instantiated.


Andrei

Re: imports in functions

[Adam D. Ruppe]

This is awesome!

Another benefit here is code running programs are simplified. For
D script kind of things, a technique I use is to simply wrap some
code inside a main function. Almost every feature worked there -
nested functions, structs, classes, etc. Now imports do too! Yay!

Re: imports in functions

[Andrei Alexandrescu]

On 06/12/2011 04:33 PM, Adam D. Ruppe wrote:

This is awesome!

Another benefit here is code running programs are simplified. For
D script kind of things, a technique I use is to simply wrap some
code inside a main function. Almost every feature worked there -
nested functions, structs, classes, etc. Now imports do too! Yay!


This bodes well for your run this online thing, too. All we need to do 
is wrap a main() around the example code and it should work.


Andrei

Re: imports in functions

[Andrej Mitrovic]

This seems like a way to simulate namespaces in C++, right? I wouldn't
know, but it looks similar to that 'using foo' trick.

Re: imports in functions

[Lars T. Kyllingstad]

On Sun, 12 Jun 2011 14:15:27 -0700, Walter Bright wrote:

 Nobody seems to have noticed yet, but yesterday I removed the
 restriction preventing import declarations from being used in functions.
 These now work:
 
 void test1()
 {
  import std.c.stdio;
  printf(hello world\n);
 }
 
 void test2()
 {
  static import std.c.stdio;
  std.c.stdio.printf(hello world\n);
 }
 
 https://github.com/D-Programming-Language/dmd/commit/
d5fbd53aa8d8452dce2514944575e654d387477a
 
 I believe this can lead to better encapsulation of code, especially when
 using mixins, versioning and other conditional compilation constructs.

Cool!  This is a definite improvement. :)

-Lars

Re: imports in functions

[Dmitry Olshansky]

On 13.06.2011 1:15, Walter Bright wrote:
Nobody seems to have noticed yet, but yesterday I removed the 
restriction preventing import declarations from being used in 
functions. These now work:


void test1()
{
import std.c.stdio;
printf(hello world\n);
}

void test2()
{
static import std.c.stdio;
std.c.stdio.printf(hello world\n);
}

https://github.com/D-Programming-Language/dmd/commit/d5fbd53aa8d8452dce2514944575e654d387477a 



I believe this can lead to better encapsulation of code, especially 
when using mixins, versioning and other conditional compilation 
constructs.


Also very helpful for unittests, thanks.

--
Dmitry Olshansky

Re: imports in functions

[Jonathan M Davis]

On 2011-06-12 15:08, Andrej Mitrovic wrote:
 This seems like a way to simulate namespaces in C++, right? I wouldn't
 know, but it looks similar to that 'using foo' trick.

C++ namespaces are completely different. Everything in a namespace has to be 
referenced by its namespace explicitly unless you use using. So, without 
using, you need to do stuff like

std::vectorint v;

whereas with

using namespace std;
vectorint v;

you don't need the std:: tag anymore. Using namespace affects _everything_ 
after it, which is why it's pretty much verboten in header files (otherwise it 
would pollute the global namespace). And whether you have a using statement or 
not, as soon as you #include a file, everything in it is visible in the 
current file. Namespaces just segregate the names so that they don't clash.

D modules are very different. As soon as you import a module, everything in 
that module is visible (though you can't use anything in it unless it's public 
or the current module is in the same package and it's package or if you're 
deriving from class in that module and the symbol in question is protected). 
You don't have to use the module name when using _any_ of its symbols unless 
names clash or you imported the module statically. It's kind of like you 
automatically have a using statement all of the time, except that it's much 
more sophisticated and handles name clashes much better.

By importing within a function, you're saying that only that function has 
access to the symbols within the module being imported. As for as the rest of 
the module is concerned, the imported module does not actually exist. You're 
restricting what can see it.

So, I'm not quite sure what you mean by this simulating C++ namespaces. They 
both deal with how symbols are brought into and viewable in the current file, 
but they're very different.

- Jonathan M Davis

Re: imports in functions

[Andrej Mitrovic]

On 6/13/11, Jonathan M Davis jmdavisp...@gmx.com wrote:
 snip

So much for my blurry recollection of C++ features. :-)

Re: imports in functions

[Andrei Alexandrescu]

On 6/12/11 5:08 PM, Andrej Mitrovic wrote:

This seems like a way to simulate namespaces in C++, right? I wouldn't
know, but it looks similar to that 'using foo' trick.


I hope not :o). C++ namespaces are quite lacking.

Andrei