Annotate methods that get MethodBase from a stackwalk as RUC#59851
Conversation
Fixes dotnet#53242. Saddened this didn't make .NET 6.0. Stack traces in trimmed apps look ugly without this fix: ``` Unhandled exception. System.ArgumentNullException: Value cannot be null. (Parameter 'id') at System.TimeZoneInfo.ValidateTimeZoneInfo(String , TimeSpan , AdjustmentRule[] , Boolean& ) at System.TimeZoneInfo..ctor(String , TimeSpan , String , String , String , AdjustmentRule[] , Boolean , Boolean ) at System.TimeZoneInfo.CreateCustomTimeZone(String , TimeSpan , String , String ) at Program.<Main>$(String[] args) in C:\stacktrace\Program.cs:line 3 ```
ghost
added
area-AssemblyLoader-coreclr
|
Note regarding the This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change. |
|
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov Issue DetailsFixes #53242. Saddened this didn't make .NET 6.0. Stack traces in trimmed apps look ugly without this fix:
|
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
| sb.Append(typeName); | ||
| sb.Append(' '); | ||
| sb.Append(pi[j].Name); | ||
| string? parameterName = pi[j].Name; |
There was a problem hiding this comment.
Possible future improvement: I vaguely remember discussing this: Would it make sense to add RUC onto the ParameterInfo.Name? I know it can be null even without trimming, but it is an observable difference with trimming.
There was a problem hiding this comment.
ILLink will not strip parameter names from things that are visible targets of reflection. By adding RUC on all APIs that get MethodBase from a stack walk, we cover all scenarios where stripping parameter names could be an observable difference (it's the API that lets you get hold of a broken MethodBase in the first place).
Since there will be a warning on getting the MethodBase, we don't need another warning on Name.
This sets us also up to do attribute stripping correctly, similar to how we strip the parameter names: https://github.com/dotnet/linker/issues/2078 - we can remove known "useless" custom attributes from methods/fields that are not visible targets of reflection for the same reason it's safe to strip parameter names and it will not cause any warningless runtime behavior differences.
4 participants
Fixes #53242. Saddened this didn't make .NET 6.0.
Stack traces in trimmed apps look ugly without this fix: