| T O P I C R E V I E W |
| briancollins |
Posted - Jul 08 2009 : 05:56:12 AM
Having just upgraded to 1727, I find that my c# code is no longer reliably being parsed. It manifests in a number of ways, best illustrated by the outline:
There is a further method between ReadStandAloneDocument and ReusePreviousDataFromUnchangedList, and these are all at the same nesting. The #if outlines reference within this unmentioned method.
As well as the missing method, the nesting has got totally confused. The problem manifists itself consistently throughout VAX in all uses of the offending symbols. So I assume it is some sort of parsing problem.
Any ideas? Any information that would help track this down?
Brian |
| 22 L A T E S T R E P L I E S (Newest First) |
| support |
Posted - Aug 22 2009 : 7:12:05 PM
case=28539 is fixed in build 1731 |
| feline |
Posted - Aug 21 2009 : 10:52:34 AM
This bug is fixed in the beta, the release notes have not been finished just yet is all 
1731 is a beta, but hopefully the only ruff edges are around the new scoped suggestions and Create From Usage features. Both of these have been through quite a lot of internal testing, and we are happy with them, otherwise we would not be releasing them. If you do run into any new problems then please report them and we will try to fix them as quickly as possible. |
| briancollins |
Posted - Aug 21 2009 : 03:28:29 AM
Perhaps a little premature, but I can can confirm that Beta build 1731 fixes this problem. This was my reason to upgrade from 1715 - so I hope the beta doesn't introduce *too* much instability from its enhancements
Thanks
Brian |
| feline |
Posted - Jul 15 2009 : 10:33:12 AM
Personally I had not thought to add an automated test for a literal string in C# that ends with a / that is used inside an if statement 4 levels of curly brackets deep... That is probably not the minimum test case, but that is what the one I found looked like. I still tend to use "//" myself, due to all my years of C and C++
I do have some other quite obscure automated test cases though |
| briancollins |
Posted - Jul 15 2009 : 10:26:44 AM
Thanks feline. I understand that these things happen to the best of us and that no regression test suite is ever going to be perfect. It was a pretty unlikely place to find a new problem though - at least when viewed by an outsider. |
| feline |
Posted - Jul 15 2009 : 10:21:36 AM
briancollins, in reply to it sneaking in undetected, we run a large and ever growing set of tests on each new build of VA, but to say there are a lot of possible things to test would be something of an understatement |
| briancollins |
Posted - Jul 15 2009 : 04:06:25 AM
Thanks for the workaround. But I'll stick with build 1715 until there's a fix
Brian |
| Dany |
Posted - Jul 15 2009 : 04:04:33 AM
Just a few minutes ago I discovered a workaround! 
Simply place a comment like//@"\\" at the end of each line containing a single @"\\". Then all problems mentioned in topic 4242 vanish...  Maybe in your case too?
I found this, because I had two occurrences of @"\\" in consecutive lines and the following lines where just fine. |
| briancollins |
Posted - Jul 15 2009 : 02:47:05 AM
Thanks Dany,
When I discovered this, I had absolutely no idea that it could be caused by mis-parsing of a string literal. In fact even now I know, I struggle to envisage how a problem like this could sneak in undetected - having worked fine for years. But that's software for you!!
Brian |
| Dany |
Posted - Jul 15 2009 : 01:43:32 AM
Brian,
just for your information, take a look here http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=4242, where several other problems with that @"\\" are shown.
feline,
I just can't wait to have this fixed...  |
| feline |
Posted - Jul 13 2009 : 09:53:56 AM
Thank you for the update. This has been fixed internally, and our developers found the same pattern, with a string ending with \
Hopefully the fix will be present in the next build of VA. |
| briancollins |
Posted - Jul 13 2009 : 02:51:00 AM
I can confirm that the problem is triggered by any literal strings of the form @"...\\". I.e. those using @"..." notation where the last quoted character is a backslash - which is not escaped in that form of string literal. It affects more than just @"\\" strings.
Brian |
| briancollins |
Posted - Jul 10 2009 : 1:26:45 PM
I shall try the "\\\\" workaround on monday. If that works, then great. Otherwise I shall stick with build 1715 as it generally does what I need.
Thanks
Brian |
| feline |
Posted - Jul 10 2009 : 1:07:09 PM
As far as I can tell the problem is being triggered by the two lines like:
string mappingFilePath = @"\\" + @"\\Mapping.xml";
They were a bit more complex in your file, but I have reduced them down to this. I have put in a high priority bug report for this, breaking VA is not a good thing:
case=28539
You may find that one of the builds between 1715 and 1727 works OK for you:
http://www.wholetomato.com/support/history.asp
I have not checked to see exactly when this broke. Depending on how many files this effects you might be able to work around it for now since I think "\\\\" should mean the same as @"\\" |
| feline |
Posted - Jul 10 2009 : 12:38:42 PM
I have the file, many thanks for this. I have reproduced the problem here. I am currently trying to see if I can simply the file even further to find the trigger.
As you say, things are clearly going wrong. |
| briancollins |
Posted - Jul 10 2009 : 02:33:04 AM
File is on its way
Brian |
| feline |
Posted - Jul 09 2009 : 11:01:50 AM
Please submit the file 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. We will only use the file to try and understand then fix the problem, keeping all of its content confidential. |
| briancollins |
Posted - Jul 09 2009 : 10:39:02 AM
I have a "cut-down" version (~600 lines) of my offending source file that still manifest the problem when loaded (in isolation) into VS2005. If I try to remove much more code, the problem goes away, so I suspect it is some pattern of block nesting that triggers it.
I am happy to mail this to you if there is a way.
Brian |
| briancollins |
Posted - Jul 09 2009 : 09:59:27 AM
I'll try to make a small example that I can post publicly. If that fails, I may need to mail (in confidence) the offending file |
| briancollins |
Posted - Jul 09 2009 : 09:57:53 AM
No - no cases like that. All #if code wraps well-formed code (i.e. whole statements or blocks) apart from one instance where the conditional code is an "if" clause.
#if 0
if(condition)
#endif
{
do something
}
And it's fine with 1715.
Brian |
| feline |
Posted - Jul 09 2009 : 09:27:00 AM
Could you post a small code sample that shows this problem? From the VA Outline picture alone I am not sure where to start trying to find the problem.
Are there any unmatched curly brackets in the file? I have seen C++ code like this:
void problemFunction()
{
#if 0
{
{
#endif
}
cause odd problems, so I am wondering if something similar is happening here. |
| briancollins |
Posted - Jul 09 2009 : 03:49:02 AM
Forgot to say - this is VS 2005.
Removing #if blocks of code (my first suspicion) made no difference.
For now I have gone back to 1715 - shame I just paid my $49 to get up to date ! :-) |
