Fix API warnings in macosx fragments #1111
Conversation
| <resource path="Eclipse SWT/cocoa/org/eclipse/swt/widgets/Composite.java" type="org.eclipse.swt.widgets.Composite"> | ||
| <filter id="576778288"> | ||
| <message_arguments> | ||
| <message_argument value="Scrollable"/> | ||
| <message_argument value="Composite"/> | ||
| </message_arguments> | ||
| </filter> | ||
| </resource> |
There was a problem hiding this comment.
I think APItools are too strict here.
For classes in the same bundle I think it makes sense to permit extending classes tagged with @noextend by default.
| @@ -51,19 +51,30 @@ public final class GCData { | |||
| public int fillRule = SWT.FILL_EVEN_ODD; | |||
| public Image image; | |||
|
|
|||
| /** @noreference This field is not intended to be referenced by clients. */ | |||
There was a problem hiding this comment.
This should IMHO also be implied by the @noreference of this class respectively public non-api types should not be an issue.
HannesWell
force-pushed
the
fix-mac-api-issues
branch
from
2a2635f
to
0696661
Compare
|
Looks like even with this approach we have to add filters, but they are about previously API fields having become non-API. |
HannesWell
force-pushed
the
fix-mac-api-issues
branch
from
0696661
to
2627870
Compare
For cocoa specific implementations of - o.e.swt.accessibility.Accessible tag methods already tagged as @noreference also with @nooverride so that API tools considers them as internal and does not complain about non-API types being referenced in their signature. - o.e.swt.graphics.GCData tag all fields as @noreference so that API tools does not complain about non-API types being used in public fields of this actually internal class (tagged as @noreference). Suppress issue about forbidden extension of Scrollable by Composite.
HannesWell
force-pushed
the
fix-mac-api-issues
branch
from
2627870
to
078581d
Compare
|
Thanks to @Phillipus who tested this PR on a real Mac and verified all API issues on Mac are really fixed with this: |
|
@HannesWell : beside the unneeded |
I used to get those warnings as well, but when I ensured the active workspace target and API-baseline target are properly resolved to one mac environment and the API-baseline is refreshed and after a clean+build they vanished. Furthermore I have currently also included this change in #1110 , where the build is configured to fail on API warnings and the build passes. |
I just double-checked with latest I-build and still no warnings or errors. |
|
@HannesWell Since 7479681 I am now getting errors for SWT such as |
|
I think you must use Eclipse SDK 4.32 IDE because. Also, I had problem with missing links to the api filters folder that @iloveeclipse helped me resolve. I ended up having to delete the projects from my workspace an importing them again.... |
Hmmm...tricky. Before now I could use the current version of the IDE (4.31) and import the SWT projects and simply ignore any warnings. Now each time I get the SWT projects I have to set these errors to warnings for the projects settings. |
|
yes, there was a problem that the API baseline details are missing from the 4.31 release of SWT so they are hard coded in PDE but of course only for 4.32. It's a tangled web we weave.... |
|
My setup is I have Eclipse 4.31 installed on 6 machines (different OS and architectures) and pull and test the latest SWT project commits and ignore any API warnings. What I don't want to do is also install yet another version of the IDE on 6 machines. ;-) I guess I'll have to keep my own copy of |
Strange. I did that and I no longer see the errors. False alarm? |
Indeed. For the next release cycle this will hopefully be stable again.
That's a large setup 😮
That's relatable. Making the warnings errors was meant to help developers to notice them early and not only in the CI that fails on API warnings since #1110. |
|
I think it was a one-off. I don't have an API baseline set so I shouldn't see the errors, right? |
It dependents on the kind of error. If it said something changed in a wrong way, then a missing baseline might be a problem (but actually without a baseline such issues are actually, falsely, not raised).
That exact issues should not depend on the baseline, but who knows what API-tools is doing in its inner-most core. 😅 |
For cocoa specific implementations of
o.e.swt.accessibility.Accessible tag methods already tagged as @noreference also with @nooverride so that API tools considers them as internal and does not complain about non-API types being referenced in their signature.
o.e.swt.graphics.GCData tag all fields as @noreference so that API tools does not complain about non-API types being used in public fields of this actually internal class (tagged as @noreference).
Suppress issue about forbidden extension of Scrollable by Composite.