-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
OS compatibility analyzer #37359
Comments
Checklist for all new requirements related to applying new design requirements. Related issue #39989
Update the semantics of these attributes as follows:
if (RuntimeInformation.IsPlatform(OSPlatform.Windows))
{
WindowsSpecificApi();
}
if (OperatingSystem.IsOSPlatform("windows"))
{
WindowsSpecificApi();
}
if (OperatingSystem.IsWindows())
{
WindowsSpecificApi();
}
if (OperatingSystem.IsWindowsVersionAtLeast(0))
{
WindowsSpecificApi();
}
// On Windows, the API was unsupported until version 10.0.19041.
// The API is considered supported everywhere else without constraints.
[UnsupportedOSPlatform("windows")]
[SupportedOSPlatform("windows10.0.19041")]
public extern void Api();
public void Api_Usage()
{
if (!OperatingSystem.IsWindows() ||
OperatingSystem.IsWindowsVersionAtLeast(10, 0, 19041))
{
Api();
}
}
|
@buyaa-n I suppose this is still for 5.0? If the change won't be cherry-picked into a release branch (which probably won't given that this is an analyzer) should we change the milestone? |
We just sent the email to seek approval to merge dotnet/roslyn-analyzers#3917 in for RC1. So hopefully we'll be able to close this very soon. 🤞 |
Yes it is for 5.0 and yes it will be merged into roslyn-analyzers repo, not runtime. The PR is about to be merged in the RC1 branch of that repo. |
The analyzer merged, closing |
OS compatibility analyzer
Based on design spec Annotating platform-specific APIs and detecting its use
Requirements
Goals
NoWarn
,#pragma
) will also work.Non-Goals
Expectations:
Guarding calls to platform-specific APIs
is approved and implemented issueRoslyn analyzer provide access to TFM and TargetPlatformMinVersionIt is now available in roslyn-analyzers, we can consume it as.editconfig
options.Diagnostic properties
Finding Diagnostics
The analyzer could start analyzing diagnostics for any method | event | property | enum invocation, check if they have annotated with any OSPlatformAttribute.
OSPlatformAttribute
that attribute applies to all members defined within the assembly/class. So if a member has no OS dependent attributes defined we will lookup for derived dependency from containing class or assembly level.OSPlatformAttribute
then the innermost member’s OS version would be counted for diagnostics, i.e if anyOSPlatformVersionAttribute
dependency found for a member we will not lookup for a derived dependencies from containing class or assembly.In general, the analyzer can produce three diagnostics:
MinimumOSPlatformAttribute
which haven't supppressed => warn with '{API}' requires {OS} {OS version} or later.* (Fixer could suggest for addingMinimumOSPlatformAttribute
or platform guardRuntimeInformation.IsOSPlatformOrLater(…)
)ObsoletedInOSPlatformVersionAttribute
which haven't supppressed => warn with '{API}' has been deprecated since {OS} {OS version}. (Fixer could suggest for addingObsoletedInOSPlatformVersionAttribute
or platform guarding methodRuntimeInformation. IsOSPlatformEarlierThan(…)
RemovedInOSPlatformVersionAttribute
which haven't supppressed => warn with '{API}' has been removed since {OS} {OS version}. (Fixer could suggest for addingRemovedInOSPlatformVersionAttribute
or platform guarding methodRuntimeInformation. IsOSPlatformEarlierThan(…)
)Detailed Scenarios for version check:
MinimumOSPlatformAttribute("Windows", 10, 1, 2, 3)
attribute and call site had guarded withMinimumOSPlatformAttribute("Windows", x, y, z, r)
thenObsoletedInOSPlatformVersion("Windows", 10, 1, 2, 3)
attribute and call site had guarded withObsoletedInOSPlatformVersion("Windows", x, y, z, r)
thenRemovedInOSPlatformVersion
attributeAutomatic suppression via Platform context or platform guard methods
Diagnostics can be suppressed by call site annotated with the same attribute with the correct version or a call to guard methods:
OSPlatformAttribute
to the containing member, type, module, or assembly related to the current diagnostic.if (1) call-site's containing method, type, module, or assembly's
OSPlatformVersionAttribute
type andosPlatform
string matches check the versions to determine if context suppresses the diagnostic.If (1) not suppressing the diagnostic, determine if the call-site is guarded by a platform check using flow analysis.
Sample: diagnostic suppressed by (2) a call to RuntimeInformation.IsOSPlatformOrLater(). This should work for simple cases where the call is contained inside an if check but also when the check causes control flow to never reach the call:
Diagnostics (2) and (3) are analogous except the guard is provided by RuntimeInformation.IsOSPlatformEarlierThan().
Code Fixers
All diagnostics can be suppressed by surround the call site using a platform guard. The fixer should offer surrounding the call with an
if
check using the appropriate platform-guard. It's not necessary that the end result compiles. It is the user's responsibility to adjust control flow and data flow to ensure variables are declared and initialized appropriately. The value that the fixer provides here is educational and avoids having to look up the correct version numbers.For diagnostic (1) we should also offer a fixer that allows it to be marked as platform-specific by applying
AddedInOSPlatformVersionAttribute
. If the attribute is already applied, it should offer to change the platform and version.The text was updated successfully, but these errors were encountered: