www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3301] New: Import statements are order dependent; should be order independent

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3301

           Summary: Import statements are order dependent; should be order
                    independent
           Product: D
           Version: 2.032
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Keywords: rejects-valid
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: sandford jhu.edu


In DMD 2.032, the order of import statements seems to be important.
Specifically, with regard to cyclic import statements. Below is a simple test
case using two files winapi.d and wincom.d

module winapi;
public import wincom;   // If the import is here, winapi does not compile
public import std.c.windows.windows;
//public import wincom; // If the import is here, winapi compiles
alias HRESULT THEMEAPI;

module wincom;
public import winapi; 
public import std.c.windows.com;
HRESULT hresult;

When compiling winapi, wincom errors are generated:
wincom.d(6): Error: identifier 'HRESULT' is not defined
wincom.d(6): Error: HRESULT is used as a type
wincom.d(6): Error: variable wincom.hresult voids have no value

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 04 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3301


simon <s.d.hammett googlemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |s.d.hammett googlemail.com



---
It's worth noting that when this happens you can still access the stuff in the
imported module by using the fully qualified name. The bug is effectively
causing the imports to be imported as static.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3301






 It's worth noting that when this happens you can still access the stuff in the
 imported module by using the fully qualified name. The bug is effectively
 causing the imports to be imported as static.


Although that's true of the test case, there were other examples in DFL where
the fully qualified name was being used and it was still not accessible. So in
practice, the FQN doesn't solve the whole problem, but this may be a different
bug. (It's just that those examples were a lot more complicated. I'm
specifically thinking of the use of classes from data.d in control.d)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3301


Stewart Gordon <smjg iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com
             Blocks|                            |340
            Summary|Import statements are order |Undefined identifier error
                   |dependent; should be order  |dependent on order of
                   |independent                 |imports when a circular
                   |                            |import is involved



It appears that this could be related to issue 258.

How it found a line 6 in wincom.d is another mystery.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3301




---
Possibly, but my code compiles fine in 2.028 & 2.031.
I've made no changes at all in my code and now it's foo barred w/ 2.032.

So (obv.) some difference in the 2.032 change set has exacerbated this bug.
Given how much stuff got done, that's probably not going to help much though.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3301




---


 Possibly, but my code compiles fine in 2.028 & 2.031.
 I've made no changes at all in my code and now it's foo barred w/ 2.032.
 
 So (obv.) some difference in the 2.032 change set has exacerbated this bug.
 Given how much stuff got done, that's probably not going to help much though.


Sry, ignore the bit about 2.031.
That's foo barred as well, but that might be phobos issues.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3301




I'm getting the same errors for the testcases here in 1.046, 1.047, 2.031 and
2.032 alike.  Though in all cases, the errors are reported at wincom.d(4).

----------
C:\Users\Stewart\Documents\Programming\D\Tests\bugs>dmd -c wincom.d

C:\Users\Stewart\Documents\Programming\D\Tests\bugs>dmd -c winapi.d
wincom.d(4): Error: identifier 'HRESULT' is not defined
wincom.d(4): Error: HRESULT is used as a type
wincom.d(4): Error: variable wincom.hresult voids have no value

C:\Users\Stewart\Documents\Programming\D\Tests\bugs>dmd -c wincom.d winapi.d

C:\Users\Stewart\Documents\Programming\D\Tests\bugs>dmd -c winapi.d wincom.d
wincom.d(4): Error: identifier 'HRESULT' is not defined
wincom.d(4): Error: HRESULT is used as a type
wincom.d(4): Error: variable wincom.hresult voids have no value

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3301


Brad Roberts <braddr puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P1
                 CC|                            |braddr puremagic.com



---
Bumping up to a P1 bug.  Walter, this needs to be at least commented upon asap.
 It's a rather nasty regression.

For the rest of you, a standalone repro case would likely help.  The one from
the original problem description requires importing std.c.windows.windows which
itself is rather huge.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 06 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3301




I'm not sure how trimming it down can be that difficult....

----- bz3301.d -----
public import bz3301a;
public import bz3301b;
----- bz3301a.d -----
public import bz3301; 
HRESULT hresult;
----- bz3301b.d -----
alias int HRESULT;
----------
C:\Users\Stewart\Documents\Programming\D\Tests\bugs>dmd -c bz3301.d
bz3301a.d(2): Error: identifier 'HRESULT' is not defined
bz3301a.d(2): Error: HRESULT is used as a type
bz3301a.d(2): Error: variable bz3301a.hresult voids have no value
----------
(1.047)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 06 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3301


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com



11:54:59 PDT ---
Thanks for doing a small test case.

This problem has actually always been there. I don't know why it didn't show up
earlier.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 11 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3301


Rainer Schuetze <r.sagitario gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.sagitario gmx.de



PDT ---


I have a patch for this (and the bugs mentioned above) that parses every file
that is unconditionally imported before any semantic analysis.

As this introduces another compile step, I'm not sure if this is a good patch,
and it will fail for conditional imports. So I'm hoping for a more general
solution that works with the deferred semantic analysis and solves more of the
forward reference problems.

Should I attach the patch anyway?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 11 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3301


Eldar Insafutdinov <e.insafutdinov gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |e.insafutdinov gmail.com



07:34:56 PDT ---
Yes indeed, this test case is reproducible on 1.041 as well, but 1.041 compiles
QtD and gtkD well. And 1.047 doesn't. Does it mean that it is a separate issue?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 12 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3301




PDT ---
Created an attachment (id=454)
do all imports before semantic analysis

Having done some investigation of the deferred semantic analysis mechanism, it
might be best to try to keep its usage to a minimum, because it might have a
negative impact on compilation speed and memory consumption. So my patch is
probably not so bad after all.

Some details: 
The problem is that, though the files are parsed, their symbol table might not
yet hold any identifiers, because the semantic analysis has not been run on the
module.

So I introduced another compile step after parsing, but before the semantic
analysis. The files on the command line are scanned for import statements,
loading and parsing the referenced modules and applying the same process on
these files. In the same step, the global members of the module are added to
the modules' symbol table (this has been moved from the semantic analysis).

The import statements must not be conditional, because the semantic analysis is
needed to evaluate a "static if" statement. If the semantic analysis gets to
the import statement, the additional compile step kicks in again for any module
not already loaded.



-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 18 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3301




13:37:03 PDT ---


 Created an attachment (id=454) [details]
 do all imports before semantic analysis
 
 Having done some investigation of the deferred semantic analysis mechanism, it
 might be best to try to keep its usage to a minimum, because it might have a
 negative impact on compilation speed and memory consumption. So my patch is
 probably not so bad after all.
 
 Some details: 
 The problem is that, though the files are parsed, their symbol table might not
 yet hold any identifiers, because the semantic analysis has not been run on the
 module.
 
 So I introduced another compile step after parsing, but before the semantic
 analysis. The files on the command line are scanned for import statements,
 loading and parsing the referenced modules and applying the same process on
 these files. In the same step, the global members of the module are added to
 the modules' symbol table (this has been moved from the semantic analysis).
 
 The import statements must not be conditional, because the semantic analysis is
 needed to evaluate a "static if" statement. If the semantic analysis gets to
 the import statement, the additional compile step kicks in again for any module
 not already loaded.
 



Dear Rainer,
Your patch applied against dmd 1.047 fixes the issue with building both gtkD
and QtD. It would be cool if it were included in the upstream.

Thank you.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 19 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3301


Tim M <tim.matthews7 gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tim.matthews7 gmail.com





 Dear Rainer,
 Your patch applied against dmd 1.047 fixes the issue with building both gtkD
 and QtD. It would be cool if it were included in the upstream.
 
 Thank you.


I had to use this to compile gtkD too and it worked well. The experimental dnet
compiler being based on dmd's front end also has this issue and the patch did
the job for that too.

Thanks Rainer.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 26 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3301


Rainer Schuetze <r.sagitario gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------

           obsolete|                            |



PDT ---
Created an attachment (id=469)
improved patch with version/debug support

I have improved the patch to look through version/debug conditionals, that
would bring back all the troubles if used for the imports.

I've also moved the setScope calls into the importAll functions, which was
already proposed in a comment nearby. At the same time, version/debug
conditional declarations pass the scope to its included branch.
StaticIfDeclarations cannot do this, because the semantic analysis is needed to
evaluate the condition.

In the long run, I'd propose to take the setScope mechanism further, setting
the scope as early as possible, allowing semantic analysis in arbitrary order.

I've run the qtd build with this patch and it still works. You'll also need the
patch of issue 3353 for the build to complete, though.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 03 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3301


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



13:47:26 PDT ---
Fixed dmd 1.049 and 2.034

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