C#: Reduce location TRAP creation for Fields, Parameters, Constructors, Destructors and Operators. #20617
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…se this location in the QL code.
…and user defined operators and use this in the QL code.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this PR we update the extractor to only extract the location of Fields, Parameters, Constructors, Destructors and Operators in the current context and update the QL library to use these locations instead (this will then be the location of the unbound declaration). This is the final change required for converting the extractor to use
*IDs for source locations (we still need to look into assembly locations) when running in BMN.Details
Furthermore, for constructors there is an extra complication: We are only extracting a single best location for implicitly declared constructors (otherwise implicit constructors for partial classes will have multiple locations). I decided to keep the semantics as they were (and still only extract a single location). (@hvitved - this is related to our offline discussion on this topic).
Changes to tests.
There are some updates to the locations for tuple related fields. This is because we are now using the unbound declaration location (which is not in source for a value tuple). I changed one of the tests to use whether the tuple type is in source (instead of the fields, which are definitely not - not even prior to this change) to get some output. However, as it is mentioned in the extractor, Roslyn reports locations of tuple types somewhat inconsistent (sometimes it is in source and sometimes it is not), which explains the "missing" results in the TupleTypes test.
DCA
cs/invalid-string-formatting: The two added results are true positives (I didn't look into the cause of this as it could also be due to wobliness).cs/dereferenced-value-may-be-null: 15 alerts removed, I looked into this change. The alert was a false positive (so fine it is removed). The cause of the discrepancy is because the class of dereferences inspected by the query, in some corner cases for extension methods, depends on whether a parameter is from library code (as a heuristic). With the change in this PR, we use the location of the unbound declaration of a parameter and if this has a source location, it is no longer considered as being from a library (with the change in this PR thethisparameter ofSelectnow has a source location). Overall, I think this is in line with the intention of the heuristic.