-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Mono: Replace exception strings with those stored in the resx file (#34056) #78341
Conversation
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
/cc @lambdageek @vargaz |
Looks ok to me. |
src/mono/System.Private.CoreLib/src/System/Reflection/Emit/DerivedTypes.Mono.cs
Outdated
Show resolved
Hide resolved
Fixed 2nd parameter for argumentExceptions
Can we switch all of the |
src/mono/System.Private.CoreLib/src/System/Reflection/Emit/DerivedTypes.Mono.cs
Outdated
Show resolved
Hide resolved
Is this just in the path: |
Yeah only within your change. |
string.format -> SR.Format
src/mono/System.Private.CoreLib/src/System/Reflection/Emit/AssemblyBuilder.Mono.cs
Outdated
Show resolved
Hide resolved
src/mono/System.Private.CoreLib/src/System/Reflection/Emit/MethodBuilder.Mono.cs
Outdated
Show resolved
Hide resolved
src/mono/System.Private.CoreLib/src/System/Reflection/Emit/MethodBuilder.Mono.cs
Outdated
Show resolved
Hide resolved
src/mono/System.Private.CoreLib/src/System/Reflection/RuntimeFieldInfo.cs
Outdated
Show resolved
Hide resolved
src/mono/System.Private.CoreLib/src/System/Reflection/RuntimeModule.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There seems to be a lot of opportunities in de-duplicating the new error strings with the existing error strings. I have commented on some, but there is certainly more.
The easy way to do the deduplication is to build a small program that hits the error path, run it on CoreCLR and see what error it produces in that case.
src/libraries/System.Private.CoreLib/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
src/mono/System.Private.CoreLib/src/System/RuntimeTypeHandle.cs
Outdated
Show resolved
Hide resolved
src/mono/System.Private.CoreLib/src/System/Reflection/Emit/TypeBuilder.Mono.cs
Outdated
Show resolved
Hide resolved
src/mono/System.Private.CoreLib/src/System/Reflection/Emit/TypeBuilderInstantiation.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
src/mono/System.Private.CoreLib/src/System/Reflection/RuntimeMethodInfo.Mono.cs
Outdated
Show resolved
Hide resolved
src/mono/System.Private.CoreLib/src/System/Reflection/RuntimeFieldInfo.cs
Outdated
Show resolved
Hide resolved
Would a way to do it be like: have a script which iterates through all of the exception strings in the .resx file If true dont remove, else remove?? and ill make a backup just in case then run the build see if theres any missing references |
I do not think you can script it. The error messages are not exactly the same. You need to be looking for same meaning that can be only done by humans (or AI). |
ok thanks ill look into it |
src/mono/System.Private.CoreLib/src/System/TypeLoadException.Mono.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
Not related to this change, but I see some ApplicationException and base Exception getting thrown, which we generally don't throw, does CLR throw the same in these cases? |
No, we should clean those up at some point. You'd expect the same exception being thrown, regardless of runtime implementation. |
Regarding the CLA, it looks like some issue with the new CLA system since it was signed in the old system according to #78341 (comment) and the status on one of the earlier commits: I'll try to find someone who can look into that. |
Co-authored-by: Dan Moseley <danmose@microsoft.com>
src/libraries/System.Private.CoreLib/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
Co-authored-by: Dan Moseley <danmose@microsoft.com>
@databunks
Edit: we were able to update the new system instead so this is handled now. |
src/libraries/System.Private.CoreLib/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
# Conflicts: # src/mono/System.Private.CoreLib/src/Mono/RuntimeMarshal.cs
@@ -24,7 +24,7 @@ public static FieldInfo GetFieldFromHandle(RuntimeFieldHandle handle, RuntimeTyp | |||
throw new ArgumentException(SR.Argument_InvalidHandle); | |||
FieldInfo fi = internal_from_handle_type(handle.Value, declaringType.Value); | |||
if (fi == null) | |||
throw new ArgumentException("The field handle and the type handle are incompatible."); | |||
throw new ArgumentException(SR.Argument_FieldPropertyEventAndTypeHandleIncompatibility); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be Argument_ResolveFieldHandle
like in CoreCLR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Theoretically yes but I don't have the type(s) to fill in the format string and RuntimeFieldHandle.GetApproxDeclaringType
is only implemented in CoreCLR.
I'd rather keep this as is for now so we can finally get this PR in.
Fixes #34056