2020-10-27 07:59:20 +03:00
|
|
|
# Copyright (c) Facebook, Inc. and its affiliates.
|
|
|
|
|
#
|
|
|
|
|
# This source code is licensed under the MIT license found in the
|
|
|
|
|
# LICENSE file in the root directory of this source tree.
|
|
|
|
|
|
|
|
|
|
load(
|
|
|
|
|
"//tools/build_defs/oss:rn_codegen_defs.bzl",
|
2021-04-15 23:25:16 +03:00
|
|
|
"rn_codegen",
|
2020-10-27 07:59:20 +03:00
|
|
|
)
|
|
|
|
|
|
2021-04-15 23:25:16 +03:00
|
|
|
rn_codegen(
|
2020-10-27 07:59:20 +03:00
|
|
|
name = "FBReactNativeSpec",
|
2020-12-30 00:01:55 +03:00
|
|
|
android_package_name = "com.facebook.fbreact.specs",
|
2021-04-15 23:25:16 +03:00
|
|
|
codegen_modules = True,
|
Add ios_assume_nonnull flag to react native codegen library (#31543)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31543
Changelog:
[iOS][Added] - Description
When compiling iOS apps with flag `-Wnullability-completeness` (like Lightspeed app and soon Instagram), Objective-C headers are required to either have full *explicit* nullability annotations on all members of its public API, or none at all; partially annotated headers will fail to build that module.
RN native modules are currently generated with *partial* annotations. This works today because most apps are not compiled with `-Wnullability-completeness` turned on. But when we flip the switch for Instagram, the app doesn't build due to importing these RN partially annotated modules.
JavsScript Flow types are implied nonnull, and the current RN codegen translates Flow's [maybe/optional](https://flow.org/en/docs/types/maybe/) type to Obj-C `_Nullable` annotation, and everything else without an explicit Obj-C annotation. However this creates a mismatch with the Obj-C type system, where the implied default is *unannotated*, which is handled differently from nonnull when built with the nullability compiler flags.
There is a simple Obj-C macro that automatically adds *explicit nonnull* annotations to all members in a header: `NS_ASSUME_NONNULL_BEGIN` / `NS_ASSUME_NONNULL_END`. If we add this to *all* RN-generated headers, however, we run into issues:
1) We may erroneously assume any previously-unannotated header was meant to be nonnull and cause future bugs
2) Another compiler flag (`-Wnullable-to-nonnull-conversion`) statically analyzes Obj-C implementation code to prevent us from ever passing null to one of these headers. Much existing Obj-C code will break here, and it's ambiguous if these are true or false positives because of the first point.
Instead, in this diff we add a new BUCK flag `ios_assume_nonnull` to let module authors opt into automatic nonnull for unannotated members so that Obj-C headers are generated correctly in alignment with Flow's type system. We can migrate all libraries individually as needed and eventually make this the RN native codegen default.
Reviewed By: RSNara
Differential Revision: D28396446
fbshipit-source-id: ad3a3a97ab19183df4ef504b1c3140596c8f69ca
2021-05-20 20:05:33 +03:00
|
|
|
ios_assume_nonnull = False,
|
2020-10-27 07:59:20 +03:00
|
|
|
library_labels = ["supermodule:xplat/default/public.react_native.infra"],
|
2021-04-15 23:25:16 +03:00
|
|
|
native_module_spec_name = "FBReactNativeSpec",
|
2020-10-27 07:59:20 +03:00
|
|
|
)
|
2020-12-09 20:16:41 +03:00
|
|
|
|
2021-04-15 23:25:16 +03:00
|
|
|
# TODO: Merge this into FBReactNativeSpec
|
|
|
|
|
rn_codegen(
|
2020-12-09 20:16:41 +03:00
|
|
|
name = "FBReactNativeComponentSpec",
|
2021-04-15 23:25:16 +03:00
|
|
|
codegen_components = True,
|
Add ios_assume_nonnull flag to react native codegen library (#31543)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31543
Changelog:
[iOS][Added] - Description
When compiling iOS apps with flag `-Wnullability-completeness` (like Lightspeed app and soon Instagram), Objective-C headers are required to either have full *explicit* nullability annotations on all members of its public API, or none at all; partially annotated headers will fail to build that module.
RN native modules are currently generated with *partial* annotations. This works today because most apps are not compiled with `-Wnullability-completeness` turned on. But when we flip the switch for Instagram, the app doesn't build due to importing these RN partially annotated modules.
JavsScript Flow types are implied nonnull, and the current RN codegen translates Flow's [maybe/optional](https://flow.org/en/docs/types/maybe/) type to Obj-C `_Nullable` annotation, and everything else without an explicit Obj-C annotation. However this creates a mismatch with the Obj-C type system, where the implied default is *unannotated*, which is handled differently from nonnull when built with the nullability compiler flags.
There is a simple Obj-C macro that automatically adds *explicit nonnull* annotations to all members in a header: `NS_ASSUME_NONNULL_BEGIN` / `NS_ASSUME_NONNULL_END`. If we add this to *all* RN-generated headers, however, we run into issues:
1) We may erroneously assume any previously-unannotated header was meant to be nonnull and cause future bugs
2) Another compiler flag (`-Wnullable-to-nonnull-conversion`) statically analyzes Obj-C implementation code to prevent us from ever passing null to one of these headers. Much existing Obj-C code will break here, and it's ambiguous if these are true or false positives because of the first point.
Instead, in this diff we add a new BUCK flag `ios_assume_nonnull` to let module authors opt into automatic nonnull for unannotated members so that Obj-C headers are generated correctly in alignment with Flow's type system. We can migrate all libraries individually as needed and eventually make this the RN native codegen default.
Reviewed By: RSNara
Differential Revision: D28396446
fbshipit-source-id: ad3a3a97ab19183df4ef504b1c3140596c8f69ca
2021-05-20 20:05:33 +03:00
|
|
|
ios_assume_nonnull = False,
|
2020-12-09 20:16:41 +03:00
|
|
|
library_labels = ["supermodule:xplat/default/public.react_native.infra"],
|
|
|
|
|
)
|
