Bug 332 - Debugger shows all conditional BCL code as comment
Summary: Debugger shows all conditional BCL code as comment
Status: NEW
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Text Editor ()
Version: Trunk
Hardware: PC Linux
: Normal major
Target Milestone: ---
Assignee: Mike Krüger
URL:
Depends on:
Blocks:
 
Reported: 2011-08-19 07:48 UTC by Marek Safar
Modified: 2015-09-08 16:41 UTC (History)
4 users (show)

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

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 for Bug 332 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
NEW

Description Marek Safar 2011-08-19 07:48:15 UTC
When debugging BCL code (e.g. corlib classes) MD debugger treats all conditional code as comments (due to NET_4_0, NET_2_0, etc). This makes it useless because none of the debugger source code features work.
Comment 1 Mikayla Hutchinson [MSFT] 2011-09-05 16:03:15 UTC
This would happen when the debugger is loading arbitrary files from mdbs. There's not really anything we can do, since we don't have any way to know what combination of defines was used when compiling the code.
Comment 2 Marek Safar 2011-09-05 17:18:24 UTC
Really? Surely stepping into code means that the code was compiled and not commented out. Just do what all other debuggers do.
Comment 3 Mikayla Hutchinson [MSFT] 2011-09-05 20:25:30 UTC
In order to resolve symbols correctly, we need to parse the file with the same set of defines used when compiling it. Indeed, it's entirely possible for a file not to be parsable unless a subset of defines is used. For simple cases we could guess the defines based on what's in the mdb, I suppose, but it would be hard to guarantee it to be correct.

Probably the best solution would be that we special-case files that aren't in a project - for the tooltips, we'd stop using the resolver and fall back to the inferior and simplistic "does the word under the caret match one of local in the current frame" approach. We'd also need to disable semantic highlighting.
Comment 5 Marek Safar 2011-09-06 03:51:29 UTC
ok, stepping back little bit but comments like we cannot really do anything about it make me sad.

If you think you need a set of defines used for compilation and they are not available from mdb, just assign the bug to mdb or compiler and someone else to make the change. This is not too difficult problem but as you are at the top of the chain you need to drive the bug resolution in some cases.
Comment 6 Jeffrey Stedfast 2012-08-01 14:23:24 UTC
Marek to put the #define's that were enabled when compiling the assembly so that MonoDevelop can enable those in the editor so that the correct #ifdef blocks are parsed by the resolver (needed for hovering over symbols)
Comment 7 Jeffrey Stedfast 2012-08-01 14:24:22 UTC
another option would be for MonoDevelop to infer which #defines were enabled based on the line #'s that we have symbol information for.
Comment 8 Jeffrey Stedfast 2012-08-01 14:27:51 UTC
sounds like we've decided that option #2 is the way to go since we need to work with csc compiled assemblies.
Comment 9 Jeffrey Stedfast 2012-10-19 16:45:37 UTC
This probably belongs in TextEditor?
Comment 10 Mike Krüger 2012-10-29 02:12:40 UTC
No not really the text editor (why should it?).

The defines must be defined in the symbols of the project that is opened. A file belongs to a project and there are the defines that are used to parse it. The editor/parser should do the right job.

(btw. it can be a 'bogus' project - doesn't need to be a real one.)

But fixing that would mean finding the right set of defines - remember an if could be any conditional expression, like :

#if FOO && (!BAR || FOOBAR) 
   ...
#endif

Can vs.net do it ? It's an interesting problem btw - esp if more than one set of defines solves an expression and there is only one 'right' set for the debugging session. I would try to retrieve the right set from the .mdb files - or maybe we can but them into these files ?
Comment 11 Mike Krüger 2012-10-29 02:19:12 UTC
btw. just to be clear - it's generally not possible to find the 'right' set of defines just based on 'this if needs to be true' - jumping around in the program flow later on another set of defines may be required. 

That may result in re-parsing but also may cause wrong tooltips/completion before the reparse, because the original 'set' that solved the 1st #if was wrong. Therefore getting the right set out of the compilation/debugger symbols is the only thing I can imagine that works.