• Ary Borenszweig <ary esperanto.org.ar> Jul 02 2008
• Jacob Carlborg <doobnet gmail.com> Jul 03 2008
• Bruno Medeiros <brunodomedeiros+spam com.gmail> Jul 05 2008
• Ary Borenszweig <ary esperanto.org.ar> Jul 05 2008
• Jason House <jason.james.house gmail.com> Jul 05 2008

Ary Borenszweig <ary esperanto.org.ar> writes:

I'm trying to optimize the semantic analysis pass in Descent. The idea 
is to not load things up if they are not needed. For example:

---
module one;

import two;

void someMethod(Foo foo) {
   foo.x = 1;
}
---
module two;

import three;

class Foo {
   int x;
   Bar bar;
}
---
module three;

class Bar { }
---

Now, if I want to help the user by giving autocompletion, go to 
definition, etc., in module *one*, you can see that property "bar" is 
not even mentioned there, so module "three" would not be loaded, not 
even looked up.

I've managed to do this (DMD's compiler doesn't care about this because 
it needs to create an object file for the whole thing). The problem is 
that this optimization gives a semantic error when you use a fully 
qualified name for something that is privately imported in an imported 
module (a very known bug, I think). Although reporting this as error is 
good, because it is "how it should be", there are a lot of existing 
modules that depend on this functionality, so seeing an error there may 
be annoying.

I can't "fix" it because if I do it, I loose the optimization (module 
"three" would have to be loaded in this example, at least to preserve 
DMD's semantic). So I think I'll leave it like that (with the 
optimization on), but I wanted to know what did the community think 
about this.

I also wonder if it helps if I report these erorrs now marked by Descent 
into bugzilla...

Jacob Carlborg <doobnet gmail.com> writes:

Ary Borenszweig wrote:
 I'm trying to optimize the semantic analysis pass in Descent. The idea 
 is to not load things up if they are not needed. For example:
 
 ---
 module one;
 
 import two;
 
 void someMethod(Foo foo) {
   foo.x = 1;
 }
 ---
 module two;
 
 import three;
 
 class Foo {
   int x;
   Bar bar;
 }
 ---
 module three;
 
 class Bar { }
 ---
 
 Now, if I want to help the user by giving autocompletion, go to 
 definition, etc., in module *one*, you can see that property "bar" is 
 not even mentioned there, so module "three" would not be loaded, not 
 even looked up.
 
 I've managed to do this (DMD's compiler doesn't care about this because 
 it needs to create an object file for the whole thing). The problem is 
 that this optimization gives a semantic error when you use a fully 
 qualified name for something that is privately imported in an imported 
 module (a very known bug, I think). Although reporting this as error is 
 good, because it is "how it should be", there are a lot of existing 
 modules that depend on this functionality, so seeing an error there may 
 be annoying.
 
 I can't "fix" it because if I do it, I loose the optimization (module 
 "three" would have to be loaded in this example, at least to preserve 
 DMD's semantic). So I think I'll leave it like that (with the 
 optimization on), but I wanted to know what did the community think 
 about this.
 
 I also wonder if it helps if I report these erorrs now marked by Descent 
 into bugzilla...


Perhaps if possible you could show these errors in some other way than 
the usual way, some other color or something like that. Perhaps it could 
be an option you could turn off if possible.

Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:

Ary Borenszweig wrote:
 I'm trying to optimize the semantic analysis pass in Descent. The idea 
 is to not load things up if they are not needed. For example:
 
 ---
 module one;
 
 import two;
 
 void someMethod(Foo foo) {
   foo.x = 1;
 }
 ---
 module two;
 
 import three;
 
 class Foo {
   int x;
   Bar bar;
 }
 ---
 module three;
 
 class Bar { }
 ---
 
 Now, if I want to help the user by giving autocompletion, go to 
 definition, etc., in module *one*, you can see that property "bar" is 
 not even mentioned there, so module "three" would not be loaded, not 
 even looked up.
 
 I've managed to do this (DMD's compiler doesn't care about this because 
 it needs to create an object file for the whole thing). The problem is 
 that this optimization gives a semantic error when you use a fully 
 qualified name for something that is privately imported in an imported 
 module (a very known bug, I think). Although reporting this as error is 
 good, because it is "how it should be", there are a lot of existing 
 modules that depend on this functionality, so seeing an error there may 
 be annoying.
 
 I can't "fix" it because if I do it, I loose the optimization (module 
 "three" would have to be loaded in this example, at least to preserve 
 DMD's semantic). So I think I'll leave it like that (with the 
 optimization on), but I wanted to know what did the community think 
 about this.
 
 I also wonder if it helps if I report these erorrs now marked by Descent 
 into bugzilla...


You're talking about bug #313, right? 
(http://d.puremagic.com/issues/show_bug.cgi?id=313)
I think it's clearly a bug, there are even testcases for it, so the IDE 
should threat it as a bug, and any such illegal uses should be marked as 
errors in the IDE.

You said "there are a lot of existing modules that depend on this 
functionality". Such as? I would find that odd, modules depending on 
that bug.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Ary Borenszweig <ary esperanto.org.ar> writes:

Bruno Medeiros a écrit :
 Ary Borenszweig wrote:
 I've managed to do this (DMD's compiler doesn't care about this 
 because it needs to create an object file for the whole thing). The 
 problem is that this optimization gives a semantic error when you use 
 a fully qualified name for something that is privately imported in an 
 imported module (a very known bug, I think). Although reporting this 
 as error is good, because it is "how it should be", there are a lot of 
 existing modules that depend on this functionality, so seeing an error 
 there may be annoying.


 You're talking about bug #313, right? 
 (http://d.puremagic.com/issues/show_bug.cgi?id=313)
 I think it's clearly a bug, there are even testcases for it, so the IDE 
 should threat it as a bug, and any such illegal uses should be marked as 
 errors in the IDE.
 
 You said "there are a lot of existing modules that depend on this 
 functionality". Such as? I would find that odd, modules depending on 
 that bug.
 


Like... a lot of modules in phobos. But I think I got rid of that 
problem when I tweaked a little the way I optimized things (so the bug 
is back :-P).

Jason House <jason.james.house gmail.com> writes:

Ary Borenszweig wrote:

 Bruno Medeiros a écrit :
 Ary Borenszweig wrote:
 I've managed to do this (DMD's compiler doesn't care about this
 because it needs to create an object file for the whole thing). The
 problem is that this optimization gives a semantic error when you use
 a fully qualified name for something that is privately imported in an
 imported module (a very known bug, I think). Although reporting this
 as error is good, because it is "how it should be", there are a lot of
 existing modules that depend on this functionality, so seeing an error
 there may be annoying.


 You're talking about bug #313, right?
 (http://d.puremagic.com/issues/show_bug.cgi?id=313)
 I think it's clearly a bug, there are even testcases for it, so the IDE
 should threat it as a bug, and any such illegal uses should be marked as
 errors in the IDE.
 
 You said "there are a lot of existing modules that depend on this
 functionality". Such as? I would find that odd, modules depending on
 that bug.
 


 Like... a lot of modules in phobos. But I think I got rid of that
 problem when I tweaked a little the way I optimized things (so the bug
 is back :-P).


Please mark it as a coding error/bug if I do something like that while
coding in Descent :)