Pointer is missing a nullability type specifier

[pho...@gmail.com]

All,

when compiling generated code in Xcode 8 directly in a swift-3 setup the compiler generates a ton of the following warnings:

"Pointer is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified)"

A ton being > 1000 for a 50 class project or so..

Anything we can do about this?

--
Michel

[Tom Ball]

Compile with the "-Wno-nullability-completeness" flag if you just want the warnings suppressed.

For your project's Java sources, you can define the correct nullability annotations and j2objc will translate them into Objective C annotations (be sure and include jsr305.jar to the j2objc classpath). This has the advantage of reducing the amount of casting that needs to be done when accessing Java classes in Swift. The Guava team recently did this, and simplified that effort by putting the default annotations in each package's package-info.java files (creating them, in many cases). That way, separate nullability annotations only needed to be added to individual source files when their API deviated from those defaults.

--
You received this message because you are subscribed to the Google Groups "j2objc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to j2objc-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pho...@gmail.com]

Thanks,

i had noticed the @Nullable @NonNull behaviour of the compiler and started using it... But haven't converted entire code base yet :)

[er...@pltech.co.nz]

https://github.com/google/j2objc/issues/683
I think this is still relevant, if you're looking at adding nullability and aren't looking to broadly suppress all nullability completeness warnings
as of swift 3, it also affects enum classes now (though I haven't tried it with j2objc 1.2 yet)

[pho...@gmail.com]

While updating my classes I also noticed Enum's cause the warnings (master)

[Antti]

Yep, enums cause these warnings too. Obviously a problem that should be sorted at j2objc side as there's nothing you can do about it, other than suppress them. I reverted back to 1.1 which works fine.

[Tom Ball]

I'd like to again recommend that Swift developers report what actual output they want to see in our generated header files. We don't use Swift much because a stable ABI for it was deferred again, because the Swift/Objective C inter-op guidelines aren't documented clearly, and because they regularly change with each iOS release. Until we have Swift developers giving us actionable feedback, we can't help this situation.

Even better would be if Swift engineers tweaked how those header files are generated, which is relatively easy since the com.google.devtools.j2objc.gen package basically just prints the final AST. This will likely break a number of translator tests, but those are even easier to fix -- just update the strings that are used to check generated headers. We'll take pull requests that improve Swift use pretty much on your say-so, as long as other apps aren't broken.

That said, I can't imagine that the JRE library call support nullability until Oracle ships a JDK that does. Disabling nullability-completeness warnings lets Swift projects use Java classes with nullability annotations to reduce casting, without clang reporting "tons of warnings."

On Mon, Nov 7, 2016 at 10:28 AM Antti <alam...@gmail.com> wrote:

Yep, enums cause these warnings too. Obviously a problem that should be sorted at j2objc side as there's nothing you can do about it, other than suppress them. I reverted back to 1.1 which works fine.

[er...@pltech.co.nz]

Tried the fix in source - it works for Nullable, but not for Nonnull. I posted an example, but I can't re-open the PR

[dan...@helabs.com.br]

Is there a way to annotate all Objective-C returns and parameters as Nullable ? I'm facing a problem, while migrating to Swift 3, that those are been “imported by Swift as an implicitly unwrapped optional" and the string interpolation show the word “Optional”. It’s really hard to find where in the code we are using a forced unwrapped string, while when it’s a optional string the Xcode shows warnings. I manually added a @Nullable to one method and it worked, but the code is too long to add it for everything.

Reference:
https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithObjective-CAPIs.html
https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md

[Tom Ball]

According to this write-up, all unannotated Objective C returns and parameters are by default "null unspecified", which suggests that there isn't an always-nullable option. We could possibly generate __nullable annotations everywhere that isn't explicitly __nonnull, but that would make a mess of generated headers with lots of complaints to follow. 

If you want to try hacking the translator yourself, download the project, change TypeGenerator.nullability(Element) to read something like:

  private String nullability(Element element) {

    if (options.nullability()) {

      return ElementUtil.isNonnull(element, parametersNonnullByDefault)) ? " __nonnull" : "__nullable";

    }

    return "";

  }

Then run "make -j4 dist" in the project's top directory and use its dist/j2objc to translator your sources. If you want to make a case for making this the standard output, please post a few of the longer method declarations to this group and see how the rest of the community reacts.

In Java, you can avoid annotating all parameters by specifying ParametersAreNonnullByDefault somewhere shared, such as a package-info.java file to mark the whole package. Annotation any parameters that are known to be nullable, then build with the error-prone plug-in or use FindBugs. If there are unannotated parameters that are passed null, then either they are actually nullable or you found a bug. Before annotating them as nullable, make sure the design warrants it, as nullable parameters should have special checking and handling.

The javax.annotation JSR-305 doesn't define any default annotations for fields or method returns. However, the asap-commons library does, and FindBugs will use them. If there is community interest, we can add support for them in the translator.