Bug 1795 - [New Resolver] Public keyword not shown sometimes when adding a new member
Summary: [New Resolver] Public keyword not shown sometimes when adding a new member
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: C# Binding ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Mike Krüger
Depends on:
Reported: 2011-10-31 11:47 UTC by Lluis Sanchez
Modified: 2011-11-03 07:55 UTC (History)
1 user (show)

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 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:

Description Lluis Sanchez 2011-10-31 11:47:23 UTC
Sometimes some keywords are not added to code completion when adding a new member. For example, place the cursor just after the closing bracket of a method, press Enter 2 times and try to enter 'public'. The keyword is not there.
See screencast: http://screencast.com/t/VEYaraFe3n
Comment 1 Mike Krüger 2011-11-03 07:55:09 UTC
This is a resurrection of a problem that master suffers as well.

However master puts all keywords always into the list, that shadows some problems - at least from keywords (The new resolver branch can be a bit more picky in what keywords are given).

To make it simple: it's needed to reparse the file before code completion takes place - in the general case that's true - and always will be true. But parse the whole file on key stroke isn't possible for speed reasons.

I see several solutions to that:

1) Use an incremental compiler which is able to reparse a part of the ast (for example on text replace events)

2) Make code completion threaded (pop up when the background parser finishes)

3) Put the type/member regions in a self updating tree - that will give 99% correct member information at a low log (n) cost.

4) Reparse a portion of the file, to check in which member we're in.

1) Is IMO the best solution hands down. But mcs can't do that right now.

2) Would disturb the current workflow, our code completion window was always "fast" ... unlike some java IDEs which had 2) ... that'll give a horrible user experience.

3) Is very interresting - however doing that would work best, when I would give up the line/col locations of ast structures and just use "offsets". Thats is something that I would like to do, but would require some more mcs changes. But that would save memory as well.

4) That's the poor mans version of 1). 

For now I've implemented 4) ... it works and for code completion I need to do it anyways to gather the local variables, therefore it's not that much of an issue. I tried some approaches to implement - but I would tend to try out 3) sometime in the future.

But that may take up to another 10 years / so I close it for now as 4) works.