I submitted the repro. I have raised issue RSRP-199662 and have emailed you.

Regards,
Eddie

Thanks. I have a repro and I will submit it via the link you provided above. I’ll email you once I have done that!

Regards,

Eddie

I fully agree. We need to get this bug fixed and drastically improve error reporting on the pattern, which is already being done.

Could I please ask you to send us the patterns you are using and a small project to reproduce? If you could log it in http://youtrack.jetbrains.net and send me the ID, I’ll make sure it will be looked at. My email is hadi at jetbrains.

Thanks.

Well I am at my wit’s end trying to get the ’search’ feature to work on the Pattern Catalog window. I have added patterns that I know 100% work because they work on the Structural Search / Replace dialog - but once I save it to the pattern catalog and try to search off there I keep getting the infamous “Cannot parse pattern” error message. This has happened on more one computer - it’s not just my environment. The funny thing is, you can tell the patterns do work because ReSharper highlights code issues matched by the patterns! Clearly this is a bug that needs fixing guys. It’s been occurring since the feature was introduced as far as I recall.

This is most frustrating! I have a large solution with 57 projects and this feature would be an incredible asset but the problem I am experiencing renders it useless. I even tried removing all projects except for the core library, unloaded ReSharper (you know ReSharper_ToggleSuspended), reloaded, and still it does not work.

JetBrains ReSharper 5.1 Full Edition
Build 5.1.1753.4 on 2010-10-15T15:51:30

PS: Don’t get me wrong; I love the structural search and replace. One suggestion though: when a pattern is indeed wrong and cannot be parsed, it would be awesome if the UI informed the user as to *why* it cannot be parsed.

Consider this code
IService { IFoo GetIt(); }
//…
var foo = service.GetIt();
if (foo != null )
service.StoreIt();

//Now we should refactor IFoo to be an int instead (for some weird reason), so we start with finding all references for IFoo. The above is not found since var is used. So we continue refactor GetIt() to return int instead of IFoo and return 0 where it previously returned null. Compile - no errors, but hopefully our unit tests aren’t 100% coverage any longer and/or failing, so we can discover that something now is wrong.

//If we instead use:
IFoo foo = service.GetIt();
if (foo != null )
service.StoreIt();

//We a) find the reference for IFoo before we continue refactoring b) We get compile error for refactoring since IFoo cannot be implicitly converted to an int.
//In both a and b we are helped to spot the foo != null and can change it to foo != 0.

Thus, usage of var keywoard IMHO should not be encouraged if it can be avoided :-).

It underlines entire line.

Your issue was solved with latest build right?