aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java
Commit message (Collapse)AuthorAge
...
* Migrate remaining apple-related skylark types to skylarkbuildapiGravatar cparsons2018-06-01
| | | | | RELNOTES: None. PiperOrigin-RevId: 198880301
* Use a new RecursivePackageProvider to ask skyframe for the correct package ↵Gravatar juliexxia2018-06-01
| | | | | | nodes in ConfiguredTargetQueryEnvironemnt. This lets us support recursive target patterns with cquery. PiperOrigin-RevId: 198879650
* Move TARGET_CPU from the CcToolchainProvider to BuildConfiguration.Gravatar jcater2018-06-01
| | | | PiperOrigin-RevId: 198877280
* [java_common.compile] Always generate a source jar.Gravatar elenairina2018-06-01
| | | | | | | | | | | java_common.compile doesn't generate the output source jar when a source jar is the only input for the compilation. This is wrong because the source jar can include APT generated sources. It is also inconsistent with java_library and leads to inconsistent Skylark rules where a declared output will not always have a generating action. RELNOTES: None. PiperOrigin-RevId: 198872718
* repository_resolved_file: pretty printGravatar Klaus Aehlig2018-06-01
| | | | | | | | As the list of external repositories with their resolved information can grow quite large, pretty print it, to make it easier for humans to inspect. Change-Id: I34b2d6df84e52c07471a0bfaf97994cabd45feff PiperOrigin-RevId: 198871353
* C++: Remove CcSpecificLinkParamsProvider.Gravatar plf2018-06-01
| | | | | | No longer needed since proto_library cannot be used for Java. PiperOrigin-RevId: 198859993
* Converts PLACEHOLDER FileValues into RegularFileValue when queried viaGravatar shahan2018-05-31
| | | | | | ActionExecutionValue.getAllFileValues. PiperOrigin-RevId: 198807229
* Remove the Blaze strict java deps exemption for Android databinding. As ofGravatar Googler2018-05-31
| | | | | | | | | | | | | unknown commit, we are using the JavaBuilder processor exemption list instead of disabling strict deps for the affected rules outright. This narrows the degree to which the exemption is applied, and prevents other strict deps violations from accruing on targets that enable databinding. Step 2 of 2; we needed the change to roll out in JavaBuilder first to be able to fix up issues in the depot first before removing the exemption in Blaze. See https://github.com/bazelbuild/bazel/commit/7edc5d49c8e764ab2bdf19e3a9fb58ea30fa708f for the original attempt. PiperOrigin-RevId: 198793976
* Migrate remaining Android Skylark API to skylarkbuildapiGravatar asteinb2018-05-31
| | | | | | | | I don't know much about most of this code, but there should be no functional changes. RELNOTES: none PiperOrigin-RevId: 198773657
* Log warning cleanupGravatar neerajen2018-05-31
| | | | | | | Setting --config in .blazerc that overrode previous options in .blazerc was triggering unnecessary warnings. Fixed by only logging warnings when a user attempts to override an option specified on the command line. RELNOTES: None. PiperOrigin-RevId: 198756160
* Remove redundant @SkylarkModule annotation on JavaInfo.Provider, as its ↵Gravatar cparsons2018-05-31
| | | | | | | skylarkbuildapi interface is annotated. RELNOTES: None. PiperOrigin-RevId: 198743504
* Migrate config-related skylark objects to skylarkbuildapiGravatar cparsons2018-05-31
| | | | | RELNOTES: None. PiperOrigin-RevId: 198735582
* Remove unused codepaths now that non_propagated_deps has been removed as an ↵Gravatar kaipi2018-05-31
| | | | | | attribute. PiperOrigin-RevId: 198735448
* Migrate test-related skylark API to skylarkbuildapiGravatar cparsons2018-05-31
| | | | | RELNOTES: None. PiperOrigin-RevId: 198728350
* Open up visibility of BuildConfiguration$OutputDirectory for serialization ↵Gravatar janakr2018-05-31
| | | | | | and remove unused repositoryName field from BuildConfiguration. PiperOrigin-RevId: 198723339
* Remove the non_propagated_deps attribute from objc_library and apple_binary. ↵Gravatar kaipi2018-05-30
| | | | | | | This was a workaround created to deal with duplicated symbol errors, but there are now better ways to avoid them than using this attribute. RELNOTES: non_propagated_deps has been removed from objc_library and apple_binary. PiperOrigin-RevId: 198620886
* Remove support for ↵Gravatar cushon2018-05-30
| | | | | | --experimental_one_version_enforcement_use_transitive_jars_for_binary_under_test PiperOrigin-RevId: 198601057
* Special case * in target lookup, work around for #5300.Gravatar twerth2018-05-30
| | | | | | | | * is not an allowed file system character on Windows and checking if it's a directory or file for the wilcard check would throw an InvalidPathException. RELNOTES: None PiperOrigin-RevId: 198595138
* Allow rules that provide resources and assets as deps of android_* rulesGravatar asteinb2018-05-30
| | | | | | | | | | | | | | | | | | | These restrictions were originally put in place to prevent things like android_binary from being used as dependencies of android_library. However, it doesn't actually work - the restrictions are all ORed together, and that means rules that are of the allowed kind OR that have a JavaProvider are allowed. Since all android_binary targets presumably have Java providers, they are presumably all allowed. Slightly expand these restrictions by also allowing rules that have Android resource and asset providers. This will allow us to use Skylark rules to only inherit assets and resources from a target, but not anything else. I don't anticipate this expansion will have unwanted side effects, since virtually all Android targets already have Java providers anyway. RELNOTES: none PiperOrigin-RevId: 198593996
* Modify cc_toolchain_suite rule to allow selection of cc_toolchain label ↵Gravatar rosica2018-05-30
| | | | | | | | | | | | | | | | without reading the CROSSTOOL file. As we want to reroute selecting the toolchain from CROSSTOOL through cc_toolchain, cc_toolchain_suite should have all the necesarry information for obtaining the cc_toolchain label without accessing the CROSSTOOL file. In order to do that, besides the existing <toolchain.targetCpu>|<toolchain.compiler>, we add <cpu> type of key in 'toolchains' attribute of cc_toolchain_suite. Now the selection of cc_toolchain label goes as follows: 1. Return toolchains[<cpu>|<compiler> if it exists 2. Return toolchains[<cpu>] if it exists 3. Fall back to the previous state: return toolchains[<toolchain.targetCpu>|<toolchain.compiler>] RELNOTES: None. PiperOrigin-RevId: 198588849
* Adds support for InlineFileArtifactValue.Gravatar shahan2018-05-30
| | | | PiperOrigin-RevId: 198584000
* Add --apple_enable_auto_dsym_dbg flagGravatar Googler2018-05-30
| | | | | | | | | This new flag can be used to forcibly enable dSYM generation for dbg apple builds, which is especially useful for debugging in remote builds, which may require the use of dSYMs. RELNOTES: Added --apple_enable_auto_dsym_dbg flag. PiperOrigin-RevId: 198577541
* Fix Skylark type typoGravatar asteinb2018-05-30
| | | | | | | | Fortunately or unfortunately, Skylark doesn't seem to validate against this type, so tests don't pick this mistyping up. RELNOTES: none PiperOrigin-RevId: 198568282
* Fix Bazel crash on bad config_setting labels.Gravatar gregce2018-05-30
| | | | | | | | | | | | | | | | This used to work more smoothly. But the introduction of ConfiguredTargetAndData adds a Precondition check: https://source.bazel.build/bazel/+/master:src/main/java/com/google/devtools/build/lib/skyframe/ConfiguredTargetAndData.java;l=68?q=ConfiguredTargetAndData that crashes if innerConfigurationKey is null. The only way that can happen is when reading a bad label, which Bazel assumes (incorrectly in this case) to be a null-configured source file. Good times. PiperOrigin-RevId: 198557148
* Fix an incorrect example in the platform documentation.Gravatar jcater2018-05-30
| | | | PiperOrigin-RevId: 198556851
* Fix `equals()` and `hashCode()` for artifacts: artifacts of different ↵Gravatar Dmitry Lomov2018-05-30
| | | | | | | | | | | | | classes are not equal. Also validate that there are no tree and file artifacts with the same exec path. Fixes #4668. Closes #5284. Change-Id: Id97c0407a476a5bfc697b4ca7b858e3d0c0f8c75 PiperOrigin-RevId: 198540425
* Allow passing the relative symlink resolution policy to the SpawnInputExpanderGravatar ulfjack2018-05-30
| | | | PiperOrigin-RevId: 198535546
* Automated rollback of commit 7fcbc8ffdead028d19606fefa2fa3be13781da98.Gravatar laszlocsomor2018-05-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** According to a post-submit regression test, this commit increased Bazel's memory usage slightly beyond some threshold. That event prompted me to consider and question the necessity of this commit. My goal is to make Bazel work on Windows without requiring MSYS, failing the build only if an action is a shell action. Toolchainifying the shell is related to, but not required by this effort. What is required is to fail the build when Bazel tries to create a shell action but the shell is missing, and we have that already with ShToolchain.getPath (which only considers the ShellConfiguration fragment). What's missing for my goal is to reimplement hardcoded shell actions (i.e. SpawnAction.builder().setShellCommand(...)) without using the shell where possible. *** Original change description *** shell toolchain: genrule now uses it genrule() now uses the shell toolchain (as well as the ShellConfiguration config fragment) to look up the shell interpreter's path. Also the CommandHelper no longer looks up the shell interpreter's path itself. Instead its ctor takes the path as an argument. This allows supporting rules that already use the shell toolchain and rules that still only consider the configuration fragment. With these changes genrule() is now able to use the shell interpreter registered as a toolchain, even if there's no `--shell_executable` flag specified (or its value is empty). Subsequent commits will migrate more and more rules to depend on the shell toolchain. This commit takes us closer to: 1. be able to detect the local shell interpreter's location, especially when it's not the default /bin/bash 2. be able to define different shell toolchains (different interpreter paths) for remote builds 3. gracefully fail the build if the machine has no shell installed but the action graph included a shell action See https://github.com/bazelbuild/bazel/issues/4319 Change-Id: I0674c7e2d5917643d87b48b19a1cb43e606ad2f7 Closes #5282. *** RELNOTES: none PiperOrigin-RevId: 198527351
* C++: Hide compilation context from SkylarkGravatar plf2018-05-30
| | | | | RELNOTES:none PiperOrigin-RevId: 198518792
* Rename r_txt from AndroidResourcesInfo to compiletime_r_txtGravatar asteinb2018-05-29
| | | | | | | | | | I didn't catch it at the time this field was initially introduced, but R files from Android libraries, exposed via AndroidResourcesInfo, are compiletime only. They should not be used at runtime or inherited from dependencies. Rename the field and add this warning to the description. RELNOTES: none PiperOrigin-RevId: 198448391
* Fix b/80260450 which saw cquery --output=proto crashing on alias configured ↵Gravatar juliexxia2018-05-29
| | | | | | | targets. Along the way, update ConfiguredTargetAccessor to return the correct Target (the alias, not the actual) when dealing with AliasedConfiguredTargets. RELNOTES: None. PiperOrigin-RevId: 198445580
* Expose Android data processing API in skylarkbuildapiGravatar asteinb2018-05-29
| | | | | | | | | | | | | | | | Expose the Android data processing API to skylarkbuildapi Rather than pass the SkylarkBuildApi interfaces (e.g., FileApi instead of Artifact) all the way through the Android data processing code, instead just cast them to the correct Bazel types. This is ugly, but is probably better than having to do multiple refactorings of the Android code. (A similar refactoring, for just a single type, took about 10 changes and 3300 lines of code.) The Skylark Build API is only meant for things exposed to Skylark, not Bazel internals, and, besides, when building with Bazel we should only expect inputs from other parts of Bazel. RELNOTES: none PiperOrigin-RevId: 198438519
* Propagate --experimental_prune_cpp_input_discovery to host builds. Otherwise,Gravatar Googler2018-05-29
| | | | | | | host builds don't profit from it. RELNOTES: None. PiperOrigin-RevId: 198437467
* Simplify RuleClass.Builder#cfg, Attribute.Builder#cfg interfaces.Gravatar gregce2018-05-29
| | | | PiperOrigin-RevId: 198427902
* Fix edge case in inferring Java package from path to targetsGravatar asteinb2018-05-29
| | | | | | | | When deriving the Java package from path to a target, actually derive it from the path to the entire target, not just the target's BUILD file. RELNOTES: none PiperOrigin-RevId: 198426047
* Merge ComposingSplitTransition and ComposingPatchTransition.Gravatar gregce2018-05-29
| | | | | | Part of https://docs.google.com/document/d/1_UJKmAQ9EE8i3Pl0il3YLTYr-Q9EKYYyLatt2zohfyM/edit# PiperOrigin-RevId: 198420365
* Use independently passed assets in aapt2 packaging as wellGravatar asteinb2018-05-29
| | | | | | | | | | | | | | Much earlier, I made a change that allowed passing assets without resources to aapt packaging. Do the same for aapt2 packaging too. The busybox seems to be expecting compiled symbols, so compile assets and pass the compiled version in. (Compiling assets doesn't save any time, but doesn't cost much either, and means that we'll eventually be able to phase out the parsed form entirely. Adapting the Busybox to take parsed assets would probably work too, but getting the code to handle it would be really messy.) RELNOTES: none PiperOrigin-RevId: 198417111
* Remove CcToolchainType rule.Gravatar jcater2018-05-29
| | | | PiperOrigin-RevId: 198413879
* Change uses of cc_toolchain_type back to plain toolchain_type.Gravatar jcater2018-05-29
| | | | | | This is a prequisite to removing cc_toolchain_type entirely. PiperOrigin-RevId: 198402472
* Properly expose asset provider for targets without explicit manifestGravatar asteinb2018-05-29
| | | | | RELNOTES: none PiperOrigin-RevId: 198402335
* Make ConstantRuleVisibility static constants into @AutoCodec constants.Gravatar janakr2018-05-29
| | | | PiperOrigin-RevId: 198398386
* Move Android data info classes to skylarkbuildapiGravatar asteinb2018-05-29
| | | | | | | | | | Expose all Android data info classes as interfaces in skylarkbuildapi. Most methods are not exposed in the interface since they are not exposed in Skylark. In fact, stop exposing a few methods from AndroidResourcesInfo that are exposed but shouldn't be. RELNOTES: none PiperOrigin-RevId: 198396677
* shell toolchain: genrule now uses itGravatar Laszlo Csomor2018-05-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | genrule() now uses the shell toolchain (as well as the ShellConfiguration config fragment) to look up the shell interpreter's path. Also the CommandHelper no longer looks up the shell interpreter's path itself. Instead its ctor takes the path as an argument. This allows supporting rules that already use the shell toolchain and rules that still only consider the configuration fragment. With these changes genrule() is now able to use the shell interpreter registered as a toolchain, even if there's no `--shell_executable` flag specified (or its value is empty). Subsequent commits will migrate more and more rules to depend on the shell toolchain. This commit takes us closer to: 1. be able to detect the local shell interpreter's location, especially when it's not the default /bin/bash 2. be able to define different shell toolchains (different interpreter paths) for remote builds 3. gracefully fail the build if the machine has no shell installed but the action graph included a shell action See https://github.com/bazelbuild/bazel/issues/4319 Change-Id: I0674c7e2d5917643d87b48b19a1cb43e606ad2f7 Closes #5282. Change-Id: I0674c7e2d5917643d87b48b19a1cb43e606ad2f7 PiperOrigin-RevId: 198394021
* Add a pretty-printer class to SkylarkGravatar Klaus Aehlig2018-05-29
| | | | | | | | | | | With the recording of the results of repository rules (that eventually will lead to an implementation of the WORKSPACE.resolved proposal) bazel started writing out lengthy Skylark values. To make this file more readable for humans, add a Skylkark printer that does at least some basic line breaking and indenting. Change-Id: I469d029421df9212b43747509dd17bd6c64da4a8 PiperOrigin-RevId: 198389112
* Avoid unnecessary work in validating C++ inclusions. Specifically:Gravatar Googler2018-05-29
| | | | | | | | | | | | | | - declaredIncludeSrcs don't need to be looked at as they also become part of the compilation prerequisites (see CcCompilationContext.addDeclaredIncludeSrc()) - transitiveModules can never be "incorrect" as they get computed and added by Bazel itself. - declaredIncludeDirs/warnIncludeDirs can be computed lazily. As most people aim for a warning-free build, it is rarely necessary to compute either set in practice. RELNOTES: None. PiperOrigin-RevId: 198386262
* Refactor root cause reporting in ConfiguredTargetFunctionGravatar ulfjack2018-05-29
| | | | | | We now track Causes instead of plain Labels, which will allow us to do better reporting in the future. Add basic tests. PiperOrigin-RevId: 198380468
* Add compilerFlagForMigrationDoNotUse field to cc_commonGravatar rosica2018-05-29
| | | | | | | This will help migration from config_setting.values{"compiler"} to config_setting.flag_values{"@bazel_tools//tools/cpp:compiler"} RELNOTES: None. PiperOrigin-RevId: 198377299
* Add CcSysrootAliasRuleGravatar dbabkin2018-05-29
| | | | | RELNOTES:none PiperOrigin-RevId: 198364550
* Remove CppCompileAction.optionalSourceFileGravatar hlopko2018-05-28
| | | | | | | It's unused. RELNOTES: NONE. PiperOrigin-RevId: 198316668
* Treat runfiles middlemen as aggregating middlemen.Gravatar Benjamin Peterson2018-05-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal is to, for an action execution, make only a single skyframe edge to every required runfiles tree rather than an edge to every runfiles artifact directly. We accomplish this by pulling the runfiles artifacts' metadata for a particular runfiles tree through the appropriate runfiles middlemen artifact in one batch. This CL fixes https://github.com/bazelbuild/bazel/issues/3217. This change makes runfiles middlemen more similar to aggregating middlemen. We however continue to treat runfiles middlemen slightly differently than true aggregating middlemen. Namely, we do not expand runfiles middlemen into the final action inputs. The reasons for this are: 1. It can make latent bugs like https://github.com/bazelbuild/bazel/issues/4033 more severe. 2. The runfiles tree builder action's output MANIFEST contains absolute paths, which interferes with remote execution if its metadata is added to a cache hash. 3. In the sandbox, it causes the runfiles artifacts to be mounted at their exec path locations in addition to within the runfiles trees. This makes the sandbox less strict. (Perhaps tolerably?) 4. It saves a modicum of (transient) memory and time to not expand. If the first two issues are fixed, it could be a nice simplification to completely replace runfiles middlemen with aggregating middlemen. Change-Id: I2d2148297f897af4c4c6dc055d87f8a6fad0061e PiperOrigin-RevId: 198307109
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-04 09:29:43 +0000