runtime: Mark APIs as unsupported on Browser WASM

We can use UnsupportedOSPlatformAttribute("browser") attribute to mark unsupported APIs on Browser WASM so that the analyzer can provide warnings when developers accidentally call platform-specific APIs. Spec: https://github.com/dotnet/designs/pull/144

We use the scanner (https://github.com/dotnet/platform-compat) to gather the list of all the APIs throwing PNSE on Browser WASM at the moment. Below is the file containing ~4500 PNSE methods. pnse-17082020.txt

There can be some special cases:

  • APIs can be Windows-specific
  • APIs might throw PNSE for all platforms
  • APIs might not be considered to be marked (e.g. APIs are not meant to be directly called by user code)
  • other cases?

Namespaces (L# in file above)

cc @steveisok @lewing

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 15 (11 by maintainers)

Most upvoted comments

All the namespaces mentioned in this issue are covered so I’m closing it as completed

I see, in that case, the closest approximation would be to read System.Reflection.AssemblyFileVersionAttribute from the assembly.

It looks like the exception scanner doesn’t gather PNSEs thrown from runtime, e.g. something that uses mono_error_set_platform_not_supported method. At least, I don’t see appropriate APIs in the result file attached to the PR’s description. In case of Browser, an example of such API could be Thread.Start() which invokes StartInternal -> ves_icall_System_Threading_Thread_StartInternal -> mono_error_set_platform_not_supported .

Should we add the attribute to all the implementations in those cases?

This is what we have been doing so far.

I’ve been encountering similar stuff with https://github.com/dotnet/runtime/pull/41209, where we’re trying to get the runtime repo ready to receive the analyzer. We don’t yet have a solid strategy for this scenario.