Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
This is a debatable change, but I think that if there is a .cs file which is not marked as 'Compile', it should not be treated as code. It will not be part of the build process so it doesn't make sense to treat it as code for highlighting or code completion purposes.
I thought about that and atm it seems a good change.
Mostly because that's a good feedback for the user to see if a file is not compileable.
AFAICT the way this is implemented, it'll break completion and outlining for files that are not directly compiled into the project, e.g. xml, aspx, etc
no it works for xml etc. why should it break anything ? It's just blocking type system generation - and xml shouldn't do that.
Aspx shouldn't do that too, aspx should do an own handling of completion. TypeSystem parsing should only be done for real c#, vb.net etc. files.
I checked. This breaks xml and aspx files at the very least, probably T4 too.
* document outline is empty
* folding doesn't update after loading
* code completion in aspx files throws an error
* inferred completion in xml files is broken
They all rely on OnParsedDocumentUpdated. And it seems reasonable for the Document class to keep an up-to-date ParsedDocument, instead of every completion extension having to re-implement it.
What we really need to do is not to disable the parse, but disable inserting it into the completion DB, and disable the C# semantic highlighting.
code completion can't not work or not work depending on language - makes no sense then.
But just disable the semantic highlighting does that make sense ? With the completion DB it's right - that's an error.
btw. outline shouldn't be done with building a type system.
same applies for breadcrumb.
Parsing the open document is done for two main purposes:
1) To update the project type context
2) To have an AST of the current file
You're correct that only the C# files with the Compile build action need #1. But ~all files that have parsers need #2, for various reasons, which include outlining, folding, and code completion.
IME we need to separate #1 from #2. They should use the same parse (for performance), but the decision of whether to insert them into the project type context needs to be delegated to something else - some kind of ShouldInsertIntoProjectContext(ProjectFile file). This can also be used for checking whether to background parse files that are not open.
The reason I suggested explicitly disabling semantic highlighting for non-Compile files is that it doesn't make sense (and may not work correctly) if the file isn't part of the project type context.
completion may even not make sense - or work correctly if it's not part of the project. At least for c# it's true.
Well, sure, but that's the same for standalone C# files.
And it's certainly not true for XML, T4, aspx, etc.
ok then it's not possible to do it, I now just disable semantic highlighting for them ... even if I don't know if that's a good idea.