[236] LF Line Endings = Crash

I just noticed a problem tonight while working on some inherited code in which some of the source files have LF line endings instead of CR/LF. When this happens, I respond Yes to have Visual Studio automatically translate the LF line endings to CR/LF. The odd thing is that ReSharper then adds a really odd error highlight near the end of the source file in about the location where the file ended before the translation. That is, if the file contains 50 lines of code with LF line endings, I can just about count backwards 50 characters from the end of the file where the odd highlighting is located. It looks as if ReSharper is getting mixed up trying to analyze either the original file or some intermediate during Visual Studio's translation. In other words, the last method might look something like this:

...
public Color this[int index]
{
return array[index];
}
}
}

If I instruct ReSharper to format the code at this point, the code becomes corrupted:

...
public Color this[int index]

} <--- end of class declaration
} <--- end of namespace declaration
rn array[index];

Right after reformatting the code, ReSharper throws an exception (although I forgot to write down the two numbers from the tracker).

I can easily work around the problem by letting Visual Studio translate the line endings, closing and saving the file, and then reopening the file for editing (presumably to force ReSharper to reanalyze the file).

I'll grab the latest build in a few minutes and see if I can reproduce the error.

2 comments
Comment actions Permalink

Hi,

thanks for reporting! Yes, it's a good idea to check this problem with the
latest build 244. Please notify us of the results. Thanks.

Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

I just noticed a problem tonight while working on some inherited code
in which some of the source files have LF line endings instead of
CR/LF. When this happens, I respond Yes to have Visual Studio
automatically translate the LF line endings to CR/LF. The odd thing is
that ReSharper then adds a really odd error highlight near the end of
the source file in about the location where the file ended before the
translation. That is, if the file contains 50 lines of code with LF
line endings, I can just about count backwards 50 characters from the
end of the file where the odd highlighting is located. It looks as if
ReSharper is getting mixed up trying to analyze either the original
file or some intermediate during Visual Studio's translation. In other
words, the last method might look something like this:

...
public Color this[int index]
{
return array[index];
}
}
}
If I instruct ReSharper to format the code at this point, the code
becomes corrupted:

...
public Color this[int index]
{
retu
}
} <--- end of class declaration
} <--- end of namespace declaration
rn array[index];

Right after reformatting the code, ReSharper throws an exception
(although I forgot to write down the two numbers from the tracker).

I can easily work around the problem by letting Visual Studio
translate the line endings, closing and saving the file, and then
reopening the file for editing (presumably to force ReSharper to
reanalyze the file).

I'll grab the latest build in a few minutes and see if I can reproduce
the error.



0
Comment actions Permalink

I am attaching a couple of screenshots that show the effect of CR/LF translations on a source file. The first shot shows the odd brace highlighting right after Visual Studio 2005 converts LF to CR/LF. The second shot shows the result of having ReSharper reformat the code. These screenshots were taken with Build 244, but so far Build 244 has not crashed as a result of this.


"Lothan" <lothan@newsguy.com> wrote in message news:e4bvm4$vod$1@is.intellij.net...
I just noticed a problem tonight while working on some inherited code in which some of the source files have LF line endings instead of CR/LF. When this happens, I respond Yes to have Visual Studio automatically translate the LF line endings to CR/LF. The odd thing is that ReSharper then adds a really odd error highlight near the end of the source file in about the location where the file ended before the translation. That is, if the file contains 50 lines of code with LF line endings, I can just about count backwards 50 characters from the end of the file where the odd highlighting is located. It looks as if ReSharper is getting mixed up trying to analyze either the original file or some intermediate during Visual Studio's translation. In other words, the last method might look something like this:

...
public Color this[int index]
{
return array[index];
}
}
}

If I instruct ReSharper to format the code at this point, the code becomes corrupted:

...
public Color this[int index]

} <--- end of class declaration
} <--- end of namespace declaration
rn array[index];

Right after reformatting the code, ReSharper throws an exception (although I forgot to write down the two numbers from the tracker).

I can easily work around the problem by letting Visual Studio translate the line endings, closing and saving the file, and then reopening the file for editing (presumably to force ReSharper to reanalyze the file).

I'll grab the latest build in a few minutes and see if I can reproduce the error.



0

Please sign in to leave a comment.