A hypothetical question

[Ary Borenszweig]

Hello Ellery :)

Ellery Newcomer escribió:
> Say you have an IDE for D (such as Descent), featuring autocompletion,
> error highlighting, and any number of other features which require solid
> semantic analysis. In the course of performing said analysis (strictly
> the non-interactive part), how much sense does it make to attempt to
> analyze all conditional blocks?

I think it makes a lot of sense because often when you make a change to 
one version you want to make the other version kept in-sync, so any 
quick errors you get because of out of sync changes is good.

It also makes sense when renaming a symbol: you want (do you?) all 
possible versions of a symbol to also be renamed.

> 
> On the one hand, you have the compiler, which throws conditional blocks
> away with little ado. These blocks may be designed to work under
> specific version sets which may not be readily gleanable from source.
> They may contain complete garbage (e.g. syntax or semantics not valid

Syntax must be valid in D. I checked this in C# and it's not a 
requirement. So in this case D is better.

> for this version of D, but maybe valid for another version). This could
> swamp the user with error messages which aren't really valid.
> 
> On the other hand, this is an IDE. Any moderately ambitious project is
> going to have different versions for different platforms, different
> modes of operation, etc. If you have errors in specific versions, you
> want to know about them up front. And you don't want autocompletion to
> suddenly stop working in part or in full inside odd version statements.

In Descent autocompletion doesn't work in inactive code (code not 
reached by the current debug/version conditions). It also appears as grey.

> Another point is efficiency. If you have symbols that can resolve to
> different types depending on version, it could potentially make semantic
> analysis much slower when checking expressions that use those symbols.

I think this isn't a big deal. At least in Descent full semantic 
analysis is run for the current module: the other modules are partially 
looked as needed.

> 
> The possibilities I see are:
> * have the user input a single version set to use when performing
> analysis (ape the compiler), and change it whenever he/she/it wants to
> work on different versions (bleach!)
> * have the user input specific version sets, all of which must be
> checked when performing analysis
> * run analysis over all version sets
> * let the user choose which of these to use

Descent has the bleach option. :-P

> Thoughts?
> 
> (And I have no idea what Descent does in this regard. Ary?)

It's made that way because it's the easiest of the options. Also Visual 
Studio works exactly like that. I just tried renaming a symbol which has 
another definition in some other inactive code, and the inactive symbol 
wasn't renamed. So I thought "If Visual Studio works like that and I 
never saw anyone complaining, it must be a good choice". But... I think 
D is very different than C# because conditional declarations are not the 
common case in C# (at least in all the code I've written in C# I never 
used them).

So it would be nice to check also version branches. The problem is that 
if you have a file like this:

version(Foo) {
   // Something
}

version(Bar) {
   // Something else
}

You'll have to make semantic analyis for these cases:
  - !Foo && !Bar
  - !Foo && Bar
  - Foo && !Bar
  - Foo && Bar

because each one of those combination is a valid version combination. 
Also you have to combine that with debug levels (that combination can be 
reduced by checking if there are debug versions in the affected 
modules). You might get errors with some combinations because those were 
not intended to be used together (for example Windows, Unix, etc.)
  I think we arrived to this conclusion with Robert Fraser. :)

On the other hand maybe semantic analysis can be performed with any of 
those versions. You thihk that can work? Because that'll solve a big 
problem in Descent that's: if your current version is Windows, all the 
posix/unix modules in Phobos/Tango give you an error because many things 
are not defined. The other problem is:

version(Unix) {
} else {
   static assert("This module should only be compiled with Unix version");
}

You'll get that error in each module that looks like that if Unix 
version is not set.

So... should I try checking each version? I wouldn't know which errors 
to show (the union? that'll trigger the static assert above; the current 
version? that brings us to the beginning of this discussion).

Also... Descent is still not good at showing exactly the same errors as 
DMD would give you, and probably will never be like that (partially 
because some errors are in the back-end and when most of the code was 
ported we didn't have access to it, partially because it's hard to make 
it work like DMD when you need to reduce the amount of semantic analysis 
needed to make the IDE work fast). So the only benefit I would see is 
getting autocompletion/go-to-definition in inactive code.

Finally, no one complained about this, but probably because not many 
people use Descent. ;-)