Skip to content

[TrimmableTypeMap][Core B] Foundation and AssemblyIndex#10817

Draft
simonrozsival wants to merge 1 commit intodotnet:dev/simonrozsival/ttm-core-a-foundationfrom
simonrozsival:dev/simonrozsival/ttm-core-b-index
Draft

[TrimmableTypeMap][Core B] Foundation and AssemblyIndex#10817
simonrozsival wants to merge 1 commit intodotnet:dev/simonrozsival/ttm-core-a-foundationfrom
simonrozsival:dev/simonrozsival/ttm-core-b-index

Conversation

@simonrozsival
Copy link
Member

@simonrozsival simonrozsival commented Feb 14, 2026

Sliced from #10805
Depends on #10816

Scope

  • Foundation pieces required by scanner (project, model/providers)
  • AssemblyIndex metadata indexing and lookup logic

Notes

  • This keeps scanner indexing concerns isolated from scanner execution flow.

@simonrozsival simonrozsival changed the title [TrimmableTypeMap][Core B] Foundation + AssemblyIndex (<1k) [TrimmableTypeMap][Core B] Foundation and AssemblyIndex Feb 14, 2026
@simonrozsival simonrozsival changed the base branch from main to dev/simonrozsival/ttm-core-a-foundation February 14, 2026 00:19
/// <summary>
/// Parsed [Register] or [Export] attribute data for a type or method.
/// </summary>
sealed class RegisterInfo
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should consider splitting this into RegisterInfo and ExportInfo

if (attrName == "RegisterAttribute") {
registerInfo = ParseRegisterAttribute (ca, customAttributeTypeProvider);
} else if (attrName == "ExportAttribute") {
// [Export] methods are detected per-method in CollectMarshalMethods
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// [Export] methods are detected per-method in CollectMarshalMethods
// [Export] methods are not handled yet and supporting them wil be implemented later

Comment on lines +192 to +193
foreach (var caHandle in typeDef.GetCustomAttributes ()) {
var ca = Reader.GetCustomAttribute (caHandle);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
foreach (var caHandle in typeDef.GetCustomAttributes ()) {
var ca = Reader.GetCustomAttribute (caHandle);
var attributes = typeDef.GetCustomAttributes ().Select (Reader.GetCustomAttribute);
foreach (var caHandle in attributes) {

if (typeDef.IsNested) {
var declaringType = reader.GetTypeDefinition (typeDef.GetDeclaringType ());
var parentName = GetFullName (declaringType, reader);
return parentName + "+" + name;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return parentName + "+" + name;
return $"{parentName}+{name}";

return name;
}

return ns + "." + name;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return ns + "." + name;
return $"{ns}.{name}";


public static AssemblyIndex Create (string filePath)
{
var peReader = new PEReader (File.OpenRead (filePath));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to consider IO errors here? Or will this need to be handled by the user of this class?

Comment on lines +389 to +393
/// <summary>
/// Type has [Activity], [Service], [BroadcastReceiver], [ContentProvider],
/// [Application], or [Instrumentation].
/// </summary>
public bool HasComponentAttribute { get; set; }
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really know if this information would be useful later, but it would be useful in tests I think: let's remember the exact type of the attribute please. I think it might be best to make this class abstract and add a sealed subclass for each of the component classes. The ApplicationBackupAgent and ApplicationManageSpaceActivity fields should be just on the ApplicationAttributeInfo class (without the redundant Application prefix).


bool ImplementsIJniNameProviderAttribute (TypeDefinition typeDef)
{
foreach (var implHandle in typeDef.GetInterfaceImplementations ()) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does typeDef.GetInterfaceImplementations () return only the interfaces implemented on this type level, or also the inherited interfaces? I would expect this API not to recursively explore the interfaces implemented on the base class and the base interfaces of the implemented interfaces. I think we should either not do this yet (we would only support the predefined set of attributes such as [Register], [Application], [Activity], ..., or do it properly and recursively explore the structure. This could be very expensive, so we'd need to carefuly cache if a given type (class or interface) implements IJniNameProviderAttribute. The more I'm thinking about it, the more I think we should not even look for this interface. We can add this logic once we run into a scenario that actually requires it.


var (registerInfo, attrInfo) = ParseAttributes (typeDef);

if (attrInfo != null) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (attrInfo != null) {
if (attrInfo is not null) {

continue;
}

TypesByFullName [fullName] = typeHandle;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it be better to store the resolved typeDef? It might not be, I'm just curious why we're storing the handle and not the actual definition in this cache.

@simonrozsival simonrozsival added copilot `copilot-cli` or other AIs were used to author this trimmable-type-map Area: CoreCLR Issues that only occur when using CoreCLR. Area: NativeAOT Issues that only occur when using NativeAOT. labels Feb 14, 2026
@simonrozsival
Copy link
Member Author

Addressed all review feedback in this and downstream stacked PRs: applied null patterns (is null/is not null), string interpolation, and split TypeAttributeInfo into typed hierarchy (ActivityAttributeInfo, ServiceAttributeInfo, ApplicationAttributeInfo, etc). All comments can be marked resolved as the code has been updated accordingly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: CoreCLR Issues that only occur when using CoreCLR. Area: NativeAOT Issues that only occur when using NativeAOT. copilot `copilot-cli` or other AIs were used to author this trimmable-type-map

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant