Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Surface a warning at the declaration site for language incompatible [InlineArray] types #68867

Closed
tannergooding opened this issue Jul 3, 2023 · 0 comments · Fixed by #69144
Closed

Comments

@tannergooding
Copy link
Member

tannergooding commented Jul 3, 2023

Summary

The new [InlineArray] works for most, but not all, types. It also currently surfaces errors for some, but not all, "invalid" declarations.

For example, the compiler currently surfaces an error if you have more than 1 field:

[InlineArray(10)]
public struct S1 // CS9169: Inline array struct must declare one and only one instance field.
{
    public int _x;
    public int _y;
}

It does not surface any warning or error for the following code, however:

[InlineArray(10)]
public struct S2
{
    public int* _x;
}

[InlineArray(10)]
public ref struct S3
{
    public ref int _x;
}

Instead, an error is only surfaced when attempting to use language syntax with these types:

S2 s2 = default;
S3 s3 = default;

s2[0] = default; // CS0021: Cannot apply indexing with [] to an expression of type 'S1'
s3[0] = default; // CS0021: Cannot apply indexing with [] to an expression of type 'S1'

// For non-constant indexing, the compiler may also surface
//     CS0306: The type 'int*' may not be used as a type argument

Expected Behavior

Given that S2 and S3 are valid from the runtime perspective and only incompatible with the language support for InlineArray, the compiler should raise a warning that surfaces this incompatibility and that language syntax will not be available.

The developer can then make the decision to suppress the warning or to expose the support in a different manner. For example, the developer could desire still exposing the types "as is" and defining their own helper APIs to allow correct indexing. They could alternatively desire to expose this using some wrapper type or via a same sized alternative.

The following would then all be "valid" options for the user:

// Disable the warning
#pragma warning disable CS----
[InlineArray(10)]
public struct S2
{
    public int* _x;
}
#pragma warning restore CS----

// Use a wrapper type
public struct Pointer<T>
    where T : unmanaged
{
    T Value;
}

[InlineArray(10)]
public struct S2
{
    public Pointer<int> _x;
}

// Use a same sized primitive
[InlineArray(10)]
public struct S2
{
    public nuint _x;
}

Relates to test plan #67826

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels Jul 3, 2023
@jcouv jcouv added this to the C# 12.0 milestone Jul 3, 2023
@jcouv jcouv added Feature Request and removed untriaged Issues and PRs which have not yet been triaged by a lead labels Jul 5, 2023
AlekseyTs added a commit to AlekseyTs/roslyn that referenced this issue Jul 21, 2023
AlekseyTs added a commit that referenced this issue Jul 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants