Inclusion of using is put inside unrelated preprocessor directive

[jnyrup]

Version Used: VS 20017 Version 15.1 26403.7

Steps to Reproduce:

1. Start with this program

#if DEBUG
using System.IO;
#endif

namespace ConsoleApplication2
{
    class Foo
    {
        public void Bar()
        {
            Console.WriteLine();
        }
    }
}

2. Ctrl+. on Console.WriteLine();
3. Select "Using System"
4. Observe how using System; is put inside #if DEBUG, result:

#if DEBUG
using System;
using System.IO;
#endif

namespace ConsoleApplication2
{
    class Foo
    {
        public void Bar()
        {
            Console.WriteLine();
        }
    }
}

Expected Behavior: using System; is put outside preprocessor directive.

Actual Behavior: using System; is put inside preprocessor directive making it incompilable in Release Mode.

[sharwell]

💭 I would expect the feature to place the new directive inside a logically-equivalent guard. For example, if you were to start with the following code I would expect the result to behave as you observed:

#if DEBUG
using System.IO;
#endif

namespace ConsoleApplication2
{
    class Foo
    {
        public void Bar()
        {
#if DEBUG
            Console.WriteLine(); // Ctrl+. on this line
#endif
        }
    }
}

Conceptually this isn't unreasonable, but there are a few cases that make it challenging:

1. Nested directives
2. Boolean equivalence (e.g. #if !!DEBUG is equivalent to #if DEBUG, but has a different form)

[CyrusNajmabadi]

PRs welcome.

[CyrusNajmabadi]

I would expect the feature to place the new directive inside a logically-equivalent guard.

Currently we have no APIs to answer that question. From the perspective of everything consuming the SyntaxTree code there is only the code that active and the code that is disabled. We could certainly try to support this, but it would need a fair amount of plumbing/infrastructure to support. Given that we haven't heard about this issue in 15+ years, it would not be a high pri for me :)

[jnyrup]

I would expect the feature to place the new directive inside a logically-equivalent guard.

Unfortunately there might not be a single guard that covers it.

#if FOO
using System.IO;
#elif BAR
using System.IO;
#endif

namespace ConsoleApplication2
{
    class Preprocessor2
    {
        public void Foo()
        {
#if FOO || BAR
            Console.WriteLine();
#endif
        }
    }
}

Given that we haven't heard about this issue in 15+ years...

I've had the issue two or three times recently in a class where I've used preprocessor directives to switch between alias.

#if DEBUG
    using Dev___DataMember = System.Runtime.Serialization.DataMemberAttribute;
#else
    using Dev___DataMember = System.Runtime.Serialization.IgnoreDataMemberAttribute;
#endif

There are properly cleaner ways to archive this, but it was a minor annoyance when my VS is in debug mode but the TFS server compiles in release mode and fails to build.

[sharwell]

Unfortunately there might not be a single guard that covers it.

True, but one could be added. Again in theory. 😄

[CyrusNajmabadi]

Would take a small community fix here.

[CyrusNajmabadi]

Not planning on doing this.