SWT Display class not marked as @noextend on MacOS

[HannesWell]

Describe the bug

The .api_description embedded in the o.e.swt.cocoa.macosx.aarch64|x86_64 artifacts lists the org.eclipse.swt.widgets.Display class, with <type name="Display" restrictions="0"> while for other platforms it is <type name="Display" restrictions="2">.

The attribute restrictions="2" represents the @noextend while restrictions="0" means no restriction:
https://github.com/eclipse-pde/eclipse.pde/blob/bc22b075c0a617d77ea261b77581e09bdae839aa/apitools/org.eclipse.pde.api.tools/src/org/eclipse/pde/api/tools/internal/provisional/RestrictionModifiers.java#L28-L36

Consequently this means that the Display class is effectively not restricted and not marked as @noextend at Mac OS, although it is actually marked as such like for all other platforms:

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/cocoa/org/eclipse/swt/widgets/Display.java

Line 105 in 8dc46be

* @noextend This class is not intended to be subclassed by clients.

I have checked the latest release 4.30 and the current I-build and in both the .api_description looks as described, so I assume this issue exists for longer. But it only seems to become visible at some occasions like #1011 (comment).

@Phillipus or @HeikoKlare can you verify on Mac that this error really manifests itself and is not just hypothetical? For example in a workspace that has SWT only in its TP can you create a class that extends Display and get a corresponding API problem?

[HeikoKlare]

can you verify on Mac that this error really manifests itself and is not just hypothetical? For example in a workspace that has SWT only in its TP can you create a class that extends Display and get a corresponding API problem?

I can confirm that: when extending Display from SWT provided via TP using latest I-Build, no error/warning shows up. When having SWT plugin and fragment in my workspace, extending Display results in a proper error/warning about the illegal extension.