Suppress warnings for taking address of TypedReference

[jcouv]

Relates to compiler change: dotnet/roslyn#66328
Tagging @AaronRobinsonMSFT to confirm those suppressions are okay.

[dotnet-issue-labeler]

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.

[stephentoub]

At some point soon we may want to just suppress 8500 for the whole repo, but for now doing it locally is good.

[AaronRobinsonMSFT]

At some point soon we may want to just suppress 8500 for the whole repo, but for now doing it locally is good.

Agreed. Do we think this is one of those warnings we want to permit when performed in an unsafe context? I can't recall all those details but we were discussing the idea of if you are in an unsafe context Roslyn is more permissive? Or was that around converting an error to warning - I don't recall all the details.

[stephentoub]

Or was that around converting an error to warning

Right. Previously this was an unsuppressable error. Now in an unsafe context it becomes a suppressable warning CS8500.

[ghost]

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

Issue Details

---

Relates to compiler change: dotnet/roslyn#66328
Tagging @AaronRobinsonMSFT to confirm those suppressions are okay.

Author:	jcouv
Assignees:	jcouv
Labels:	area-System.Runtime.CompilerServices
Milestone:	-

[danmoseley]

S.R.CS seems a resaonable label even though it's not?

[jcouv]

@stephentoub My understanding is that this is generally unsafe, but there are a few situations where it is okay. When it comes to compiler warnings, this is one that is stern :-P
In that light, having a local suppression seems beneficial to call reviewers' attention to something subtle. So I'm not sure that a repo-wide suppression is a good idea.

[stephentoub]

My understanding is that this is generally unsafe, but there are a few situations where it is okay.

What are some examples where the warning legitimately protects someone from a bad mistake? (That's a real question; I'm trying to understand how the problems this averts are significantly worse than many other things I can do with pointers in an unsafe context with zero warning.)

[jcouv]

how the problems this averts are significantly worse than many other things I can do with pointers in an unsafe context with zero warning

I see your point. This is not worse than other things you can do with pointers in unsafe context. A broader suppression would make sense.