[Issue 15567] local import hijacking

[via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||hst...@quickfur.ath.cx
 Resolution|--- |DUPLICATE

--- Comment #2 from hst...@quickfur.ath.cx ---


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

--

Re: local import hijacking

[deadalnix via Digitalmars-d]

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-annou...@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.

Re: local import hijacking

[Martin Nowak via Digitalmars-d]

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-annou...@puremagic.com) and cause such troubles during development.

I think it's time to dedicate a whole release to work on imports.

Re: local import hijacking

[Jack Stouffer via Digitalmars-d]

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.

Re: local import hijacking

[rsw0x via Digitalmars-d]

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?

Re: local import hijacking

[rsw0x via Digitalmars-d]

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

Re: local import hijacking

[Jack Stouffer via Digitalmars-d]

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.

Re: local import hijacking

[Joakim via Digitalmars-d]

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.

Re: local import hijacking

[Timon Gehr via Digitalmars-d]

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

Re: local import hijacking

[Meta via Digitalmars-d]

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.

Re: local import hijacking

[karabuta via Digitalmars-d]

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  
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.

Re: local import hijacking

[Iain Buclaw via Digitalmars-d]

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.  :-)

Re: local import hijacking

[tsbockman via Digitalmars-d]

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.

Re: local import hijacking

[tsbockman via Digitalmars-d]

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.

Re: local import hijacking

[tsbockman via Digitalmars-d]

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

Re: local import hijacking

[Meta via Digitalmars-d]

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?

Re: local import hijacking

[Andrei Alexandrescu via Digitalmars-d]

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

Re: local import hijacking

[John Colvin via Digitalmars-d]

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.

Re: local import hijacking

[Meta via Digitalmars-d]

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

Re: local import hijacking

[Meta via Digitalmars-d]

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

Re: local import hijacking

[Johannes Pfau via Digitalmars-d]

Am Thu, 14 Jan 2016 21:36:01 +
schrieb tsbockman :

> 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

Re: local import hijacking

[Iain Buclaw via Digitalmars-d]

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.

Re: local import hijacking

[Russel Winder via Digitalmars-d]

On Thu, 2016-01-14 at 21:36 +, tsbockman via Digitalmars-d wrote:
> 
[…]
> 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.

"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…

> It is recommended to do your testing with DMD because of issues 
> like this, and mostly use GDC for making optimized release builds.

…given this. 

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, 
> 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...

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.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: local import hijacking

[anonymous via Digitalmars-d]

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.

Re: local import hijacking

[Andrei Alexandrescu via Digitalmars-d]

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

Re: local import hijacking

[Andrei Alexandrescu via Digitalmars-d]

On 01/14/2016 09:36 AM, Daniel Kozak via Digitalmars-d wrote:

V Thu, 14 Jan 2016 14:25:43 +
Byron Heads via Digitalmars-d  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

[Issue 15567] New: local import hijacking

[via Digitalmars-d-bugs]

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

  Issue ID: 15567
   Summary: local import hijacking
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: major
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bhe...@moxiegroup.com

Got burned by this:

import std.experimental.logger : trace;

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

void main() {
foo();
}

This should not compile and give an error on the use of the ambiguous call to
trace.

confirmed on DMD 2.069.2  on windows

--

local import hijacking

[Byron Heads via Digitalmars-d]

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

Re: local import hijacking

[Daniel Kozak via Digitalmars-d]

V Thu, 14 Jan 2016 14:25:43 +
Byron Heads via Digitalmars-d  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

[Issue 15567] local import hijacking

[via Digitalmars-d-bugs]

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

--- Comment #1 from Byron Heads  ---
The implicit locals should not hijack globals

import std.experimental.logger;

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

void main() {
foo();
}

--

Re: local import hijacking

[Daniel Kozak via Digitalmars-d]

V Thu, 14 Jan 2016 16:17:41 +0100
anonymous via Digitalmars-d  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

Re: local import hijacking

[H. S. Teoh via Digitalmars-d]

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

Re: local import hijacking

[tsbockman via Digitalmars-d]

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...

Re: local import hijacking

[Andrei Alexandrescu via Digitalmars-d]

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

Re: local import hijacking

[Joakim via Digitalmars-d]

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

Re: local import hijacking

[Byron Heads via Digitalmars-d]

On Thursday, 14 January 2016 at 14:36:23 UTC, Daniel Kozak wrote:

V Thu, 14 Jan 2016 14:25:43 +
Byron Heads via Digitalmars-d  
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...

Re: local import hijacking

[Byron Heads via Digitalmars-d]

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!

Re: local import hijacking

[H. S. Teoh via Digitalmars-d]

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

-- 
Жил-был король когда-то, при нём блоха жила.

[Issue 12598] New: Poor diagnostic with local import hijacking

[via Digitalmars-d-bugs]

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

  Issue ID: 12598
   Summary: Poor diagnostic with local import hijacking
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: DMD
  Assignee: nob...@puremagic.com
  Reporter: thecybersha...@gmail.com

Consider the following program:

 test.d 
class C
{
void addLine(string l)
{
debug
{
import std.stdio;
stderr.writeln(Adding line:  ~ l);
}
lines ~= l;
}

immutable(string)[] lines;
}


When compiled with -debug, the compiler produces the following error message:

test.d(10,3): Error: lines is not an lvalue

This error message is misleading - it's not clear that a symbol from std.stdio
is hijacking the lines field.

One way to improve the situation is to print fully-qualified symbol names in
error messages.

Another would be to add a warning or error when a locally-imported symbol is
hijacking a non-global symbol. The user can silence this message by using a
selective, static or named import.

--

[Issue 12598] Poor diagnostic with local import hijacking

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

URL||https://github.com/D-Progra
   ||mming-Language/dmd/pull/347
   ||0
 CC||andrej.mitrov...@gmail.com
   Assignee|nob...@puremagic.com|andrej.mitrov...@gmail.com

--

[Issue 12598] Poor diagnostic with local import hijacking

[via Digitalmars-d-bugs]

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

--- Comment #1 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/776cc73b4afc04e22bbc06f3e3b370cd5c90c5a5
Fix Issue 12598 - Emit better diagnostics when type is found where an lvalue
was expected.

https://github.com/D-Programming-Language/dmd/commit/c643ec572f8c528225c6a6af1594b08b04488657
Merge pull request #3470 from AndrejMitrovic/Fix12598

Issue 12598 - Emit better diagnostics when type is found where an lvalue was
expected

--