Rename refactoring on a private field takes too long; analyzes full solution

We received an excellent bug from Michael Teper
commenting that rename was taking too long in a scenario that should
have been faster.  Not only does he mention his dissatisfaction
but he also took the time to suggest a way that we could be much faster
in a very specific renaming scenario.  Specifically, if you were
renaming a private field then it shouldn't be necessary to compile the
full solution.  First off, i want to thank Michael for submitting
this feedback to us.  It's extraordinarily helpful to know if our
features are or are not meeting your needs.  When we don't hear
anything from users we will often have to guess or hope that it's
working out well.  (and, sometimes you want something to be
working so well that users never even notice it).  However, when
we do hear back from a user we know that this is something we have to
look at.  Now, i wanted to dive deep into the optimization
suggestion that was made.

Specifically, Michael says "This class lives in a library project that
depends on one other library project. Current implementation aside, I
can't see any reason why you would need/want to compile the entire
solution just to analyze usage for a *private* field."

This is a very reasonable complaint.  It certainly appears that if you had the following code:

 internal sealed class TextBoxDefinition : FieldDefinitionBase {
    private int _maxLength;

    public int MaxLength {
        get { return _maxLength; }
        set { _maxLength = value; }
    }
}

and you renamed "_maxLength" to something else (say "_maxSize"), then
we could put in a quick optimization and and only try to compile the
current type.  The reasoning behind this is that as the field is
private, nothing else could possibly reference it and so it suffices to
look in the current type only when doing the compile.  However, as
it turns out this is not the case.  And it is necessary when
renaming a member (even a private one) to do a full project
analysis.  Why?  Well consider the following trivial example:

 public class Foo {
    private int member;

    void Method() {
        Bar.CreateFoo().member = 4;
    }
}

public class Bar {
    public static Foo CreateFoo() {
        return new Foo();
    }
}

As you can see, "member" is referenced in one place:

 Bar.CreateFoo().member = 4;

This is an example of referencing a private member of the current type
through an expression that binds to an instance of the current
type.  However, in order to know that "Bar.CreateFoo()" binds to
an instance of "Foo" we must compile "Bar".  Since arbitrary
expressions can end up returning an instance of the current type we
basically need to compile everything to ensure that accurately rename
everything.

Now, one area that we can we can speed this up in is when you rename a
local variable.  Because the local variable cannot be referenced
by anything outside the current member, and because you can only refer
to it with it's name and not through an arbitrary expression, it's
possible to rename a local quite quickly.

When we started work on refactorings we read a lot of the literature on
it, and we talked to many customers to see what they wanted out of
it. 
And the message we got back was that if they could not absolutely trust
refactorings then they would not use them.  Refactorings are
supposed
to keep the semantics of your code the same and if that invariant is
not held, then refactorings like renames are no better than just a
find/replace.   And, like with most development, and
especially something like refactorings, it
was our top priority to get the feature working to specification first,
and
then make it work performantly next.   So, for whidbey, we
will continue to rebuild a fair bit when you rename a class
member (private or otherwise).  However, it's still possible for
us to find other ways to make this faster through other means, and we'd
like to make these kinds of user actions much faster for our RTM
release. 

Michael: Once again, thank you very much for your feedback.  We'll
definitely be keeping that bug open so that we can track the issue of
performance with this feature.  I hope that when we finally ship
you'll be much happier with the product!