When both prebuilt and source versions of a module are present in the
build an implicit dependency is added from source -> prebuilt. This
change excludes that dependency from visibility enforcement as it
provides no value and would otherwise require an sdk snapshot to
rewrite the visibility of the generated prebuilt modules which would
be complicated.
The rewriting would include:
* Detecting //visibility:public and just passing that straight through.
* Detecting //visibility:private and replacing that with the location
of the source.
* Otherwise, adding the location of the source to the visibility
property.
This adds a general mechanism to allow any dependency to be excluded
from visibility enforcement by simply using a tag that implements
the ExcludeFromVisibilityEnforcementTag interface.
Bug: 142940300
Test: m nothing
Change-Id: I0668ff5aa798152d17faf3aac1bb8eff8d6350c3
Exports visibility and package mutator registration functions so they
can be used in sdk testing. Updates sdk test to support visibility and
package modules.
Adds EffectiveVisibility(...)[]string function to make the effective
visibility rules available to sdk snapshot creation.
Extracts compositeRule.Strings() []string from compositeRule.String()
method so that it can be used by above func.
Adds visibility property to sdk snapshot and prebuilt modules along
with a test to ensure it works properly.
Adds dir parameter to CheckSnapshot so that it can check the snapshot
generated for a non-root package. That is required in order to ensure
that visibility of :__subpackages__ on a source module in package
<pkg> is resolved to an effective visibility of
//<pkg>:__subpackages__ on its corresponding prebuilt.
Test: m conscrypt-module-sdk
Bug: 143678475
Change-Id: Icaacac5b9c04726d28e6fec93e49715ac45df7f4
Existing modules, either general one or package ones have a single
visibility property, called visibility in general, and
default_visibility on package, that controls access to that module, or
in the case of package sets the default visibility of all modules in
that package. The property is checked and gathered during the similarly
named phases of visibility processing.
The defaults module will be different as it will have two properties.
The first, visibility, will not affect the visibility of the module, it
only affects the visibility of modules that 'extend' the defaults. So,
it will need checking but not parsing. The second property,
defaults_visibility, will affect the visibility of the module and so
will need both checking and parsing.
The current implementation does not handle those cases because:
1) It does not differentiate between the property that affects the
module and those that do not. It checks and gathers all of them with
the last property gathered overriding the rules for the previous
properties.
2) It relies on overriding methods in MethodBase in order to change the
default behavior for the package module. That works because
packageModule embeds ModuleBase but will not work for
DefaultsModuleBase as it does not embed ModuleBase and instead is
embedded alongside it so attempting to override a method in
MethodBase leads to ambiguity.
This change addresses the issues as follows:
1) It adds a new visibility() []string method to get access to the
primary visibility rules, i.e. the ones that affect the module.
2) It adds two fields, 'visibilityPropertyInfo []visibilityProperty'
to provide information about all the properties that need checking,
and 'primaryVisibilityProperty visibilityProperty' to specify the
property that affects the module.
The PackageFactory() and InitAndroidModule(Module) functions are
modified to initialize the fields. The override of the
visibilityProperties() method for packageModule is removed and the
default implementations of visibilityProperties() and visibility()
on ModuleBase return information from the two new fields.
The InitDefaultsModule is updated to also initialize the two new
fields. It uses nil for primaryVisibilityProperty for now but that
will be changed to return defaults_visibility. It also uses the
commonProperties structure created for the defaults directly instead
of having to search for it through properties().
Changed the visibilityProperty to take a pointer to the property that
can be used to retrieve the value rather than a lambda function.
Bug: 130796911
Test: m nothing
Change-Id: Icadd470a5f692a48ec61de02bf3dfde3e2eea2ef
Enhances the visibility mechanism to use the default_visibility
property of the closest ancestor package that has the property
specified.
Bug: 133290645
Test: m droid
Change-Id: I7248e9034a73894ac8d514f913316438c4d7c079
Adds a package module type with a default_visibility property. The
package module type can only be specified once per package.
Bug: 133290645
Test: m droid
Change-Id: Ibb2fb499c9ea88ecaa662d3cd2cbde478e4b9a4b
However only allow it when they are merged from different defaults.
Extend the tests to cover that and other cases with visibilities in
defaults.
Also avoid dumping the whole visibility spec in the error message when a
visibility check fails, because it gets noisy for long visibility lists, and
can be confusing when //visibility:public gets merged with other visibility
rules.
Test: Soong self test
Bug: 112158820
Bug: 130796911
Change-Id: I242513975a3f824b9ea2eab5b94b194b9af2481b
Implementation uploaded for review. Includes unit tests but does not
yet handle prebuilts, that will come in a future change once some
more general issues with prebuilts and namespaces is resolved.
See README.md#Visibility for details of what this does and how to use
it.
Bug: 112158820
Test: add visibility rules for core library modules, make core-tests
Change-Id: I8ec980554398ad6f2d42043ce518f811a35da679
