Clarify Type.FullName and Type.AssemblyQualifiedName null return conditions

[Copilot]

Summary

The documentation incorrectly stated that Type.FullName and Type.AssemblyQualifiedName return null for array types and pointer types. Actual runtime behavior shows they return non-null values for these types:

var m = typeof(C).GetMethod("M")!;
foreach (var p in m.GetParameters())
{
    Console.WriteLine($"{p.Name}: {p.ParameterType.FullName}");
}

public class C
{
    public unsafe void M<T>(int* x, int[] y, T z) { }
}

// Output:
// x: System.Int32*      (not null, contrary to old docs)
// y: System.Int32[]     (not null, contrary to old docs)  
// z:                    (null, as expected for generic parameter)

Changes:

• Updated Type.FullName documentation to clarify it returns null when "the type can't be represented by a fully qualified name" - specifically for types with unresolved generic parameters (ContainsGenericParameters is true) and types containing function pointers
• Updated Type.AssemblyQualifiedName documentation with the same clarification
• Removed incorrect claims about array types and simple pointer types returning null
• Applied repository style guidelines: used contractions ("can't" instead of "cannot") for a conversational tone

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Type.FullName behavior diverges from documentation</issue_title>
<issue_description>### Description

https://learn.microsoft.com/en-us/dotnet/api/system.type.fullname?view=net-10.0

null if the current instance represents a generic type parameter, an array type, pointer type

using System;

var m = typeof(C).GetMethod("M")!;
foreach (var p in m.GetParameters())
{
    Console.WriteLine($"{p.Name}: {p.ParameterType.FullName}");
}

public class C
{
    public unsafe void M<T>(int* x, int[] y, T z) { }
}

This prints:

x: System.Int32*
y: System.Int32[]
z:

So it doesn't seem to be null for points and array types?

Reproduction Steps

See above.

Expected behavior

Implementation and docs are aligned.

Actual behavior

They are not aligned.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response</issue_description>

<agent_instructions>Implement suggestion from #12104 (comment) . Fix both Type.FullName and Type.AssemblyQualifiedName </agent_instructions>

Comments on the Issue (you are @copilot in this section)

@Youssef1313 Oh, I see. The bullet points makes it much clearer. This is a doc clarification request then. @jkotas This can return null for all sorts of custom types. How about this?

The fully qualified name of the type, including its namespace but not its assembly; or null if the type cannot be represented by a fully qualified name. Types that cannot be represented by a fully qualified name include types that contain unresolved generic parameters (Type.ContainsGenericParameters is true) and types that contain function pointers.</comment_new>

• Fixes Type.FullName behavior diverges from documentation #12104

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Copilot]

Pull request overview

This PR corrects the documentation for Type.FullName and Type.AssemblyQualifiedName to accurately reflect their runtime behavior regarding when they return null.

• Removes incorrect claims that these properties return null for array types and pointer types
• Updates documentation to clarify that null is returned when the type can't be represented by a fully qualified name, specifically for types with unresolved generic parameters (ContainsGenericParameters is true) and types containing function pointers
• Ensures both properties have consistent and accurate documentation