Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
User name:
Password:
Save Password
Forgot your password?

 All Forums
 Visual Assist
 Technical Support
 CRITICAL ERROR: VA Rename corrupts source code
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

gbozoki
Ketchup Master

USA
70 Posts

Posted - Feb 06 2013 :  4:40:34 PM  Show Profile  Reply with Quote
I just ran into a case where VA Refactor->Rename corrupts unrelated source code during the rename operation in VS 2008. This is at least the 4th occasion in the past ~1 year when Rename corrupted source code. There were more when I noticed the problem early and cancelled the Rename dialog before it could cause damage.

This is a mixed solution of ~15 projects: C# and C++ projects. Total number of files is ~1700. I have a C# class, something like:

namespace Some.Name.Space
{
    internal class Parser
    {
        #region ParserState
        private sealed class ParserState
        {
            #region Private members
            ...
            private int m_nPos = -1;
            ...
            #endregion

            #region Public members
            public int Pos
            {
                get { return ( m_nPos ); }
                set { m_nPos = value; }
            }

            ...
            #endregion
        }
        #endregion

        #region Public members
        public ParseResult Parse ( string sInput )
        {
            ParserState oState = new ParserState ( sInput );

            ...
            oState.Pos++;
            ...
        }
        #endregion
    }
}


When I tried to rename the Pos symbol to Position, it did so but when I tried compiling the project, I got errors in another (C++) project in the solution that I didn't touch. I was able to revert the changes to the C++ source because it's a 3rd party project (zLib) and it's not being worked on. I had to manually revert the changes in the C# source code to avoid losing a day's work (and to be able to try to reproduce this).

This is the result list when I try to use Refactor->Rename on the Pos symbol:



Another case that I found (I only used Find References with this):

using System;
using System.Collections.Generic;
using System.Text;

namespace Some.Name.Space
{
    /// <summary>
    /// 
    /// </summary>
    internal class XRange
    {
        #region Private members
        private int m_nPosition;
        private int m_nLength;
        #endregion

        #region Constructor
        /// <summary>
        /// Constructor
        /// </summary>
        public XRange () :
            this ( -1, -1 )
        {
        }

        /// <summary>
        /// Constructor
        /// </summary>
        /// <param name="nPosition"></param>
        /// <param name="nLength"></param>
        public XRange ( int nPosition, int nLength )
        {
            m_nPosition = nPosition;
            m_nLength = nLength;
        }
        #endregion

        #region Public members
        /// <summary>
        /// 
        /// </summary>
        public int Position
        {
            get
            {
                return ( m_nPosition );
            }
            set
            {
                m_nPosition = value;
            }
        }

        /// <summary>
        /// 
        /// </summary>
        public int Length
        {
            get
            {
                return ( m_nLength );
            }
            set
            {
                m_nLength = value;
            }
        }
        #endregion
    }
}


Edit:

When I run Find References for the public Length property, the result list shows 22 matches - only 3 are correct, all others are wrong. Out of the 22 matches, 16 are checked. Matches come from unrelated C++ source / header files in other projects (in the same solution) and from unrelated C# classes in the same project.

I looked through some of the incorrect matches in C++ source - there's a macro defined like:

#define InitializeObjectAttributes(pOA,pName,lAttr,hRoot,pSD) \{ \    ( pOA )->Length = sizeof ( OBJECT_ATTRIBUTES ); \    ( pOA )->RootDirectory = hRoot; \    ( pOA )->Attributes = lAttr; \    ( pOA )->ObjectName = pName; \    ( pOA )->SecurityDescriptor = pSD; \    ( pOA )->SecurityQualityOfService = NULL; \}


This macro triggered several matches in .h and .cpp files. It seems like that almost anything that looks like ...->Length ... triggers a match from C++ code. No files outside the solution have been listed in results.

Although a bunch of unrelated C# files / classes are listed, no unrelated symbol is actually checked in C# code. The incorrect C# matches are strange because things like:

FileInfo oFI = ...;
long lLen = oFI.Length;


triggered '?' (unchecked) matches. The type of oFI is not related to XRange, they just happen to have similarly named properties.

Related problems:
http://forums.wholetomato.com/forum/topic.asp?TOPIC_ID=11026
http://forums.wholetomato.com/forum/topic.asp?TOPIC_ID=10527

--------------------
System info:

VA_X.dll file version 10.7.1925.0 built 2012.12.14
Licensed to:
VA X: ... (1-user license) Support ends 2013.06.18
DevEnv.exe version 9.0.30729.1 Enterprise
msenv.dll version 9.0.30729.1
Font: Courier New 13(Pixels)
Comctl32.dll version 6.10.7601.17514
Windows 7 6.1 Build 7601 Service Pack 1
8 processors (x86-64; WOW64)
Language info: 1252, 0x409

Platform: Win32
Stable Includes:
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\include;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\include;
C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\include;
C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\include;

Other Includes:

Stable Source Directories:
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\src\\mfc;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\src\\mfcm;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\src\\atl;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\crt\\src;

Edited by - gbozoki on Feb 06 2013 7:25:26 PM

gbozoki
Ketchup Master

USA
70 Posts

Posted - Feb 06 2013 :  7:16:54 PM  Show Profile  Reply with Quote
Updated first post with more information.
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18751 Posts

Posted - Feb 07 2013 :  6:06:18 PM  Show Profile  Reply with Quote
Problem 1 we are aware of an occasional problem where Find References from C# will find references in C++ that it thinks are solid matches, so no question marks. Its hard to reproduce here, but we have found 1 test case, I have added some comments on what you are seeing to it:

case=72085

problem 2, I have put in a bug report for Find References finding the solid match inside the macro definition. That is clearly not helpful:

case=72271

Is there any chance of getting two of the .cs files you are using for testing purposes? The one where the class is declared and one of the files where you got the possible matches. I realise this is often not possible, but if it is possible it would allow me to try and reproduce this effect here.

If possible please submit the files via the form:

http://www.wholetomato.com/support/contact.asp

including this thread ID or URL in the description, so we can match it up.

zen is the art of being at one with the two'ness
Go to Top of Page

gbozoki
Ketchup Master

USA
70 Posts

Posted - Feb 13 2013 :  2:42:05 PM  Show Profile  Reply with Quote
Feline,

Thanks for your answer. I'm very busy right now so it may take a few days but I'll try to put together a small test project for you.
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
18751 Posts

Posted - Feb 13 2013 :  2:58:42 PM  Show Profile  Reply with Quote
Thank you, that will help. The problem with Rename updating macro declarations has been fixed internally, and the fix should be in the next build of VA.

zen is the art of being at one with the two'ness
Go to Top of Page

support
Whole Tomato Software

5566 Posts

Posted - Feb 25 2013 :  12:18:11 PM  Show Profile  Reply with Quote
case=72271 is a duplicate of case=9860 and is fixed in build 1929
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000