Jump to page: 1 24  
Page
Thread overview
[Issue 10378] Prevent local imports from hiding local symbols
[Issue 10378] Local imports hide local symbols
Aug 29, 2014
dbr
Aug 29, 2014
dbr
Aug 29, 2014
dbr
Sep 23, 2014
deadalnix
Oct 08, 2014
deadalnix
Aug 19, 2015
timon.gehr@gmx.ch
Aug 20, 2015
Sobirari Muhomori
Aug 21, 2015
Kenji Hara
Aug 21, 2015
Kenji Hara
Jan 19, 2016
Ketmar Dark
Jan 19, 2016
timon.gehr@gmx.ch
Jan 19, 2016
Ketmar Dark
Feb 12, 2016
Walter Bright
Feb 14, 2016
Walter Bright
Feb 14, 2016
Walter Bright
Feb 17, 2016
Ketmar Dark
Feb 17, 2016
timon.gehr@gmx.ch
Feb 17, 2016
timon.gehr@gmx.ch
Feb 18, 2016
timon.gehr@gmx.ch
Jun 16, 2016
Sobirari Muhomori
Jul 03, 2017
Vladimir Panteleev
Jul 13
Dlang Bot
August 29, 2014
https://issues.dlang.org/show_bug.cgi?id=10378

dbr <dbugreporter@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dbugreporter@gmail.com

--- Comment #3 from dbr <dbugreporter@gmail.com> ---
The fact that local imports hide things instead of properly detecting conflicts is a dangerous bug. I actually almost trashed a bunch of files because of it since I had something like this:

import std.stdio;
void main() {
    import std.file;    // just wanted to use dirEntries!
    auto files = dirEntries("importantfiles", "*.{png}", SpanMode.depth);
    foreach (f; files) {
        auto hdr = read_header(f.name);
        writeln(f.name, ":");
        writefln("%d x %d", hdr.width, hdr.height);
    }
}

Luckily, I had that read_header call *after* the first writeln, and it of course threw and I only lost one file (and it wasn't actually important). I know (now!) that the docs say this about local (or "scoped") imports: "Imported symbols may hide symbols from outer scopes", but this is damn insane. It's inconsistent and surprising.

--
August 29, 2014
https://issues.dlang.org/show_bug.cgi?id=10378

--- Comment #4 from dbr <dbugreporter@gmail.com> ---
Sorry, that writeln(f.name, ":"); was actually writeln(f.name, ":"); as in, it
called std.file.write instead of std.stdio.write as I intended.

--
August 29, 2014
https://issues.dlang.org/show_bug.cgi?id=10378

--- Comment #5 from dbr <dbugreporter@gmail.com> ---
I meant write(f.name, ":"); I can't type shit today...

--
September 23, 2014
https://issues.dlang.org/show_bug.cgi?id=10378

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@erdani.com
           Severity|normal                      |critical

--- Comment #6 from Andrei Alexandrescu <andrei@erdani.com> ---
An example that doesn't compile today for the sake of illustration:

void main(string[] group)
{
    import std.algorithm, std.stdio;
    writeln(group);
}

This is a critical bug. I'm raising it accordingly.

One simple idea (that would nevertheless break existing code): only allow "static import xyz;" and "import xyz : sym1, sym2;" at local scope.

--
September 23, 2014
https://issues.dlang.org/show_bug.cgi?id=10378

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx

--- Comment #7 from hsteoh@quickfur.ath.cx ---
Most blatant illustration of this bug:
------
import std.stdio;
void func(string text) {
        import std.conv;
        writeln(text);
}
void main() {
        func("Hello world");
}
------

Program output:
------
------

:-)

--
September 23, 2014
https://issues.dlang.org/show_bug.cgi?id=10378

bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc

--- Comment #8 from bearophile_hugs@eml.cc ---
I have written some comments here: http://forum.dlang.org/post/wiahdvkvxjnasaijptvi@forum.dlang.org

--
September 23, 2014
https://issues.dlang.org/show_bug.cgi?id=10378

deadalnix <deadalnix@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |deadalnix@gmail.com

--- Comment #9 from deadalnix <deadalnix@gmail.com> ---
Proposal:

Free symbol are resolved from the inner scope to the outer scope WITHOUT considering imports. If that lookup fails, the symbol is searched in import from the inner scope to the outer scope.

A variant is to aggregate import into the inner scope.

This solution has various advantages:
 - import cannot hijack in module symbols implicitly.
 - import do not need to be processed if local lookup succeed, and doing less
work is always a way to make the compiler faster.

The main difference between the first proposal and the variant is that that in the first proposal, an inner imported module's symbol can hijack an outer imported one. In the variant, it doesn't happen, but the import lookup phase will be much heavier, as the compiler must look into all imported module at once.

--
October 07, 2014
https://issues.dlang.org/show_bug.cgi?id=10378

--- Comment #10 from hsteoh@quickfur.ath.cx ---
@deadalnix: Unfortunately this would require some rather big changes in dmdfe... currently, imports are implemented by actually inserting symbols from the imported module into the symbol table of the current scope. So either we would have to hack the symbol table to mark imported symbols as being imported, and modify symbol lookup to ignore such symbols the first time round; or, we'd have to introduce an additional symbol table per lexical scope for holding imported symbols, alongside the "normal" symbol table.

--
October 08, 2014
https://issues.dlang.org/show_bug.cgi?id=10378

--- Comment #11 from deadalnix <deadalnix@gmail.com> ---
(In reply to hsteoh from comment #10)
> @deadalnix: Unfortunately this would require some rather big changes in dmdfe... currently, imports are implemented by actually inserting symbols from the imported module into the symbol table of the current scope. So either we would have to hack the symbol table to mark imported symbols as being imported, and modify symbol lookup to ignore such symbols the first time round; or, we'd have to introduce an additional symbol table per lexical scope for holding imported symbols, alongside the "normal" symbol table.

We have to sell it to Walter as a way to make D compile faster (as it allow for
more lazy imports).

--
August 19, 2015
https://issues.dlang.org/show_bug.cgi?id=10378

timon.gehr@gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timon.gehr@gmx.ch

--- Comment #12 from timon.gehr@gmx.ch ---
(In reply to deadalnix from comment #9)
> Proposal:
> 
> Free symbol are resolved from the inner scope to the outer scope WITHOUT considering imports. If that lookup fails, the symbol is searched in import from the inner scope to the outer scope.
> 
> A variant is to aggregate import into the inner scope.
> 
> This solution has various advantages:
>  - import cannot hijack in module symbols implicitly.
>  - import do not need to be processed if local lookup succeed, and doing
> less work is always a way to make the compiler faster.
> 
> The main difference between the first proposal and the variant is that that in the first proposal, an inner imported module's symbol can hijack an outer imported one. In the variant, it doesn't happen, but the import lookup phase will be much heavier, as the compiler must look into all imported module at once.

Another solution would be to not have an a priori precedence order for symbols that are imported and symbols that are found in an enclosing scope, and to then do the usual overload resolution. (Think of this like treating enclosing scopes as imports.) This is more in line with the anti-hijacking design philosophy of the module system.

--
« First   ‹ Prev
1 2 3 4