fix: handle types without a namespace or assembly in reside-in checks - #501
Open
iamAdarshh wants to merge 1 commit into
Open
iamAdarshh wants to merge 1 commit into
iamAdarshh wants to merge 1 commit into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #501 +/- ##
==========================================
+ Coverage 86.33% 86.39% +0.05%
==========================================
Files 260 260
Lines 12496 12506 +10
Branches 1216 1222 +6
==========================================
+ Hits 10789 10804 +15
+ Misses 1372 1364 -8
- Partials 335 338 +3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Function pointer types are created by the DomainResolver with a null
Namespace and a null Assembly. They only ever appear as referenced types,
so rules on Types() were unaffected, but any namespace or assembly
predicate on Types(true) dereferenced the null and threw a
NullReferenceException, e.g.
Types(true).That().ResideInNamespace("System")
on System.Private.CoreLib.
Guard ResidesInNamespace(Matching) and ResidesInAssembly(Matching) so a
type without a namespace or assembly simply does not reside in one. The
corresponding conditions had the same problem in two more places: the
assembly-object overloads compared via ruleType.Assembly.Equals(...), and
every ResideIn*/NotResideIn* condition builds its failure description
eagerly from Namespace.FullName or Assembly.FullName. Compare with the
static Equals and describe such types as "does not reside in a namespace"
or "does not reside in an assembly".
The new fixture adds a function pointer to the shared test architecture,
which made ArchLoaderTests.SameFullNameInMultipleAssemblies trip over the
same null while filtering ReferencedTypes; make that filter null-safe.
Resolves TNG#492
Signed-off-by: Adarsh Choudhary <adarshchoudhary087@gmail.com>
iamAdarshh
force-pushed
the
fix/null-namespace-function-pointer
branch
from
September 28, 2026 14:09
8de0137 to
fcefb43
Compare
This branch has not been deployed
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
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.
Function pointer types (Cecil
FunctionPointerType) are created byDomainResolverwith anullNamespaceand anullAssembly. They only show up inReferencedTypes, soTypes()rules work, but any namespace/assembly predicate onTypes(true)throws aNullReferenceException, as reported in #492:This follows Option 1 from the issue, as the maintainer suggested: null-guard the helpers instead of dropping function pointers from the type set.
Changes
TypeExtensions:ResidesInNamespace,ResidesInNamespaceMatching,ResidesInAssemblyandResidesInAssemblyMatchingreturnfalsefor a type without a namespace/assembly.TypeConditionsDefinition:SimpleConditionbuilds the failure description eagerly, even for passing objects, so everyResideIn*/NotResideIn*condition dereferencedNamespace.FullName/Assembly.FullName. Those messages now go through two small helpers that fall back to"does not reside in a namespace"/"does not reside in an assembly".System.Reflection.Assemblyoverloads ofResideInAssembly/NotResideInAssemblycompared withruleType.Assembly.Equals(...). They now use the staticEquals(a, b).FunctionPointerTestsadds a class with adelegate*<int, void>field and covers the extension methods, the predicates (ResideIn*/DoNotResideIn*) and the conditions for both namespace and assembly. All of them failed with an NRE before this change.ArchLoaderTests.SameFullNameInMultipleAssembliesfilters the shared test architecture'sReferencedTypesbytype.Namespace.FullName. The new fixture puts a function pointer there, so that filter is now?..I also ran the exact snippet from the issue against
System.Private.CoreLib. The 32 null-namespace referenced types are still present, andTypes(true).That().ResideInNamespace("System")now returns results instead of throwing.The issue only mentions the namespace helpers. I included the assembly side because function pointers have a null
Assemblytoo, andResideInAssemblyonTypes(true)fails the same way. If you'd rather keep this PR to the namespace fix, I'm happy to split it out.dotnet build,dotnet testandmise run checkpass locally.Resolves #492