More smart code work inside disabled preprocessor blocks

[sfjohansson]

       string aString="Consulo is Awesome";

        string anohterString=aString[0]; //This get highlighted

        #if CheeseCake
        anohterString=aString[0];  //this does not get highlighted
        #endif

[VISTALL]

Because CheeseCake is not defined

[sfjohansson]

Yes that is correct, but even if the code is inactive now and one makes a typo, it will be active at some point.

[VISTALL]

for example - in preprocessor code i will write } - that will break original code. Trying resolve inside disabled block for not out of poll(for example preprocessor can handle using and you can resolve to different methods.

[sfjohansson]

I guess compilation errors themselves are harder/impossible as preprocessor directives can dramatically change the code path and therefore only the defined ones can be evaluated properly, as evaluating undefined ones could result in an incompatible combination of code blocks.

I was expecting that syntax errors (I guess these are done by the linter) would be picked up equally within or outside preprocessor directive blocks, but then again...I'm not the most experienced programmer and maybe thats not normally expected behaviour and this is a feature (aka a bug in disguise)

http://2.bp.blogspot.com/_80jBkqKSe50/SlOgZjkKwGI/AAAAAAAAAEs/LSvgaSoG7Gg/s400/bug-feature.jpg

But yes it would certainly be helpful as one would not have to define the directives before writing any code to them, as in my case I was wrapping some simple debug code with preprocessor directives.

[VISTALL]

public class A {

 public void 
#if A
    test() 
#else
   maybe()
#endif

    { 
      // some code
    }

 public void tryCall() {

     test(); // error - if no A, or not ? 
 }
}

[sfjohansson]

Yes that shouldn't be working as it is an example of an incompatible combination of code blocks, "test()" would not exist for the compiler unless a preprocessor directive "A" is defined...at least according my interpretation.

I would expect a syntax error like assigning a string to an int for instance to be picked up:

    #if Cheese
    int anInt="A";
    anIntFromSomewhereElse="Cheese";
    #endif

But yes, I have no idea if this i normally possible in an IDE.

[VISTALL]

And you can create local variables with same name - but different type (i saw some code with that). Idk how to handle it

[sfjohansson]

hmm it might be a hell lot of work and other people might be better to advise than me if this is valid feature.

but I guess...that as long a variable is defined within an active code block..maybe the compiler/linter can be used to highlight and error against it even if wrapped with a preprocessor directive.

If the definition is with another preprocessor block where a variable is of a completely different type like you have seen...then the syntax check would have to be done against the code within those blocks...this might be even trickier.

[barzto]

I guess it may be resolved by introducing multiple (see [1] bellow) CSharpFile instances (hoping this is the right class) for one physical .cs file.

There should be one of those CSharpFile instance marked as main with preproc symbol set according to project settings, and others should be temporary enabled when entering appropriate preproc. section and considered when doing the using optimization.

[1] The number of file variants is exactly 2^n where n is number of symbols that appears in a .cs file. This is because C# preprocessor recognizes only logical expressions (and, or, not) but not arithmetic or comparison exprs. (I.e. UNITY_IOS || !UNITY_EDITOR is valid but UNITY_VERSION >= 5000 is not valid). I know the number of variants to consider grows dramatically (for distinct 10 referenced preproc symbols it will need 1024 CSharpFile objects), but it is the only way to deal with this imho.

[barzto]

Actually the 2^n is the worse case scenario that may happen only in artificial cases, the number of really needed CSharpFile instances should be way smaller as there will likely be used only small subset of all possible combinations.