Bug 3148 - Watch/immediate windows can't always resolve the provided code snippet
Summary: Watch/immediate windows can't always resolve the provided code snippet
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Debugger ()
Version: 2.8.6
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: Jeffrey Stedfast
URL:
Depends on:
Blocks:
 
Reported: 2012-01-30 17:00 UTC by Sebastien Pouliot
Modified: 2012-02-08 12:34 UTC (History)
2 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
screenshot (44.96 KB, image/png)
2012-02-06 16:58 UTC, Sebastien Pouliot
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Sebastien Pouliot 2012-01-30 17:00:05 UTC
MD 2.8.6.4.

For some reason(s) the watch window (and other debugging parts) of MonoDevelop can "lose" the context of the source. That makes debugging a lot less productive.

E.g. from the Immediate pad (watch pad behave just like it)

> ? Thread.CurrentThread
Unknown member: Threading

^^^ it was smart enough to reach/find "Threading" (I did not write it) but decided it was something unknown

Giving more context did not help

> ? System.Threading.Thread.CurrentThread
Unknown member: Threading
> ? global::System.Threading.Thread.CurrentThread
Unknown member: Threading
Comment 1 Jeffrey Stedfast 2012-01-31 10:57:10 UTC
This is *probably* an OldNRefactory resolver issue, and probably requires a similar fix as bug #513 but might not be exactly the same issue.
Comment 2 Jeffrey Stedfast 2012-02-02 19:52:03 UTC
Can you attach a sample app? This seems to work for me on git master MonoDevelop on my FlightLog app (Simulator *and* Device).

MonoTouch 5.0.4
Comment 3 Jeffrey Stedfast 2012-02-02 19:54:40 UTC
Works in MonoDevelop 2.8.6.4 too:

> Thread.CurrentThread
Evaluating 
{System.Threading.Thread}
> ? Thread.CurrentThread
{System.Threading.Thread}
>
Comment 4 Sebastien Pouliot 2012-02-06 16:58:30 UTC
Created attachment 1319 [details]
screenshot

still occurs
screenshot when debugging inside monotouch-tests (unit tests)
Comment 5 Jeffrey Stedfast 2012-02-07 08:08:25 UTC
okay, thanks. I'll try out those tests and see if I can repro.
Comment 6 Jeffrey Stedfast 2012-02-07 17:02:01 UTC
I can repro now, but strange that only in monotouch-tests
Comment 7 Sebastien Pouliot 2012-02-07 17:09:00 UTC
pretty sure it occured to me outside it...
have you checked the linker settings ?

not that I see how System.Threading.Thread.CurrentThread.ManagedThreadId could be printed and not found at the same time ?!?
Comment 8 Jeffrey Stedfast 2012-02-07 18:45:50 UTC
Yea, the problem is that the AST parser creates a tree of MemberReferenceExpressions assuming that CurrentThread is a member of Thread (ok so far) which is a member of Threading (Threading isn't a type, it's a namespace - oops!) which is a member of System (which is also a namespace, oops!)

The end result is that NRefactoryEvaluator.cs:VisitMemberReferenceExpression() fails here:

ValueReference ch = vref.GetChild (memberReferenceExpression.MemberName, ctx.Options);
if (ch == null)
	throw CreateParseError ("Unknown member: {0}", memberReferenceExpression.MemberName);


vref.GetChild() returns null.


Reassigning to Mike Krueger to take a look at because I can't figure out how to make this work.
Comment 9 Jeffrey Stedfast 2012-02-07 18:48:55 UTC
Sebastien: yea, I had it fail in the tooltips for me in a tooltip a few minutes ago while debugging MonoDevelop debugging monotouch-tests... so... I dunno.

Looking back at the snippets I posted above, it seems to have just printed the type and not the value. So it was wrong even there, it just didn't error. Might have to do with the Debugger EvaluationOptions (e.g. UseExternalTypeResolver)
Comment 10 Mike Krüger 2012-02-08 02:38:21 UTC
How is this evaluation done ?

I've not really knowledge about this code - but generally it seems that it's not "set up" in the right way.

A stub source file needs to be generated with the usings/namespaces from the current scope. (like ASP.NET)

Then the project references of the project need to be set the right way. And then in can be given to a "resolver" engine. But AFAIK that is atm done using the mcs expression evaluator ?!?
Comment 11 Lluis Sanchez 2012-02-08 02:54:58 UTC
The evaluation is done in Mono.Debugging.Evaluation.NRefactoryEvaluator, which uses a visitor to evaluate the expression. The visitor uses a resolver when it needs to. However I don't think this is a resolver issue. The GetChild method used above is not based on the monodevelop type system, but based on the information provided by the debugger. What I think it is failing in this case is the method SoftDebuggerAdaptor.GetType.
Comment 12 Jeffrey Stedfast 2012-02-08 10:59:27 UTC
Thanks Lluis. If this isn't Mike's domain, then I'll reassign back to myself.
Comment 13 Jeffrey Stedfast 2012-02-08 12:34:35 UTC
Fixed in git master