Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Mark APIs as unsupported on Browser WASM #41087

Closed
71 tasks done
MaximLipnin opened this issue Aug 20, 2020 · 15 comments
Closed
71 tasks done

Mark APIs as unsupported on Browser WASM #41087

MaximLipnin opened this issue Aug 20, 2020 · 15 comments
Labels
arch-wasm WebAssembly architecture area-Infrastructure-libraries
Milestone
6.0.0

Comments

@MaximLipnin
Copy link
Contributor

MaximLipnin commented Aug 20, 2020 •
edited by mdh1418
Loading

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: dotnet/designs#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
@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Aug 20, 2020
@Dotnet-GitSync-Bot
Copy link
Collaborator

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@MaximLipnin MaximLipnin added the arch-wasm WebAssembly architecture label Aug 20, 2020
This was referenced Aug 20, 2020
Merged
Merged
Closed
@MaximLipnin MaximLipnin removed the untriaged New issue has not been triaged by the area owner label Aug 20, 2020
@mdh1418 mdh1418 mentioned this issue Aug 20, 2020
Merged
@MaximLipnin MaximLipnin mentioned this issue Aug 21, 2020
Closed
@ghost
Copy link

ghost commented Aug 21, 2020

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

@CoffeeFlux
Copy link
Contributor

area-VM-meta-mono seems like the wrong area for this since it's purely libraries, but I'm not sure what to use for something that applies to libraries as a whole. area-Meta also seems wrong...

@steveisok steveisok added this to the 6.0.0 milestone Aug 21, 2020
This was referenced Aug 21, 2020
Merged
Closed
@ghost
Copy link

ghost commented Aug 24, 2020

Tagging subscribers to this area: @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

@mdh1418 mdh1418 mentioned this issue Aug 24, 2020
Merged
@akoeplinger
Copy link
Member

@jeffhandley @adamsitnik while adding the [UnsupportedOSPlatform] attributes to the src a question came up what to do when the method we're annotating has multiple implementations (e.g. .Browser.cs, .Unix.cs and .Windows.cs).

Should we add the attribute to all the implementations in those cases? If we don't do that then regenerating the ref would remove the attribute if you're on a different platform.

@jeffhandley
Copy link
Member

I've been encountering similar stuff with #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.

@adamsitnik
Copy link
Member

adamsitnik commented Aug 25, 2020 •
edited
Loading

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

This is what we have been doing so far.

This was referenced Aug 25, 2020
Closed
Closed
Closed
@jeffhandley
Copy link
Member

We have now filed #41354 against the runtime repo to resolve the issues there for RC2.

This was referenced Sep 1, 2020
Merged
Merged
Merged
Merged
This was referenced Sep 4, 2020
Closed
Closed
Merged
Closed
@MaximLipnin MaximLipnin mentioned this issue Sep 8, 2020
Merged
This was referenced Sep 8, 2020
Merged
Closed
Merged
Merged
Closed
This was referenced Sep 9, 2020
Merged
Merged
Merged
@MaximLipnin
Copy link
Contributor Author

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 .

@jeffhandley jeffhandley mentioned this issue Sep 16, 2020
Closed
3 tasks
@MaximLipnin MaximLipnin mentioned this issue Sep 17, 2020
Merged
@buyaa-n buyaa-n mentioned this issue Sep 21, 2020
Closed
@sigmarsson
Copy link

Hi Seniors, Is there an alternative way to retrieve assembly version info on Wasm instead of FileVersionInfo ?
That is not supported any more in the browser.

unoplatform/uno#5916

@marek-safar
Copy link
Contributor

@sigmarsson what about using RuntimeEnvironment.GetSystemVersion () ?

@sigmarsson
Copy link

@marek-safar i wish to retrieve either the calling or the executing assembly version.

@sigmarsson
Copy link

E.g.

image

@marek-safar
Copy link
Contributor

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

@MaximLipnin
Copy link
Contributor Author

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

@ghost ghost locked as resolved and limited conversation to collaborators Jun 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
arch-wasm WebAssembly architecture area-Infrastructure-libraries
Projects
None yet
Milestone
6.0.0
Development

No branches or pull requests
10 participants
@marek-safar @steveisok @jeffhandley @akoeplinger @CoffeeFlux @MaximLipnin @adamsitnik @jeffschwMSFT @sigmarsson @Dotnet-GitSync-Bot