Mark applicable structs as readonly #14789

stephentoub · 2017-11-01T13:54:40Z

In a few known "why wasn't this annotated" cases (e.g. nullable), I added readonly to fields in order to allow readonly on the type.

Contributes to https://github.com/dotnet/corefx/issues/24900

cc: @jaredpar, @VSadov, @jkotas

jkotas

We should make sure that the corefx contract consistency check start verifying the readonly annotations (if they are not doing it already). The contracts have to stay in sync with the implementation.

jkotas · 2017-11-01T14:46:15Z

src/mscorlib/shared/System/Diagnostics/Tracing/TraceLogging/EmptyStruct.cs

    /// TraceLogging: Empty struct indicating no payload data.
    /// </summary>
-    internal struct EmptyStruct
+    internal readonly struct EmptyStruct


@brianrob Are you ok with marking these as readonly - will it cause issues with source sharing?

This is also in the same boat as the other "empty" structs below. I'm fine keeping the changes for these and fine getting rid of them.

jkotas · 2017-11-01T14:48:33Z

src/mscorlib/shared/System/Void.cs

 {
    // This class represents the void return type
-    public struct Void
+    public readonly struct Void


You can mark this readonly, but it has zero value here - just adds extra bytes to the binary. The marking on this type looks a bit odd to me.

I am wondering what the rule should be: mark structs as read only because of it makes senses (it would be my preference), or just because of we can?

Yeah, I went back and forth on that. There are a few types like this in a PR I'm about to put up in corefx as well. I could go either way.

Perhaps mark like public /* readonly */ struct Void so it's clear it was intentionally skipped.

Perhaps mark like public /* readonly */ struct Void so it's clear it was intentionally skipped.

Ok, I'll do that for internal types and leave public types annotated. Seems like a reasonable place to land.

EDIT: Actually, I'll just remove them from these no-member types. We can always add them later if desired.

jkotas · 2017-11-01T14:48:44Z

src/mscorlib/src/Internal/Padding.cs

    /// <summary>Padding structure used to minimize false sharing</summary>
    [StructLayout(LayoutKind.Explicit, Size = PaddingHelpers.CACHE_LINE_SIZE - sizeof(int))]
-    internal struct PaddingFor32
+    internal readonly struct PaddingFor32


jkotas · 2017-11-01T14:52:05Z

src/mscorlib/shared/System/DateTime.cs

    [Serializable]
    [System.Runtime.CompilerServices.TypeForwardedFrom("mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089")] 
-    public partial struct DateTime : IComparable, IFormattable, IConvertible, IComparable<DateTime>, IEquatable<DateTime>, ISerializable
+    public readonly partial struct DateTime : IComparable, IFormattable, IConvertible, IComparable<DateTime>, IEquatable<DateTime>, ISerializable


I see that you were not able to mark DateTimeOffset because of its internal implementation detail around binary serialization. It is pretty unfortunate. I am wondering whether the DateTimeOffset case would warrant using the Unsafe helper to cast away the readonly-liness, so that DateTimeOffset can be marked as well.

Exactly. I started looking at fixing it, but decided to keep this PR just focused on the easy cases where implementation changes weren't necessary. There are probably also additional structs that could be made readonly if their fields were appropriately annotated; I only looked at / fixed a few in that category (e.g. DateTime, Nullable), but didn't do a full sweep looking for others; that can be done subsequently, either piecemeal or with an analyzer.

DateTimeOffset #19552

jkotas · 2017-11-01T15:00:48Z

KeyValuePair is a good candidate to annotate.

jkotas · 2017-11-01T15:04:37Z

@dotnet-bot test Windows_NT x64 corefx_baseline

stephentoub · 2017-11-01T15:34:46Z

We should make sure that the corefx contract consistency check start verifying the readonly annotations (if they are not doing it already). The contracts have to stay in sync with the implementation.

I don't believe they do yet. And in my corefx change, I went through and manually propagated the visible changes to the refs.
cc: @weshaggard, @ericstj

KeyValuePair is a good candidate to annotate.

Another case where the fields aren't currently annotated as readonly, so I didn't pick it up. I'll fix that one here, but others can be done subsequently.

In a few cases (e.g. nullable), I added readonly to fields in order to allow readonly on the type.

stephentoub · 2017-11-02T20:00:30Z

@dotnet-bot test Windows_NT x64 full_opt ryujit CoreCLR Perf Tests Correctness please
@dotnet-bot test Windows_NT x86 full_opt ryujit CoreCLR Perf Tests Correctness please

stephentoub · 2017-11-02T21:14:06Z

@jkotas, should these CoreCLR Perf Tests Correctness legs be working? The details links just come back as 404s.

weshaggard · 2017-11-02T21:40:38Z

I don't believe they do yet. And in my corefx change, I went through and manually propagated the visible changes to the refs.

I don't think we are currently. It should be easy enough to add for anyone that wants to verify it. The code lives in Microsoft.Cci.Extensions in Buildtools.

jkotas · 2017-11-02T22:43:17Z

@adiaaida I see you have pending PR to change perf related legs. Are the perf test correctness failures known issue?

jkotas · 2017-11-02T22:44:16Z

It should be easy enough to add for anyone that wants to verify it. The code lives in Microsoft.Cci.Extensions in Buildtools.

We need tracking issue for this at least. It needs to be done before we ship 2.1 to ensure consistency.

jkotas

LGTM

michellemcdaniel · 2017-11-02T23:27:48Z

I can't see the failure because I removed the jobs with my last change. I'll re-run the Perf Build and Test runs, which should tell us if this change will break the perf testing.

@dotnet-bot test Perf Build and Test please

VSadov

LGTM
Nice change!!!

stephentoub · 2017-11-03T04:12:47Z

@adiaaida, how long is that perf build and test leg expected to take? It's been running for almost 5 hours. Similarly in the PR at #14836.

jkotas · 2017-11-03T11:44:39Z

We should not block on the Perf Build and Test

In a few cases (e.g. nullable), I added readonly to fields in order to allow readonly on the type. Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>

jkotas · 2017-11-03T11:59:38Z

It should be easy enough to add for anyone that wants to verify it. The code lives in Microsoft.Cci.Extensions in Buildtools.

We need tracking issue for this at least. It needs to be done before we ship 2.1 to ensure consistency.

Opened https://github.com/dotnet/corefx/issues/25039 on this

In a few cases (e.g. nullable), I added readonly to fields in order to allow readonly on the type. Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>

In a few cases (e.g. nullable), I added readonly to fields in order to allow readonly on the type.

In a few cases (e.g. nullable), I added readonly to fields in order to allow readonly on the type. Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>

weshaggard · 2018-01-05T01:14:29Z

src/mscorlib/shared/System/Collections/Generic/KeyValuePair.cs

    [Serializable]
    [System.Runtime.CompilerServices.TypeForwardedFrom("mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089")]
-    public struct KeyValuePair<TKey, TValue>
+    public readonly struct KeyValuePair<TKey, TValue>


I'm working on the APICompat checks work but I'm not sure if this a compatible change. @jkotas @stephentoub is this an API compatible change?

Marking struct as readonly should be compatible change. The other direction (removing readonly on a struct) is not a compatible change.

cc @VSadov

Yes this is a compatible change.

In a few cases (e.g. nullable), I added readonly to fields in order to allow readonly on the type. Signed-off-by: dotnet-bot-corefx-mirror <dotnet-bot@microsoft.com>

jkotas reviewed Nov 1, 2017

View reviewed changes

This was referenced Nov 1, 2017

Mark applicable structs as readonly dotnet/corefx#24997

Merged

Port non-shared readonly changes from coreclr dotnet/corert#4855

Merged

Mark applicable structs as readonly

834d439

In a few cases (e.g. nullable), I added readonly to fields in order to allow readonly on the type.

stephentoub force-pushed the readonly_structs branch from 356e306 to 834d439 Compare November 2, 2017 15:00

jkotas approved these changes Nov 2, 2017

View reviewed changes

VSadov approved these changes Nov 2, 2017

View reviewed changes

jkotas merged commit 278c8f3 into dotnet:master Nov 3, 2017

stephentoub deleted the readonly_structs branch November 3, 2017 13:51

nategraf pushed a commit to nategraf/coreclr that referenced this pull request Nov 7, 2017

Mark applicable structs as readonly (dotnet#14789)

9cd8b31

In a few cases (e.g. nullable), I added readonly to fields in order to allow readonly on the type.

weshaggard reviewed Jan 5, 2018

View reviewed changes

benaadams mentioned this pull request Feb 4, 2018

Mark readonly structs as such dotnet/extensions#311

Merged

jkotas mentioned this pull request Jan 31, 2020

Add validation of contract/implementation consistency for readonly structs, parameters and returns dotnet/runtime#24040

Closed

jkotas mentioned this pull request Jul 6, 2020

Update void struct to readonly struct dotnet/runtime#38796

Closed

xtqqczze mentioned this pull request Oct 29, 2020

Mark applicable structs as readonly and use in-modifier PowerShell/PowerShell#13919

Merged

Mark applicable structs as readonly #14789

Mark applicable structs as readonly #14789

Uh oh!

Conversation

stephentoub commented Nov 1, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jkotas left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkotas Nov 1, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stephentoub Nov 2, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkotas commented Nov 1, 2017

Uh oh!

jkotas commented Nov 1, 2017

Uh oh!

stephentoub commented Nov 1, 2017

Uh oh!

stephentoub commented Nov 2, 2017

Uh oh!

stephentoub commented Nov 2, 2017

Uh oh!

weshaggard commented Nov 2, 2017

Uh oh!

jkotas commented Nov 2, 2017

Uh oh!

jkotas commented Nov 2, 2017

Uh oh!

jkotas left a comment

Choose a reason for hiding this comment

Uh oh!

michellemcdaniel commented Nov 2, 2017

Uh oh!

VSadov left a comment

Choose a reason for hiding this comment

Uh oh!

stephentoub commented Nov 3, 2017

Uh oh!

jkotas commented Nov 3, 2017

Uh oh!

jkotas commented Nov 3, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

stephentoub commented Nov 1, 2017 •

edited

Loading

jkotas left a comment •

edited

Loading

jkotas Nov 1, 2017 •

edited

Loading

stephentoub Nov 2, 2017 •

edited

Loading

jkotas commented Nov 3, 2017 •

edited

Loading