Remove no-op SR.Format calls with single message argument

[Copilot]

Description

SR.Format(SR.SomeMessage) with no format arguments is a no-op. This PR removes the unnecessary wrapper, replacing it with just SR.SomeMessage.

All touched resource strings were verified to not contain format placeholders like {0}. One resource string (ComplexTypeRestrictionNotSupported) was found to have a redundant {0} placeholder that was never being filled - this was a pre-existing bug that would throw FormatException if reached. The {0} was removed from the resource string and the message simplified to "Complex type restriction is not supported."

Files changed

• System.Data.OleDb - OleDb_Util.cs (16)
• System.Security.Cryptography.Cose - CoseHeaderValue.cs (4)
• System.Private.CoreLib - GC.CoreCLR.cs, GC.NativeAot.cs (4)
• System.Private.DataContractSerialization - DataContractSet.cs, ExtensionDataReader.cs, SchemaImporter.cs, Strings.resx (32)
• System.Text.Json - ThrowHelper.cs, ThrowHelper.Serialization.cs (7)
• System.Formats.Tar - TarHelpers.cs, TarHeader.Read.cs, GnuTarEntry.Tests.cs (4)

Example

// Before
throw new InvalidOperationException(SR.Format(SR.SomeErrorMessage));

// After
throw new InvalidOperationException(SR.SomeErrorMessage);

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Copilot]

Pull request overview

This PR removes unnecessary SR.Format() wrapper calls when there are no format arguments, simplifying error message construction across multiple libraries. The change improves code clarity and removes no-op function calls.

Changes:

• Removed 67 instances of SR.Format(SR.SomeMessage) calls with no format arguments, replacing them with direct SR.SomeMessage references
• Changes span 10 files across 6 different libraries/components
• All changes are mechanical refactorings that preserve exact behavior

Reviewed changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/libraries/System.Text.Json/src/System/Text/Json/ThrowHelper.cs	Removed 4 no-op SR.Format calls in exception message handling
src/libraries/System.Text.Json/src/System/Text/Json/ThrowHelper.Serialization.cs	Removed 3 no-op SR.Format calls in serialization exception handling
src/libraries/System.Security.Cryptography.Cose/src/System/Security/Cryptography/Cose/CoseHeaderValue.cs	Removed 4 identical no-op SR.Format calls in header value parsing methods
src/libraries/System.Private.DataContractSerialization/src/System/Runtime/Serialization/SchemaImporter.cs	Removed 32 no-op SR.Format calls in schema import error handling
src/libraries/System.Private.DataContractSerialization/src/System/Runtime/Serialization/ExtensionDataReader.cs	Removed 1 no-op SR.Format call in deserialization error handling
src/libraries/System.Private.DataContractSerialization/src/System/Runtime/Serialization/DataContractSet.cs	Removed 2 no-op SR.Format calls in validation error handling
src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarHelpers.cs	Removed 1 no-op SR.Format call in number parsing error handling
src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarHeader.Read.cs	Removed 2 no-op SR.Format calls in TAR header parsing errors
src/libraries/System.Formats.Tar/tests/TarEntry/GnuTarEntry.Tests.cs	Removed 1 no-op SR.Format call in test code
src/libraries/System.Data.OleDb/src/OleDb_Util.cs	Removed 16 no-op SR.Format calls in OleDb exception factory methods
src/coreclr/System.Private.CoreLib/src/System/GC.CoreCLR.cs	Removed 2 no-op SR.Format calls in GC NoGCRegion error handling
src/coreclr/nativeaot/System.Private.CoreLib/src/System/GC.NativeAot.cs	Removed 2 no-op SR.Format calls in GC NoGCRegion error handling (NativeAOT variant)

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

[jkotas]

@copilot Could you please check that the error messages touched in this PR do not contain formatting sequences like {0}? Go through all error messages touched in this change and verify it for each of them.

[Copilot]

@copilot Could you please check that the error messages touched in this PR do not contain formatting sequences like {0}? Go through all error messages touched in this change and verify it for each o...

Verified all 66 touched error messages for formatting sequences. Found one issue: ComplexTypeRestrictionNotSupported contains {0} in its value. I've restored the SR.Format call for this one in commit 72fcfd8.

All other messages were confirmed to have no format placeholders:

• System.Data.OleDb: 16 messages - none with placeholders ✓
• System.Security.Cryptography.Cose: 1 message - no placeholders ✓
• System.Private.CoreLib: 2 messages - no placeholders ✓
• System.Text.Json: 7 messages - no placeholders ✓
• System.Formats.Tar: 3 messages - no placeholders ✓
• System.Private.DataContractSerialization: 27 messages - no placeholders ✓ (1 with placeholder was restored)

[stephentoub]

@copilot is that code path with the {0} in the message reachable? Do we have any tests hitting it? Such a call will typically throw an exception due to having a hole for an argument without one to fill it.

[Copilot]

@copilot is that code path with the {0} in the message reachable? Do we have any tests hitting it? Such a call will typically throw an exception due to having a hole for an argument without one to fil...

The code path is reachable when importing an XSD complex type with a content restriction that doesn't extend anyType. However, I found no tests exercising this path.

You're correct that SR.Format(SR.ComplexTypeRestrictionNotSupported) without arguments would throw a FormatException at runtime - this is a pre-existing bug.

Looking at the resource strings, the {0} in ComplexTypeRestrictionNotSupported appears to be redundant anyway - the namespace is already included by the outer TypeCannotBeImported wrapper message which formats it as "Type '{0}' in namespace '{1}' cannot be imported. {2}".

Should I fix this by removing the {0} from the resource string (making my original change correct), or should I leave this for a separate fix?

[jkotas]

@copilot Remove the {0} from the resource string

[Copilot]

@copilot Remove the {0} from the resource string

Done in 21482ad9. Removed the {0} from the resource string (simplified to "Complex type restriction is not supported.") and removed the SR.Format wrapper from the code.