www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - local import hijacking

reply Byron Heads <bheads moxiegroup.com> writes:
I got burned by this yesterday, this code should not compile

import std.experimental.logger : trace;


void foo() {
	import std.net.curl : trace;
	trace("hello");
}


void main() {
	foo();	
}


Not sure if this is a duplicate
https://issues.dlang.org/show_bug.cgi?id=15567
Jan 14
next sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
V Thu, 14 Jan 2016 14:25:43 +0000
Byron Heads via Digitalmars-d <digitalmars-d puremagic.com> napsáno:

 I got burned by this yesterday, this code should not compile
 
 import std.experimental.logger : trace;
 
 
 void foo() {
 	import std.net.curl : trace;
 	trace("hello");
 }
 
 
 void main() {
 	foo();	
 }
 
 
 Not sure if this is a duplicate
 https://issues.dlang.org/show_bug.cgi?id=15567
 
 
 
No this is OK, there is no reason to not compile. It is same as: import std.stdio; string trace = "trace"; void foo() { int trace = 7; writeln(trace); } void main() { foo(); writeln(trace); } local symbols can hide global symbols
Jan 14
next sibling parent reply Byron Heads <bheads moxiegroup.com> writes:
On Thursday, 14 January 2016 at 14:36:23 UTC, Daniel Kozak wrote:
 V Thu, 14 Jan 2016 14:25:43 +0000
 Byron Heads via Digitalmars-d <digitalmars-d puremagic.com> 
 napsáno:

 I got burned by this yesterday, this code should not compile
 
 import std.experimental.logger : trace;
 
 
 void foo() {
 	import std.net.curl : trace;
 	trace("hello");
 }
 
 
 void main() {
 	foo();
 }
 
 
 Not sure if this is a duplicate 
 https://issues.dlang.org/show_bug.cgi?id=15567
 
 
 
No this is OK, there is no reason to not compile. It is same as: import std.stdio; string trace = "trace"; void foo() { int trace = 7; writeln(trace); } void main() { foo(); writeln(trace); } local symbols can hide global symbols
import std.experimental.logger; void foo() { import std.net.curl; .... lots of curl calls trace("hello"); .. more curl calls } void main() { foo(); } std.net.curl.CurlException std\net\curl.d(4033): Couldn't resolve host name on handle 2188398 ---------------- 0x00405F65 0x00405F10 0x0040275B 0x0040259E 0x0040202B 0x00402035 0x004257A7 0x004256A8 0x0041B7FF 0x769F337A in BaseThreadInitThunk 0x77429882 in RtlInitializeExceptionChain 0x77429855 in RtlInitializeExceptionChain This was a 4 hour debug which made it worse as I was adding more trace calls to figure out what was going on. My boss is now on the fence, to many compiler bugs with D, he asked me to switch to Java if I have to deal to many more issues like this.. (https://issues.dlang.org/show_bug.cgi?id=15457 another issue we had) And this awesome stack trace helped me so much to track this issue down...
Jan 14
next sibling parent Byron Heads <bheads moxiegroup.com> writes:
On Thursday, 14 January 2016 at 14:56:39 UTC, Byron Heads wrote:
 On Thursday, 14 January 2016 at 14:36:23 UTC, Daniel Kozak 
 wrote:
 [...]
import std.experimental.logger; void foo() { import std.net.curl; .... lots of curl calls trace("hello"); .. more curl calls } void main() { foo(); } std.net.curl.CurlException std\net\curl.d(4033): Couldn't resolve host name on handle 2188398 ---------------- 0x00405F65 0x00405F10 0x0040275B 0x0040259E 0x0040202B 0x00402035 0x004257A7 0x004256A8 0x0041B7FF 0x769F337A in BaseThreadInitThunk 0x77429882 in RtlInitializeExceptionChain 0x77429855 in RtlInitializeExceptionChain This was a 4 hour debug which made it worse as I was adding more trace calls to figure out what was going on. My boss is now on the fence, to many compiler bugs with D, he asked me to switch to Java if I have to deal to many more issues like this.. (https://issues.dlang.org/show_bug.cgi?id=15457 another issue we had) And this awesome stack trace helped me so much to track this issue down...
Also why is this not allowed then? import std.stdio; void main() { auto x = "foo"; for(int x = 0; x < 10; ++x) { writeln(x); } } Error: variable x is shadowing variable f335.main.x Shadowing is bad and leads to bugs!
Jan 14
prev sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
On Thursday, 14 January 2016 at 14:56:39 UTC, Byron Heads wrote:
 std.net.curl.CurlException std\net\curl.d(4033): Couldn't 
 resolve host name on handle 2188398
 ----------------
 0x00405F65
 0x00405F10
 0x0040275B
 0x0040259E
 0x0040202B
 0x00402035
 0x004257A7
 0x004256A8
 0x0041B7FF
 0x769F337A in BaseThreadInitThunk
 0x77429882 in RtlInitializeExceptionChain
 0x77429855 in RtlInitializeExceptionChain

 This was a 4 hour debug which made it worse as I was adding 
 more trace calls to figure out what was going on.  My boss is 
 now on the fence, to many compiler bugs with D, he asked me to 
 switch to Java if I have to deal to many more issues like 
 this.. (https://issues.dlang.org/show_bug.cgi?id=15457  another 
 issue we had)

 And this awesome stack trace helped me so much to track this 
 issue down...
What compiler are you using? The useless stack traces got fixed in a fairly recent version of DMD - as have many, many other issues which are still present in GDC, whose front end is several versions out-of-date. It is recommended to do your testing with DMD because of issues like this, and mostly use GDC for making optimized release builds. Alternately, if you don't want to mix two compilers like that, LDC has good performance and is currently significantly more up-to-date than GDC. Or, you could even just use DMD, as the performance of its generated binaries has improved a whole lot in the past two releases, although it is of course still not as good as GDC or LDC in this respect. More generally, though, much as we might not like to admit it, D2 is still beta quality software. It is *vastly* more stable and less frustrating to work with than it was a few years ago when I first tried it, but it still has a long way to go before compiler problems cease to be a part of normal day-to-day usage. If that's not acceptable to you or your business, you really probably should just use something else and check back in five years or so...
Jan 14
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2016-01-14 at 21:36 +0000, tsbockman via Digitalmars-d wrote:
=20
[=E2=80=A6]
 The useless stack traces got fixed in a fairly recent version of=C2=A0
 DMD - as have many, many other issues which are still present in=C2=A0
 GDC, whose front end is several versions out-of-date.
"several versions behind" might be a better way if putting this. The release cycles of DMD (basically unconstrained), LDC (basically unconstrained), and GDC (heavily constrained), mean that "out of date" is a bad marketing phrase. Especially=E2=80=A6
 It is recommended to do your testing with DMD because of issues=C2=A0
 like this, and mostly use GDC for making optimized release builds.
=E2=80=A6given this.=C2=A0 Clearly the D community needs to try and ensure that each GCC bundle release has teh latest possible D in it, but we must also be positive about which version each compiler supports.
 Alternately, if you don't want to mix two compilers like that,=C2=A0
 LDC has good performance and is currently significantly more=C2=A0
 up-to-date than GDC. Or, you could even just use DMD, as the=C2=A0
 performance of its generated binaries has improved a whole lot in=C2=A0
 the past two releases, although it is of course still not as good=C2=A0
 as GDC or LDC in this respect.
=20
 More generally, though, much as we might not like to admit it, D2=C2=A0
 is still beta quality software. It is *vastly* more stable and=C2=A0
 less frustrating to work with than it was a few years ago when I=C2=A0
 first tried it, but it still has a long way to go before compiler=C2=A0
 problems cease to be a part of normal day-to-day usage.
=20
 If that's not acceptable to you or your business, you really=C2=A0
 probably should just use something else and check back in five=C2=A0
 years or so...
I find this the wrong view of progress, yet one that remains embedded in far too many organizations. It comes in two parts: 1. If a product has changed at all in the last six months, other than trivial bug fixes, it isn't stable enough to use in production. 2. Once we have stuff out in production, nothing may be changed until end of life. Clearly the opposite extreme of "we must use the very latest of every early-access version we can get out hands on" is equally dangerous in production. There is a middle ground. Keep everything as up to date with formally released versions as possible, taking on a continuous change and evolution strategy. In this mindset D is certainly stable enough for production, it is not beta software. DMD is the playground compiler, GDC the conservative but solid one, and LDC the core production tool. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 15
parent tsbockman <thomas.bockman gmail.com> writes:
On Friday, 15 January 2016 at 08:12:03 UTC, Russel Winder wrote:
 "several versions behind" might be a better way if putting 
 this. The release cycles of DMD (basically unconstrained),
 LDC (basically unconstrained), and GDC (heavily constrained),
 mean that "out of date" is a bad marketing phrase.
I wasn't trying to market D; I was simply offering my advice to the OP. I think D is a fantastic language, but I'm not going to downplay what I perceive to be its shortcomings.
 I find this the wrong view of progress, yet one that remains 
 embedded in far too many organizations. It comes in two parts:

 1. If a product has changed at all in the last six months, 
 other than trivial bug fixes, it isn't stable enough to use in 
 production.

 2. Once we have stuff out in production, nothing may be changed 
 until end of life.

 Clearly the opposite extreme of "we must use the very latest of 
 every early-access version we can get out hands on" is equally 
 dangerous in production. There is a middle ground. Keep 
 everything as up to date with formally released versions as 
 possible, taking on a continuous change and evolution strategy.

 In this mindset D is certainly stable enough for production, it 
 is not beta software. DMD is the playground compiler, GDC the 
 conservative but solid one, and LDC the core production tool.
That is not my mindset. I consider D beta-quality because whenever I program in D, I encounter bugs (both new and old) in the compiler and/or standard library on almost a daily basis. This has not been my experience with other languages that have more money behind them, like Java (never hit a bug in my life, that I'm aware of), C# (once?), or C++ (so byzantine that I'm not sure I would notice - that's why I prefer D :-) ). None of the bugs I've hit recently has been too difficult to diagnose and work around, which is why I no longer consider D alpha-quality. I, personally, would be comfortable using D in production - but that's because I have a high tolerance for the kinds of minor issues beta software brings with it; not everyone does. And to be clear - I think GDC is awesome. But I also think that someone with a low tolerance for issues like the one the OP complained about will be happier using DMD or LDC, as I find the newer front-ends noticeably less buggy in day-to-day use. Horses for courses.
Jan 15
prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 15 Jan 2016 9:12 am, "Russel Winder via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
 In this mindset D is certainly stable enough for production, it is not
 beta software. DMD is the playground compiler, GDC the conservative but
 solid one, and LDC the core production tool.

 --
 Russel.
Thanks for putting it so eloquently, Russell. Iain.
Jan 15
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Friday, 15 January 2016 at 08:15:50 UTC, Iain Buclaw wrote:
 On 15 Jan 2016 9:12 am, "Russel Winder via Digitalmars-d" < 
 digitalmars-d puremagic.com> wrote:
 In this mindset D is certainly stable enough for production, 
 it is not beta software. DMD is the playground compiler, GDC 
 the conservative but solid one, and LDC the core production 
 tool.

 --
 Russel.
Thanks for putting it so eloquently, Russell. Iain.
The difficulty is that gdc includes a lot of long-standing bugs that are fixed upstream.
Jan 15
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 15 January 2016 at 23:50, John Colvin via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Friday, 15 January 2016 at 08:15:50 UTC, Iain Buclaw wrote:

 On 15 Jan 2016 9:12 am, "Russel Winder via Digitalmars-d" <
 digitalmars-d puremagic.com> wrote:

 In this mindset D is certainly stable enough for production, it is not
 beta software. DMD is the playground compiler, GDC the conservative but
 solid one, and LDC the core production tool.

 --
 Russel.
Thanks for putting it so eloquently, Russell. Iain.
The difficulty is that gdc includes a lot of long-standing bugs that are fixed upstream.
GDC is rarely a vanilla cut of the version it supports, and no one should be allergic to submitting backports of library or frontend fixes. It is afterall Boost licensed. :-)
Jan 16
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 14 Jan 2016 21:36:01 +0000
schrieb tsbockman <thomas.bockman gmail.com>:

 On Thursday, 14 January 2016 at 14:56:39 UTC, Byron Heads wrote:
 std.net.curl.CurlException std\net\curl.d(4033): Couldn't 
 resolve host name on handle 2188398
 ----------------
 0x00405F65
 0x00405F10
 0x0040275B
 0x0040259E
 0x0040202B
 0x00402035
 0x004257A7
 0x004256A8
 0x0041B7FF
 0x769F337A in BaseThreadInitThunk
 0x77429882 in RtlInitializeExceptionChain
 0x77429855 in RtlInitializeExceptionChain

 This was a 4 hour debug which made it worse as I was adding 
 more trace calls to figure out what was going on.  My boss is 
 now on the fence, to many compiler bugs with D, he asked me to 
 switch to Java if I have to deal to many more issues like 
 this.. (https://issues.dlang.org/show_bug.cgi?id=15457  another 
 issue we had)

 And this awesome stack trace helped me so much to track this 
 issue down...  
What compiler are you using? The useless stack traces got fixed in a fairly recent version of DMD - as have many, many other issues which are still present in GDC, whose front end is several versions out-of-date.
I'm not sure why you even think the OP is using GDC. His bug report says he's on windows 10. GDC is not supported on windows systems and won't work for anything but trivial programs. And stack traces is one thing GDC has had proper support way before DMD. We have proper stack traces since June 2013: https://github.com/D-Programming-GDC/GDC/pull/65 https://github.com/D-Programming-GDC/GDC/commit/fbde3698398f85768bcf918a7a777d81fd0ac3ed
Jan 15
parent tsbockman <thomas.bockman gmail.com> writes:
On Friday, 15 January 2016 at 09:05:27 UTC, Johannes Pfau wrote:
 I'm not sure why you even think the OP is using GDC. His bug 
 report says he's on windows 10. GDC is not supported on windows 
 systems and won't work for anything but trivial programs.

 And stack traces is one thing GDC has had proper support way 
 before
 DMD. We have proper stack traces since June 2013:
 https://github.com/D-Programming-GDC/GDC/pull/65
 https://github.com/D-Programming-GDC/GDC/commit/fbde3698398f85768bcf918a7a777d81fd0ac3ed
Good to know. I was really trying to ask what front-end version he's using, though.
Jan 15
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/14/2016 09:36 AM, Daniel Kozak via Digitalmars-d wrote:
 V Thu, 14 Jan 2016 14:25:43 +0000
 Byron Heads via Digitalmars-d <digitalmars-d puremagic.com> napsáno:

 I got burned by this yesterday, this code should not compile

 import std.experimental.logger : trace;


 void foo() {
 	import std.net.curl : trace;
 	trace("hello");
 }


 void main() {
 	foo();	
 }


 Not sure if this is a duplicate
 https://issues.dlang.org/show_bug.cgi?id=15567
No this is OK, there is no reason to not compile. It is same as: import std.stdio; string trace = "trace"; void foo() { int trace = 7; writeln(trace); } void main() { foo(); writeln(trace); } local symbols can hide global symbols
Correct. The implicitly introduced locals are the problem. Can anyone on the compiler team work on this? -- Andrei
Jan 14
parent reply Martin Nowak <code dawg.eu> writes:
On Thursday, 14 January 2016 at 16:10:29 UTC, Andrei Alexandrescu 
wrote:
 local symbols can hide global symbols
Correct. The implicitly introduced locals are the problem. Can anyone on the compiler team work on this? -- Andrei
No, we cannot just jump to anything that pops up on the newsgroup, b/c we would only be jump but no longer work on anything. I've trying to put fixing the whole import system on the agenda for the past 2 releases, but didn't got much feedback. Import issues are constantly breaking code (e.g. http://forum.dlang.org/post/mailman.3708.1453114739.22025.digitalmars-d-ann unce puremagic.com) and cause such troubles during development. I think it's time to dedicate a whole release to work on imports.
Jan 18
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Monday, 18 January 2016 at 13:17:54 UTC, Martin Nowak wrote:
 I think it's time to dedicate a whole release to work on 
 imports.
Please do. D is damn lucky that the main problem people think it has is the GC while it's sitting there with a half finished import system.
Jan 18
parent reply rsw0x <anonymous anonymous.com> writes:
On Monday, 18 January 2016 at 13:26:24 UTC, Jack Stouffer wrote:
 On Monday, 18 January 2016 at 13:17:54 UTC, Martin Nowak wrote:
 I think it's time to dedicate a whole release to work on 
 imports.
Please do. D is damn lucky that the main problem people think it has is the GC while it's sitting there with a half finished import system.
I'm not sure I agree on 'half finished', one of the biggest things D has over C++ is its vastly superior module system. Is there a compiled list of issues?
Jan 18
parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Monday, 18 January 2016 at 14:01:15 UTC, rsw0x wrote:
 one of the biggest things D has over C++ is its vastly superior 
 module system.
When you compare D's something with C++'s nothing, then the module system in D is infinitely better by definition.
 Is there a compiled list of issues?
1. As deadalnix pointed out, a lack of spec 2. Issue 313 3. Issue 314 4. Issue 10378 These are the biggest IMO. There are probably others I don't know of.
 I'm not sure I agree on 'half finished'
When looking at the above issues, it becomes clear that the D module system does not completely provide one of the main things module systems are designed for: encapsulation.
Jan 18
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/18/2016 06:02 PM, Jack Stouffer wrote:
 Is there a compiled list of issues?
1. As deadalnix pointed out, a lack of spec 2. Issue 313 3. Issue 314 4. Issue 10378 These are the biggest IMO. There are probably others I don't know of.
https://issues.dlang.org/show_bug.cgi?id=1238
Jan 18
prev sibling parent Joakim <dlang joakim.fea.st> writes:
On Monday, 18 January 2016 at 17:02:07 UTC, Jack Stouffer wrote:
 On Monday, 18 January 2016 at 14:01:15 UTC, rsw0x wrote:
 one of the biggest things D has over C++ is its vastly 
 superior module system.
When you compare D's something with C++'s nothing, then the module system in D is infinitely better by definition.
 Is there a compiled list of issues?
1. As deadalnix pointed out, a lack of spec 2. Issue 313 3. Issue 314 4. Issue 10378 These are the biggest IMO. There are probably others I don't know of.
 I'm not sure I agree on 'half finished'
When looking at the above issues, it becomes clear that the D module system does not completely provide one of the main things module systems are designed for: encapsulation.
The problem is that D's import system is much more advanced than those in C++ or Java, allowing much more control and precision over what's imported, so some leaks have sprung in D's more complex module implementation. Certainly much more than half, but definitely not finished. :) If you simply stick a bunch of non-selective imports at the top of a module, ie non-local, and all the modules you import do the same (this is tougher, as not everybody is aware of the issue and some library might leak symbols into your module if they're not as conservative), you'll have no problem. If you use more advanced features like selective or local imports, there are a few places they leak symbols or can shadow variables in non-intuitive ways, as the issues you listed enumerate.
Jan 18
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Monday, 18 January 2016 at 13:17:54 UTC, Martin Nowak wrote:
 On Thursday, 14 January 2016 at 16:10:29 UTC, Andrei 
 Alexandrescu wrote:
 local symbols can hide global symbols
Correct. The implicitly introduced locals are the problem. Can anyone on the compiler team work on this? -- Andrei
No, we cannot just jump to anything that pops up on the newsgroup, b/c we would only be jump but no longer work on anything. I've trying to put fixing the whole import system on the agenda for the past 2 releases, but didn't got much feedback. Import issues are constantly breaking code (e.g. http://forum.dlang.org/post/mailman.3708.1453114739.22025.digitalmars-d-ann unce puremagic.com) and cause such troubles during development. I think it's time to dedicate a whole release to work on imports.
I tried to simply define imports, and it is way more complex than you'd expect. We probably need some spec first.
Jan 18
prev sibling parent reply anonymous <anonymous example.com> writes:
On 14.01.2016 15:25, Byron Heads wrote:
 I got burned by this yesterday, this code should not compile

 import std.experimental.logger : trace;


 void foo() {
      import std.net.curl : trace;
      trace("hello");
 }


 void main() {
      foo();
 }
I don't see a problem with that specific code. You're explicitly importing `trace` from std.net.curl, so it can't be surprising that it's called. But change one little detail and this qualifies as hijacking, I think: ---- void foo() { import std.net.curl; /* not mentioning trace */ trace("hello"); } ---- Imagine that std.net.curl didn't have a `trace` function when the code was written. std.experimental.logger.trace would have been called then. When a `trace` function is then added to std.net.curl, the code suddenly calls a different `trace`, without any warning. Hijacking.
Jan 14
next sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
V Thu, 14 Jan 2016 16:17:41 +0100
anonymous via Digitalmars-d <digitalmars-d puremagic.com> napsáno:

 On 14.01.2016 15:25, Byron Heads wrote:
 I got burned by this yesterday, this code should not compile

 import std.experimental.logger : trace;


 void foo() {
      import std.net.curl : trace;
      trace("hello");
 }


 void main() {
      foo();
 }  
I don't see a problem with that specific code. You're explicitly importing `trace` from std.net.curl, so it can't be surprising that it's called. But change one little detail and this qualifies as hijacking, I think: ---- void foo() { import std.net.curl; /* not mentioning trace */ trace("hello"); } ---- Imagine that std.net.curl didn't have a `trace` function when the code was written. std.experimental.logger.trace would have been called then. When a `trace` function is then added to std.net.curl, the code suddenly calls a different `trace`, without any warning. Hijacking.
Using local imports is dangerous. It should be used only with selective imports
Jan 14
parent karabuta <karabutaworld gmail.com> writes:
On Thursday, 14 January 2016 at 15:54:02 UTC, Daniel Kozak wrote:
 V Thu, 14 Jan 2016 16:17:41 +0100
 anonymous via Digitalmars-d <digitalmars-d puremagic.com> 
 napsáno:

 On 14.01.2016 15:25, Byron Heads wrote:
 I got burned by this yesterday, this code should not compile
 void foo() {
      import std.net.curl; /* not mentioning trace */
      trace("hello");
 }
 ----
Using local imports is dangerous. It should be used only with selective imports
Some of these problems can be avoided when you write good code. Explicit import is allowed but not the best especially when you are just using one or two functions (locally or globally). Same as those who write: class Name { string name; this(string name) { name = name; } } Instead of; class Name { string name; this(string name) { this.name = name; } } Imagine you have; class Name { string realName; this(string name) { .... a lot of code here....... string realName = name ..... //This will punish you .... a lot of code here....... string finalName = realName ....... .... a lot of code here....... realName = finalName; // code maintained for a long time } } Writing good code takes time much like mining diamond.
Jan 16
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/14/2016 10:17 AM, anonymous wrote:
 On 14.01.2016 15:25, Byron Heads wrote:
 I got burned by this yesterday, this code should not compile

 import std.experimental.logger : trace;


 void foo() {
      import std.net.curl : trace;
      trace("hello");
 }


 void main() {
      foo();
 }
I don't see a problem with that specific code. You're explicitly importing `trace` from std.net.curl, so it can't be surprising that it's called. But change one little detail and this qualifies as hijacking, I think: ---- void foo() { import std.net.curl; /* not mentioning trace */ trace("hello"); } ---- Imagine that std.net.curl didn't have a `trace` function when the code was written. std.experimental.logger.trace would have been called then. When a `trace` function is then added to std.net.curl, the code suddenly calls a different `trace`, without any warning. Hijacking.
Yes, this needs to be fixed. -- Andrei
Jan 14
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jan 14, 2016 at 11:09:29AM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]
 Yes, this needs to be fixed. -- Andrei
This issue has been known for a long time: https://issues.dlang.org/show_bug.cgi?id=10378 Kenji even has a PR for it. My favorite blatant demonstration of its nastiness: import std.stdio; void func(string text) { import std.conv; writeln(text); } void main() { func("Hello world"); } Program output: (blank) T -- Жил-был король когда-то, при нём блоха жила.
Jan 14
parent reply Joakim <dlang joakim.fea.st> writes:
On Thursday, 14 January 2016 at 16:32:38 UTC, H. S. Teoh wrote:
 On Thu, Jan 14, 2016 at 11:09:29AM -0500, Andrei Alexandrescu 
 via Digitalmars-d wrote: [...]
 Yes, this needs to be fixed. -- Andrei
This issue has been known for a long time: https://issues.dlang.org/show_bug.cgi?id=10378 Kenji even has a PR for it. My favorite blatant demonstration of its nastiness: import std.stdio; void func(string text) { import std.conv; writeln(text); } void main() { func("Hello world"); } Program output: (blank) T
Wow, can't believe his PR has been sitting unreviewed for 5 months: https://github.com/D-Programming-Language/dmd/pull/4915
Jan 14
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/14/2016 02:10 PM, Joakim wrote:
 Wow, can't believe his PR has been sitting unreviewed for 5 months:

 https://github.com/D-Programming-Language/dmd/pull/4915
I notice Kenji has been absent for a while, could anyone take over that PR? -- Andrei
Jan 14
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jan 14, 2016 at 03:37:54PM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 01/14/2016 02:10 PM, Joakim wrote:
Wow, can't believe his PR has been sitting unreviewed for 5 months:

https://github.com/D-Programming-Language/dmd/pull/4915
I notice Kenji has been absent for a while, could anyone take over that PR? -- Andrei
It's almost an entire month since he suddenly went silent. Completely silent, in fact -- no activity whatsoever on his github account. Is he OK?? T -- Unix is my IDE. -- Justin Whear
Jan 14
parent rsw0x <anonymous anonymous.com> writes:
On Thursday, 14 January 2016 at 22:33:51 UTC, H. S. Teoh wrote:
 On Thu, Jan 14, 2016 at 03:37:54PM -0500, Andrei Alexandrescu 
 via Digitalmars-d wrote:
 On 01/14/2016 02:10 PM, Joakim wrote:
Wow, can't believe his PR has been sitting unreviewed for 5 
months:

https://github.com/D-Programming-Language/dmd/pull/4915
I notice Kenji has been absent for a while, could anyone take over that PR? -- Andrei
It's almost an entire month since he suddenly went silent. Completely silent, in fact -- no activity whatsoever on his github account. Is he OK?? T
Appears he's back, and he rebased the PR. https://github.com/D-Programming-Language/dmd/pull/4915
Jan 18
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Thursday, 14 January 2016 at 20:37:54 UTC, Andrei Alexandrescu 
wrote:
 On 01/14/2016 02:10 PM, Joakim wrote:
 Wow, can't believe his PR has been sitting unreviewed for 5 
 months:

 https://github.com/D-Programming-Language/dmd/pull/4915
I notice Kenji has been absent for a while, could anyone take over that PR? -- Andrei
We're live! Please review: https://github.com/D-Programming-Language/dmd/pull/5353
Jan 15
next sibling parent reply Meta <jared771 gmail.com> writes:
On Friday, 15 January 2016 at 23:57:51 UTC, Meta wrote:
 On Thursday, 14 January 2016 at 20:37:54 UTC, Andrei 
 Alexandrescu wrote:
 On 01/14/2016 02:10 PM, Joakim wrote:
 Wow, can't believe his PR has been sitting unreviewed for 5 
 months:

 https://github.com/D-Programming-Language/dmd/pull/4915
I notice Kenji has been absent for a while, could anyone take over that PR? -- Andrei
We're live! Please review: https://github.com/D-Programming-Language/dmd/pull/5353
And the build is failing on DAutoTest with nasty assert errors. It built fine for me locally, anyone know what might be the problem?
Jan 15
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Saturday, 16 January 2016 at 00:03:31 UTC, Meta wrote:
 And the build is failing on DAutoTest with nasty assert errors. 
 It built fine for me locally, anyone know what might be the 
 problem?
Error - file 'dimport.d' contains windows line endings at line 1 ... *** [checkwhitespace] Error 1
Jan 15
parent Meta <jared771 gmail.com> writes:
On Saturday, 16 January 2016 at 00:07:59 UTC, tsbockman wrote:
 On Saturday, 16 January 2016 at 00:03:31 UTC, Meta wrote:
 And the build is failing on DAutoTest with nasty assert 
 errors. It built fine for me locally, anyone know what might 
 be the problem?
Error - file 'dimport.d' contains windows line endings at line 1 ... *** [checkwhitespace] Error 1
I'm talking about this: https://travis-ci.org/D-Programming-Language/dmd/jobs/102725760#L342
Jan 15
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/15/2016 06:57 PM, Meta wrote:
 On Thursday, 14 January 2016 at 20:37:54 UTC, Andrei Alexandrescu wrote:
 On 01/14/2016 02:10 PM, Joakim wrote:
 Wow, can't believe his PR has been sitting unreviewed for 5 months:

 https://github.com/D-Programming-Language/dmd/pull/4915
I notice Kenji has been absent for a while, could anyone take over that PR? -- Andrei
We're live! Please review: https://github.com/D-Programming-Language/dmd/pull/5353
Thanks! "All checks have failed" -- Andrei
Jan 15
parent Meta <jared771 gmail.com> writes:
On Saturday, 16 January 2016 at 01:10:21 UTC, Andrei Alexandrescu 
wrote:
 We're live! Please review:
 https://github.com/D-Programming-Language/dmd/pull/5353
Thanks! "All checks have failed" -- Andrei
I hoped it would be as simple as rebasing, but either Kenji left that PR unfinished or there's something I'm missing, as it is not working as evidenced by the autotester. I'll close it in lieu of someone more knowledgeable about the compiler fixing it.
Jan 16