-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Merge master to master-vs-deps #45456
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
All array types for one elemnt type is consider same in our index. e.g. int[], int[][] and int[,] are just represent as int[]
Since they are already from the same compilation that triggered completion.
…emantic diagnostics for a specific tree, which are categorized by each analyzer that reported the diagnostic. We have existing APIs on this type that return the same diagnostics, but as a single group instead of categorized by analyzer. Latter is required by the IDE analyzer host as we cache diagnostics from each analyzer.
First step towards #44408 1. Refactor IDE open file analysis so that we have a single place where we execute the analyzers for document analysis. I have preserved the existing IDE layer diagnostic caching in this PR, but it should hopefully go away in future when we move the diagnostic computation to OOP. 2. Perf improvement: Currently, we execute open file analyzers one at a time by making separate calls into CompilationWithAnalyzers. This identified overhead where we are recomputing lot of stuff with each call and missing semantic model/bound node cache hits. This PR simplifies the approach by invoking a single syntax/semantic call into CompilationWithAnalyzers with all relevant analyzers. This required adding a new public API to CompilationWithAnalyzers to return syntax/semantic diagnostics for a tree/model grouped by analyzers, which has been split into a separate commit. 3. Remove code for code fix support for CompilationEndAction diagnostics - these actions are not executed in the IDE live analysis, so the code was not executing. Additionally, we have identified that we never want to run these actions in IDE live analysis due to associated perf concerns. Future steps: 1. Move open file diagnostic analyzer execution to OOP 2. Remove IDE layer diagnostic caching, and rely on caching at OOP side 3. Investigate moving even compiler diagnostic computation to OOP - need to ensure responsiveness of refreshing compiler diagnostics on typing is not affected
…emantic diagnostics for a specific tree, which are categorized by each analyzer that reported the diagnostic. We have existing APIs on this type that return the same diagnostics, but as a single group instead of categorized by analyzer. Latter is required by the IDE analyzer host as we cache diagnostics from each analyzer.
A workspace can customize which changes are allowed to be applied through TryApplyChanges. There's a CanApplyChanges that generally is called with each type of change which you can opt in for. There is also a specific overloads for filtering specific changes to CompilationOptions or ParseOptions, since a host may support changing some of those but not all of them. This documents our existing behavior and adds tests to confirm the behavior. There were some Debug.Asserts() that are incorrect and are now fixed.
So we don't need to process extension methods with receiver type we know wouldn't match
Today, we realize ConstantValues of nodes as soon as an IOperation is created. This means that for things like constant string addition, we immediately use O(n^2) memory when an IOperation tree is fully realized. Internally the compiler uses an approach to only realize the final string when necessary, and this ports IOperation to use that representation under the hood for strings. When an IOperation.ConstantValue that is a string is realized, we take a WeakReference to that string. If a subsequent request comes in and the reference has not yet expired, we return that same string to avoid duplication, but avoid rooting the object if one user requests the constant value and then immediately gets rid of it. Fixes #43019.
…framework Set ignoreAssemblyKey to true during SymbolKey resolution
The perf with ignoreAssemblyKey = true doesn't meet the bar
…overloads instead of new APIs
…overloads instead of new APIs
…AnalysisResultAsync APIs as an outcome of design change in #45347
Perf improvement for completion of unimported extension methods
|
Reset HEAD of |
Fix inconsistencies in handling CompilerVisibleItemMetadata
* Additional tests for nested function contexts. * Override VisitFunctionPointerLoad in MethodToClassRewriter. * Adjust debug asserts.
…626.2 (#45482) Microsoft.DotNet.Arcade.Sdk From Version 1.0.0-beta.20302.3 -> To Version 1.0.0-beta.20326.2 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
We have two members in TypeKind that point to the same value, Struct and Structure. Because of this, Enum.ToString(), which under the covers uses a binary search, isn't stable which one it will pick and it can change if other TypeKinds are added. This ensures we keep using the same string consistently. We also have a few members in MethodKind that are also duplicates, but it appears those have kept stable. To be safe, we now serialize explicitly. Fixes #44714
|
Reset HEAD of |
Function pointer bug fixes
|
Reset HEAD of |
Reduce memory required for document change processing queues
|
Reset HEAD of |
Update Language Feature Status
|
Reset HEAD of |
…nsistency Fix up nondeterminism in serializing naming style preferences
|
Reset HEAD of |
* Move SymbolSearch down to EditorFeatures * RemoteControl package reference
|
Reset HEAD of |
This is an automatically generated pull request from master into master-vs-deps.
git fetch --all git checkout merges/master-to-master-vs-deps git reset --hard upstream/master-vs-deps git merge upstream/master # Fix merge conflicts git commit git push upstream merges/master-to-master-vs-deps --forceOnce all conflicts are resolved and all the tests pass, you are free to merge the pull request.