🐛 Fix incorrect caching of XML documentation comments with/without expandIncludes#36021
🐛 Fix incorrect caching of XML documentation comments with/without expandIncludes#36021sharwell merged 2 commits intodotnet:masterfrom
Conversation
|
Please provide some context for reviewers. |
| private SymbolCompletionState _state; | ||
| private CustomAttributesBag<CSharpAttributeData> _lazyCustomAttributesBag; | ||
| private string _lazyDocComment; | ||
| private string _lazyExpandedDocComment; |
There was a problem hiding this comment.
private string _lazyExpandedDocComment; [](start = 8, length = 39)
Is there a big advantage to cache this? Is it common to request this information? #Closed
There was a problem hiding this comment.
I'm not sure how valuable the cache is. I have observed documentation comment evaluation as a substantial contributor to some poor performance scenarios, but that's not a direct indicator of the helpfulness of the cache (in theory or as implemented). This commit was part of an experimental branch where I updated Quick Info to expand included documentation as part of the presentation process (which I believe is the correct approach), only to find that in some cases the results were not getting expanded.
There was a problem hiding this comment.
I'm not sure how valuable the cache is.
We might want to take approach used for PE Symbols. It looks like implementations of GetDocumentationCommentXml for them cache result of the first request and recalculate if subsequent requests use different parameters.
In reply to: 288692002 [](ancestors = 288692002)
There was a problem hiding this comment.
We might want to take approach used for PE Symbols. It looks like implementations of GetDocumentationCommentXml for them cache result of the first request and recalculate if subsequent requests use different parameters.
The PE symbol implementation looks at the culture info, which (IMO) seems less likely to change during a session. It ignores the expandIncludes parameter.
With that said, either approach works for me. I am working on tests which cover the API for source symbols. Currently I've implemented the VB side the same way I implemented the C# side in this pull request. If you prefer it the other way, I can switch them all.
|
Does VB have the same problem? #Closed |
|
Done with review pass (iteration 1). Please add tests covering the affected code paths. #Closed |
Yes, but I have not updated those cases. Definitely an oversight on my part.
Can you help identify a good place for these tests? I have some tests in another branch that cover these paths, but the tests are for a somewhat unrelated feature in the IDE layers. It would be better to have more localized tests in the compiler layer. |
It looks like we have a bunch of tests for In reply to: 497041661 [](ancestors = 497041661) |
Great! I'm adding a new IncludeTests.cs in this folder. To start with I'm only covering the behavior I changed and not actually writing tests for the full |
3eafe02 to
551e31c
Compare
|
@AlekseyTs VB implementation and tests are now added |
|
@AlekseyTs It looks like the code might not be correctly using the culture provided to |
Could you provide more details about the failures? #Closed |
|
The Spanish leg is failing because it prints a localized error message even when GetDocumentationCommentXml is called with EnsureEnglishUICulture.PreferredOrNull. |
This is likely due to the fact that error messages aren't really a part of a doc comment, they are coming from somewhere else and are localized based on the current culture. Consider adding |
|
@sharwell In the future, please, consider to not rewrite commits in the PRs that are being reviewed. This prevents people from reviewing incrementally and often can lead to losing mapping of comments to relevant positions. |
|
@AlekseyTs I made sure to not rebase so the incremental changes were preserved by the force-push events in the timeline without bringing in changes from other branches. |
src/Compilers/VisualBasic/Portable/DocumentationComments/SourceDocumentationCommentUtils.vb
Outdated
Show resolved
Hide resolved
There is only one commit in this PR now, there is no way for me to separate what changes I already looked at and what changes you've made after that. Significant portion of work done during previous review pass cannot be reused or built upon because I have to review everything from scratch. So, please, consider avoiding rewriting commits, push additional commits and squash/rebase at the end once review process is completed. |
I submitted https://github.com/maintainers/early-access-feedback/issues/255 requesting improved clarity of the relation between the pull request at the time of review and the most recent iteration of the pull request. |
For some reason the link doesn't work for me, so I cannot comment on the request. |
|
Note, however, that often we are not using GitHub UI for review. |
* Use ref locals to simplify code flow * Fix VB code layout
|
Feel free to merge when CI is green. Thanks |
No description provided.