| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
Note that it is currently only used by the java_proto_library family of rules (if enabled per flag).
RELNOTES: None
PiperOrigin-RevId: 208601730
|
|
|
|
|
|
|
| |
that it can be accessed in Skylark. One example where this is used is in Android IDL processing where the manifestProtoOutput is used to split out the Android IDL generated Java classes from the overarching outputJar produced by the android_library rule.
RELNOTES: none
PiperOrigin-RevId: 206580880
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dependencies.
This is a reland of https://github.com/bazelbuild/bazel/commit/5deca4cf88f5568771f2c836a9b8c693b88bd749.
This will make protoc see as direct dependencies the .proto files that were included using the proto_source_root flag.
Until now, Bazel passed to protoc the direct dependencies of a target as the path relative to the WORKSPACE, which made it fail when a shorter path, relative to the package was used.
Progress on #4544.
RELNOTES: None.
PiperOrigin-RevId: 203808292
|
|
|
|
|
|
|
|
|
|
|
| |
Like with providers, consumers get a merged view of all actions from the merged configured target (all other aspects + the base target).
I had to rejig the aspect value / configured aspect to be symmetric with rule configured targets.
I do not expect significant memory bloat from this. All lists / maps already existed, only extra fields have been added.
RELNOTES: Expose aspect actions provider to Skylark.
PiperOrigin-RevId: 201697923
|
|
|
|
|
| |
RELNOTES:none:
PiperOrigin-RevId: 200988244
|
|
|
|
|
|
|
|
|
|
| |
This is a rollforward of CL/197725926 after depot fix.
NEW: Additional deletions of unused providers (no constructor call references).
NEW[last rollforward]: Allow java_* rules to depend on proto_libraries via runtime_deps and exports. This should avoid the breakage that caused the original rollback. The edges are no-ops and could be removed.
PiperOrigin-RevId: 198060345
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove java support from proto_library.
NEW: Allow java_* rules to depend on proto_libraries via runtime_deps and exports. This should avoid the breakage that caused the original rollback. The edges are no-ops and could be removed.
*** Reason for rollback ***
Targets in the repository are still able to depend on proto_library rules
even after the --noemit_proto_java_outputs flag flip. Removal of the Java
support from proto_library breaks them.
PiperOrigin-RevId: 197725926
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Targets in the repository are still able to depend on proto_library rules
even after the --noemit_proto_java_outputs flag flip. Removal of the Java
support from proto_library breaks them.
PiperOrigin-RevId: 197442659
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 197136304
|
|
|
|
|
|
|
|
|
|
| |
for direct, transitive, and full compile-time jars; runtime jars; and instrumentation
metadata. These are trivial wrappers around the corresponding getters on the recursive
and non-recursive JavaCompilationArgs objects.
This is a no-op refactoring in preparation for flatting JavaCompilationArgs into JavaCompilationArgsProvider.
PiperOrigin-RevId: 194047064
|
|
|
|
|
|
| |
ConfiguredTargetAndData. We want to get BuildConfiguration out of ConfiguredTarget because it uses >800K when serialized.
PiperOrigin-RevId: 188600002
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This will make protoc see as direct dependencies the .proto files that were included using the proto_source_root flag.
Until now, Bazel passed to protoc the direct dependencies of a target as the path relative to the WORKSPACE, which made it fail when a shorter path, relative to the package was used.
Progress on #4544.
RELNOTES: None.
PiperOrigin-RevId: 186294997
|
|
|
|
|
|
|
| |
Fixes #4544.
RELNOTES: Add "proto_source_root" flag to proto_library.
PiperOrigin-RevId: 185997723
|
|
|
|
|
|
|
|
| |
JavaBuilder and friends will write this into the manifest of the produced jars to assist with add_dep commands, when strict_deps is violated.
This will obviate the need for blaze to pass jar owners on the command line.
PiperOrigin-RevId: 185763422
|
|
|
|
| |
PiperOrigin-RevId: 185369902
|
|
|
|
|
|
|
|
| |
either a Label or a List<Label>. We can easily enforce this through static type checking, so do it.
This will help with LateBoundDefault serialization, since we don't have to serialize an arbitrary object.
PiperOrigin-RevId: 184347100
|
|
|
|
|
|
|
| |
ConfiguredTargetAndTarget instead of a ConfiguredTarget.
This is to assist in deprecating ConfiguredTarget.getTarget().
PiperOrigin-RevId: 184043491
|
|
|
|
|
|
|
| |
Fixes #3735.
RELNOTES: java_common.compile supports neverlink
PiperOrigin-RevId: 184017410
|
|
|
|
|
|
|
| |
JavaRuntimeInfo.
Change-Id: Ic338dc9b3e5efa2fee92dba722a46cab743db40c
PiperOrigin-RevId: 182919931
|
|
|
|
|
|
|
|
|
| |
This is the first step in removing package loading from JvmConfigurationLoader (I didn't want to add the rest into this change because it's technically possible to access ctx.fragments.jvm even though it contains no fields, so removing that is an incompatible change) and it's also possible that removing error reporting from JvmConfigurationLoader causes some subtle changes in behavior.
Baby steps. Now that the hard part is done, there is no need to rush.
RELNOTES: None.
PiperOrigin-RevId: 181143978
|
|
|
|
|
|
| |
Preparatory step for removing ConfigurationTransition.HOST.
PiperOrigin-RevId: 179838374
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and expose transitive source jars to Skylark.
Initial change was rolled back (unknown commit). java_common.compile wouldn't fill the JavaRuleOutputJarsProvider when there was only one input source jar. Fixed that and added test (there was one before, but didn't check this particular provider).
Slightly refactor java classes to take in specific host javabase inputs and host java executable for creating the source jar, instead of always relying on fetching them from native java rules specific attributes.
Creating the output source jar in java_common.compile makes the behavior more similar to java_library.
Exposing the transitive_source_jars to Skylark helps with the Skylark migration from the old 'java' provider to JavaInfo.
Progress on #2614.
RELNOTES: transitive_source_jars is now exposed on JavaInfo.
PiperOrigin-RevId: 177311138
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks //javatests/com/google/devtools/intellij/blaze/plugin/aspect/java/soygenrule:SoyGenruleTest
*** Original change description ***
Create the output source jar in java_common.compile
and expose transitive source jars to Skylark.
Slightly refactor java classes to take in specific host javabase inputs and host java executable for creating the source jar, instead of always relying on fetching them from native java rules specific attributes.
Creating the output source jar in java_common.compile makes the behavior more similar to java_library.
Exposing the transitive_source_jars to Skylark helps with the Skylark migration fr...
***
RELNOTES: None.
PiperOrigin-RevId: 177015958
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and expose transitive source jars to Skylark.
Slightly refactor java classes to take in specific host javabase inputs and host java executable for creating the source jar, instead of always relying on fetching them from native java rules specific attributes.
Creating the output source jar in java_common.compile makes the behavior more similar to java_library.
Exposing the transitive_source_jars to Skylark helps with the Skylark migration from the old 'java' provider to JavaInfo.
Progress on #2614.
RELNOTES: transitive_source_jars is now exposed on JavaInfo.
PiperOrigin-RevId: 176844750
|
|
|
|
|
|
|
| |
Previously the java rules returned some providers twice: once as regular providers and once wrapped in JavaInfo (e.g. JavaCompilationArgsProvider). This is unnecessary, inefficient and error prone. JavaInfo should be the only way of returning these providers.
RELNOTES: None.
PiperOrigin-RevId: 171663550
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not attempting to fix b/65618333 here, just handling one case
currently breaking users (JavaInfo created via java_common.compile).
My temporary workaround attempt to expose this information in the
soy custom rule failed (unknown commit) -- to fix users we really
need java_common changes.
RELNOTES: Expose output jars and jdeps in java_common.provider, when available.
PiperOrigin-RevId: 170236096
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, there is no way to enforce that LateBoundDefaults only access
the fragments that they declare. This means that LateBoundDefaults can
fail to declare fragments at all, or declare the wrong ones, and still
have no troubles.
But when trimming, these fragments must be declared, because otherwise
they will not necessarily be available.
This change refactors LateBoundDefault to declare a single fragment type,
not a set. All existing LateBoundDefaults use sets with a single element
or no elements at all for their set of fragment classes, so this does not
limit anything being done currently.
To account for LateBoundDefaults which do not use configuration at all,
typically those which only want to access the configured attribute map,
it is possible for Void to be the fragment class which is requested.
To account for LateBoundDefaults which need to access methods of the
BuildConfiguration instance itself, it is possible for BuildConfiguration
to be the fragment class which is requested; however, this is unsafe, so
it is only a temporary state until a way to do this without also giving
access to all of the fragments can be added.
Drive-by refactoring: LateBoundDefaults' values are now typed. All actual
production LateBoundDefaults were Label or List<Label> typed, through the
LateBoundLabel and LateBoundLabelList subclasses. These subclasses have
been removed, and LateBoundDefault has two type parameters, one for the
type of its input, and one for the type of its output.
RELNOTES: None.
PiperOrigin-RevId: 169242278
|
|
|
|
|
|
| |
This is a trivial change with a large file footprint.
PiperOrigin-RevId: 169169864
|
|
|
|
|
|
|
| |
Memory is saved by sharing the format string and label object instances, instead of constructing new strings for each action.
RELNOTES: None
PiperOrigin-RevId: 164731899
|
| |
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 163838735
|
|
|
|
|
|
|
|
|
|
|
|
| |
SKIP_KOKORO: Kokoro is out of quota.
*** Reason for rollback ***
Causes memory regression, somehow: b/63934093
*** Original change description ***
PiperOrigin-RevId: 163023580
|
| |
|
|
|
|
|
|
| |
correct //tools/cpp:toolchain and //tools/jdk:jdk.
PiperOrigin-RevId: 161227981
|
|
|
|
|
|
| |
To unblock, regression tests for the breakage will come in a follow-up CL.
PiperOrigin-RevId: 159829368
|
|
|
|
|
|
| |
Cuts down on file count and makes it easier to find these methods.
PiperOrigin-RevId: 159560422
|
|
|
|
|
|
|
|
|
|
|
|
| |
friends.
The wrapping provider contains its own provider map containing any providers that may conflict. This can be used generally for any aspect that wants to override its base providers (during migration), and due to the generality we should be able to cut down on code size and complexity.
Once we have this, we can more easily and uniformly bind aspects to Skylark for aspect-on-aspect functionality. The Skylark providers can be instantiated with a wrapping provider if one is present, or fall through to the base target if they aren't.
We will also likely save a bit of memory from cutting down on wrapping classes.
PiperOrigin-RevId: 159461325
|
|
|
|
|
| |
PiperOrigin-RevId: 150019356
MOS_MIGRATED_REVID=150019356
|
|
|
|
|
|
|
|
|
|
|
| |
Having a correlation between an output jar and a source jar is not enough.
There may be situations when an output jar is generated from more source jars,
not just one. We need this flexibility especially in Skylark for the java
sandwich, when the user can compile multiple source jars.
--
PiperOrigin-RevId: 149510534
MOS_MIGRATED_REVID=149510534
|
|
|
|
|
|
|
|
| |
providers.
--
PiperOrigin-RevId: 147526961
MOS_MIGRATED_REVID=147526961
|
|
|
|
|
|
|
|
|
| |
This functionality is never used, have never been exposed to Skylark
and is a continuous pain to maintain and test.
--
PiperOrigin-RevId: 145079832
MOS_MIGRATED_REVID=145079832
|
|
|
|
|
|
|
|
| |
when it's reached through a :java_toolchain attribute.
--
PiperOrigin-RevId: 144638966
MOS_MIGRATED_REVID=144638966
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 144257691
MOS_MIGRATED_REVID=144257691
|
|
|
|
|
|
|
|
| |
The skylark provider is bound as "proto_java" to avoid collisions with the base, which is called "java".
--
PiperOrigin-RevId: 143960605
MOS_MIGRATED_REVID=143960605
|
|
|
|
|
|
|
|
|
| |
This hardcodes usage of proto-toolchains, which triggers strict-proto-deps.
Since strict-proto-deps relies on a proto-compiler feature which doesn't exist yet, I've also changed the default of --strict_proto_deps to 'default', which won't trigger the check unless specifically requested.
--
PiperOrigin-RevId: 141347426
MOS_MIGRATED_REVID=141347426
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 140912072
MOS_MIGRATED_REVID=140912072
|
|
|
|
|
|
|
| |
against rules. Aspects can attach to a rule if at least one set of required providers are present on the rule.
--
MOS_MIGRATED_REVID=140605023
|
|
|
|
|
|
|
|
|
| |
java_xxx_proto_library rules now look for toolchains in the external repo @com_google_protobuf_xxx//:xxx_toolchain
This still requires getting protobuf's GitHub repository to build with Bazel.
--
MOS_MIGRATED_REVID=140420903
|