![]() * JIT: Simplify JitDisasm matching behavior (#74430) This changes how the JIT matches method names and signatures for method sets (e.g. JitDisasm). It also starts printing method instantiations for full method names and makes references to types consistent in generic instantiations and the signature. In addition it starts supporting generic instantiations in release too. To do this, most of the type printing is moved to the JIT, which also aligns the output between crossgen2 and the VM (there were subtle differences here, like spaces between generic type arguments). More importantly, we (for the most part) stop relying on JIT-EE methods that are documented to only be for debug purposes. The new behavior of the matching is the following: * The matching behavior is always string based. * The JitDisasm string is a space-separated list of patterns. Patterns can arbitrarily contain both '*' (match any characters) and '?' (match any 1 character). * The string matched against depends on characters in the pattern: + If the pattern contains a ':' character, the string matched against is prefixed by the class name and a colon + If the pattern contains a '(' character, the string matched against is suffixed by the signature + If the class name (part before colon) contains a '[', the class contains its generic instantiation + If the method name (part between colon and '(') contains a '[', the method contains its generic instantiation For example, consider ``` namespace MyNamespace { public class C<T1, T2> { [MethodImpl(MethodImplOptions.NoInlining)] public void M<T3, T4>(T1 arg1, T2 arg2, T3 arg3, T4 arg4) { } } } new C<sbyte, string>().M<int, object>(default, default, default, default); // compilation 1 new C<int, int>().M<int, int>(default, default, default, default); // compilation 2 ``` The full strings are: Before the change: ``` MyNamespace.C`2[SByte,__Canon][System.SByte,System.__Canon]:M(byte,System.__Canon,int,System.__Canon) MyNamespace.C`2[Int32,Int32][System.Int32,System.Int32]:M(int,int,int,int) ``` Notice no method instantiation and the double class instantiation, which seems like an EE bug. Also two different names are used for sbyte: System.SByte and byte. After the change the strings are: ``` MyNamespace.C`2[byte,System.__Canon]:M[int,System.__Canon](byte,System.__Canon,int,System.__Canon) MyNamespace.C`2[int,int]:M[int,int](int,int,int,int) ``` The following strings will match both compilations: ``` M *C`2:M *C`2[*]:M[*](*) MyNamespace.C`2:M ``` The following will match only the first one: ``` M[int,*Canon] MyNamespace.C`2[byte,*]:M M(*Canon) ``` There is one significant change in behavior here, which is that I have removed the special case that allows matching class names without namespaces. In particular, today Console:WriteLine would match all overloads of System.Console.WriteLine, while after this change it will not match. However, with generalized wild cards the replacement is simple in *Console:WriteLine. * Update JIT-EE GUID Avoid using the same JIT-EE GUID as the main branch. |
||
---|---|---|
.. | ||
coding-guidelines | ||
design | ||
infra | ||
issue-mappings | ||
manpages/host | ||
project | ||
workflow | ||
area-owners.json | ||
area-owners.md | ||
deep-dive-blog-posts.md | ||
issue-cleanup.md | ||
issues-pr-management.md | ||
pr-builds.md | ||
pr-guide.md | ||
README.md |
Documents Index
This repo includes several documents that explain both high-level and low-level concepts about the .NET runtime and libraries. These are very useful for contributors, to get context that can be very difficult to acquire from just reading code.
Intro to .NET
.NET is a self-contained .NET runtime and framework that implements ECMA 335. It can be (and has been) ported to multiple architectures and platforms. It support a variety of installation options, having no specific deployment requirements itself.
Getting Started
Workflow (Building, testing, benchmarking, profiling, etc.)
If you want to contribute a code change to this repo, start here.
Design Docs
The Book of the Runtime is a set of chapters that go in depth into various interesting aspects of the design of the .NET Framework.
For your convenience, here are a few quick links to popular chapters:
For additional information, see this list of blog posts that provide a 'deep-dive' into the CoreCLR source code
Coding Guidelines
- CLR Coding Guide
- CLR JIT Coding Conventions
- Cross Platform Performance and Eventing Design
- Adding New Events to the VM
- C# coding style
- Framework Design Guidelines
- Cross-Platform Guidelines
- Performance Guidelines
- Interop Guidelines
- Breaking Changes
- Breaking Change Definitions
- Breaking Change Rules
- Project Guidelines
- Adding APIs Guidelines
Project Docs
To be added. Visit the project docs folder directly meanwhile.