Runtime: Infra: Sync the sources of {ReadOnly}Memory and friends between corefx and corelib

[ahsonkhan]

I'd suggest someone compares the files in the two repos and gets them to be as close as possible. I noticed there are various discrepancies between them that make diff'ing harder, like differences in XML comments, differences in the ordering of members, etc.

Use ifdefs for small differences

From https://github.com/dotnet/coreclr/pull/14906#discussion_r149799699 (for context)

Also figure out and setup a source mirroring strategy between the two repos.

cc @stephentoub, @KrzysztofCwalina, @jkotas, @brianrob, @safern

[jkotas]

Also figure out and setup a source mirroring strategy between the two repos.

We may want to mirror the whole https://github.com/dotnet/coreclr/tree/master/src/mscorlib/shared with corefx.

[ahsonkhan]

We may want to mirror the whole https://github.com/dotnet/coreclr/tree/master/src/mscorlib/shared with corefx.

cc @ianhays

[tarekgh]

@jkotas

We may want to mirror the whole https://github.com/dotnet/coreclr/tree/master/src/mscorlib/shared with corefx.

Why do we need to mirror the whole folder? is it ok to have un-used files in corefx?
Actually, this will be easier in general but I am just wondering if this would be ok.

Note, we already have a mirroring between corefx and coreclr which doing System.Diagnostics.Tracing folder only.

[jkotas]

Why do we need to mirror the whole folder?

Simplicity. So that we do not have to manage mirroring of every little piece individually. We would switch System.Diagnostics.Tracing to use the whole folder mirror.

is it ok to have un-used files in corefx?

I think so, as long as it does not have major impact on the repo footprint:

• The CoreFX is 13,000 .cs files, 150 MB today.
• The shared CoreLib partition is 700 files, 6 MB today.

These number means that adding shared CoreLib partition to CoreFX is not going to increase the repo footprint significantly.

[jkotas]

Also, having shared CoreLib partition present in CoreFX would simplify things for Mono. They would not need to depend on CoreRT repo to get the shared CoreLib parts. It presents release logistic challenge for them today.

cc @marek-safar @luhenry

[tarekgh]

@jkotas looks reasonable mirroring the whole shared folder. do you think we can store it on the src root? I mean having corefx\src\Shared? or should we add a corelib level, something like corefx\src\corelib\shared?

cc @weshaggard

[jkotas]

My name pick would be corefx\src\System.Private.CoreLib\shared. I do not have a strong opinion on it.

[weshaggard]

I'm ok with sharing the entire folder. I would put it under corefx\src\Common\src\System.Private.CoreLib. We already use the Common folder for sharing between projects so I think that makes the most since.

[marek-safar]

It'd certainly help us to simplify synchronization of CoreFX sources for our releases. Right now there is no clear link between CoreFX and CoreRT and we go out of sync with shared files when we update CoreFX sources. This should also allow committing API changes to System.Runtime together with implementation in many cases.

[safern]

Mirror is running in between coreclr and corefx, here is the initial PR:

https://github.com/dotnet/corefx/pull/26311

[safern]

Just for reference, the PR to start the mirroring is: https://github.com/dotnet/corefx/pull/26314 because we decided to change the folder path in corefx.