Backing field symbol for record with a primary constructor in a referenced project is missing

[kzu]

Version Used: Compiler version: '4.11.0-2.24304.1 (e68227e)'. Language version: 12.0

Steps to Reproduce:

1. Given a library that references another library
2. Both libraries have a record type with a primary constructor
3. A source generator running with a compilation from the main library, cannot access the backing field symbol for the referenced library record, but it can for the locally declared record.

This is inconsistent and prevents a generator to treat source symbols from local + referenced types uniformly.

I believe this to be the root cause of an issue with the Orleans serialization code generation for record types in referenced projects.

A minimal repro, with source-code provided, is ideal. Using sharplab is preferred for compiler/language issues whenever possible.

Full repro: https://github.com/kzu/BackingFieldRecordSymbolMissing

The repro contains an analyzer project with the two libraries, which can be directly run with F5 to see the problem.
The output of the generator is a diff of the members accessible by using symbol.GetMembers() on both symbols, which looks like the following and showcases the missing backing field:

// Local                                   External
// --------------------------------------------------------------------------------
// .ctor                                   .ctor
// .ctor                                   .ctor
// <Amount>k__BackingField                 
// <Clone>$                                <Clone>$
// Amount                                  Amount
// Deconstruct                             Deconstruct
// EqualityContract                        EqualityContract
// Equals                                  Equals
// Equals                                  Equals
// get_Amount                              get_Amount
// get_EqualityContract                    get_EqualityContract
// GetHashCode                             GetHashCode
// op_Equality                             op_Equality
// op_Inequality                           op_Inequality
// PrintMembers                            PrintMembers
// set_Amount                              set_Amount
// ToString                                ToString

Expected Behavior: whether the symbol is locally defined or via metadata reference, the same backing fields should be available.

Actual Behavior: only the local records contain the backing fields.

NOTES:

1. Setting <ProduceReferenceAssembly>false</ProduceReferenceAssembly> in the referenced project, AND <CompileUsingReferenceAssemblies>false</CompileUsingReferenceAssemblies> on the consuming one, still doesn't produce the right list of symbols. See kzu/BackingFieldRecordSymbolMissing@a2f9b6c

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[CyrusNajmabadi]

This is inconsistent and prevents a generator to treat source symbols from local + referenced types uniformly.

This is not a thing in Roslyn. Metadata may contain different data. For example, it may not include private information.

[kzu]

I'm talking about how Orleans does codegen and does not distinguish in its generator records locally defined from referenced, since all it needs is access the field types and names. You're saying it's by design that that info isn't available and this is not a bug? (just clarifying so I plan accordingly a workaround, rather than expect a fix :)).

BTW, I do see your point since the metadata reference can definitely be a non-C#-compiled assembly and thus contain different things for an INamedTypeSymbol. But being (as shown in the repro) both C# compiled projects even within the same solution, I would expect the INamedTypeSymbol exposed for both types to be pretty much identical.

[CyrusNajmabadi]

You're saying it's by design that that info isn't available and this is not a bug?

Yes.

I would expect the INamedTypeSymbol exposed for both types to be pretty much identical.

This is not a Roslyn guarantee. Add I mentioned, we may literally not load things like private members as they have no impact on the language's view of the world.

[kzu]

Gotcha. Thanks for the explanation and the quick reply 💯