C#: Handle some BMN garbage types. #18894
Merged
Conversation
This file contains 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
michaelnebel
force-pushed
the
csharp/garbagetypes
branch
2 times, most recently
from
820737e to
c4033f2
Compare
michaelnebel
commented
Feb 28, 2025
| @@ -267,7 +267,7 @@ private void Populate(ISymbol? optionalSymbol, Entities.CachedEntity entity) | |||
|
|
|||
| bool duplicationGuard, deferred; | |||
|
|
|||
| if (ExtractionContext.Mode is ExtractorMode.Standalone) | |||
| if (ExtractionContext.IsStandalone) | |||
There was a problem hiding this comment.
Note, that this is not semantically equivalent! But the original code looks like a mistake.
michaelnebel
force-pushed
the
csharp/garbagetypes
branch
3 times, most recently
from
3c5e02f to
f061860
Compare
…he only flag set is Standalone.
michaelnebel
force-pushed
the
csharp/garbagetypes
branch
from
65225b3 to
6f80c56
Compare
michaelnebel
added
the
no-change-note-required
michaelnebel
force-pushed
the
csharp/garbagetypes
branch
from
6f80c56 to
5c931fa
Compare
tamasvajk
reviewed
Mar 5, 2025
| // (1) public class { ... } is a broken type as it doesn't have a name. | ||
| // (2) public class var { ... } is an allowed type, but it overrides the `var` keyword for all uses. | ||
| // It is probably a better heuristic to treat it as a broken type. | ||
| return string.IsNullOrEmpty(symbol.Name) || symbol.Name == "var"; |
There was a problem hiding this comment.
Are there other names that should be treated the same way? For example dynamic, nint, nuint?
There was a problem hiding this comment.
Yes, we can definitely extend the list with more "reserved" names.
| @@ -15,6 +15,7 @@ public class ExtractionContext | |||
| public ExtractorMode Mode { get; } | |||
| public string OutputPath { get; } | |||
| public IEnumerable<CompilationInfo> CompilationInfos { get; } | |||
| public bool IsStandalone => Mode.HasFlag(ExtractorMode.Standalone); | |||
There was a problem hiding this comment.
Do we still need a public Mode property? Can it be made private?
There was a problem hiding this comment.
No, it the value itself is written to trap outside this file (it is written to file_extraction_mode).
tamasvajk
approved these changes
Mar 6, 2025
|
Will run DCA one more time. |
|
No further comments on the latest DCA run compared to the previous ones. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 categorize some types as unknown types even though they are not considered error types in Roslyn in BMN. An example of this is that in the
roslynproject a type namedvaris introduced. Since all files are crammed into a single compilation all implicitly typed declarations are considered to have typevar- which is definitely wrong. Instead we should/can consider the type to be unknown (a better solution is of course to get the type right).Analysis of DCA results:
nightly/nightly: Onlyroslynandmonoappears to be affected (these are the projects that has different tuple counts on some of the quality queries). This is not surprising as it are those projects that have broken types defined (for instance a type namedvarand a type without a name). There doesn't appear to be any performance degredations. Tens of thousands of false positives for thecs/call-to-object-tostringhave been removed. Some new false positives have been introduced for some of the other quality queries - most prominently iscs/constant-condition. Improving this again will require further investigation (I think this is due to improper handling of unknown types inisMatchingConstant- will make a follow up PR for that). All this boils down to incorrect typing of expressions and variables. DCA also shows an explosion of expressions inroslynthat doesn't have a type. This is expected as most expressions inroslynwere assigned an incorrect type (either the typevaror the type without a name).nightly/security-extended: No changes in results or performance.