You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 4f4d3bb
Browse filesBrowse the repository at this point in the historyBrowse files
fix: handle types without a namespace or assembly in reside-in checks
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 tests use a new TestAssemblies/FunctionPointerAssembly containing a
class with a function pointer field, loaded as its own architecture.
Resolves#492
Signed-off-by: Adarsh Choudhary <adarshchoudhary087@gmail.com>
0 commit comments