Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

incompatible_no_transitive_loads: Forbid macros loaded transitively #5636

Closed
laurentlb opened this issue Jul 19, 2018 · 12 comments
Closed

incompatible_no_transitive_loads: Forbid macros loaded transitively #5636

laurentlb opened this issue Jul 19, 2018 · 12 comments
Assignees
Labels
incompatible-change Incompatible/breaking change P1 I'll work on this now. (Assignee required)

Comments

@laurentlb
Copy link
Contributor

laurentlb commented Jul 19, 2018

When a bzl file contains a load, e.g.
load("//some:file.bzl", "fct")
it implicitly exports fct.

This is problematic for many reasons:

  • Exports should be explicit
  • Other languages don't do that
  • Removing a load can break other files
  • So it means we can't have a tool to safely remove unused loads

Unfortunately, this is a breaking change.

There are two ways to fix it.

  1. Update the load site and use the label of the file where the symbol is really declared
  2. Update the loaded file. To explicitly re-export the symbol foo, use:
load("...", _foo = "foo")

foo = _foo
@ittaiz
Copy link
Member

ittaiz commented Jul 20, 2018 via email

@laurentlb laurentlb self-assigned this Sep 21, 2018
@laurentlb laurentlb added the P1 I'll work on this now. (Assignee required) label Sep 21, 2018
bazel-io pushed a commit that referenced this issue Sep 27, 2018
With flag set, loaded symbols are not automatically re-exported.

#5636

RELNOTES: None.
PiperOrigin-RevId: 214776940
@laurentlb laurentlb changed the title Forbid macros loaded transitively --incompatible_no_transitive_loads: Forbid macros loaded transitively Nov 23, 2018
@laurentlb laurentlb added the incompatible-change Incompatible/breaking change label Nov 23, 2018
bazel-io pushed a commit that referenced this issue Nov 26, 2018
Default behavior of Bazel will change soon (--incompatible_no_transitive_loads)

#5636

RELNOTES: None.
PiperOrigin-RevId: 222841756
@laurentlb laurentlb changed the title --incompatible_no_transitive_loads: Forbid macros loaded transitively incompatible_no_transitive_loads: Forbid macros loaded transitively Jan 7, 2019
@laurentlb
Copy link
Contributor Author

After running on the CI (https://buildkite.com/bazel/bazel-at-release-plus-incompatible-flags/builds/56), here's the list of projects that fail with the flag:

  • Android Testing
  • bazel-toolchains
  • Gerrit
  • rules_closure
  • rules_foreign_cc
  • rules_scala
  • Tensorflow

@ittaiz
Copy link
Member

ittaiz commented Jan 16, 2019

@laurentlb you fixed rules_scala, right?

@laurentlb
Copy link
Contributor Author

I think so. I'll update the list after a new CI run.

@philwo
Copy link
Member

philwo commented Feb 6, 2019

This flag was not flipped in time for the Bazel 0.23.0 release and will thus be postponed to Bazel 0.24.0.

@laurentlb
Copy link
Contributor Author

Still blocked by: Android Testing, Bazel integration testing, Bazel Remote Cache, Bazel Watcher, Gerrit, Tensorflow, rules_webtesting.

chuckx added a commit to tink-crypto/tink that referenced this issue May 3, 2019
In bazel 0.25 the flag --incompatible_no_transitive_loads is now enabled by
default. To fix this, we must not rely on imported symbols being exported by
default.

Context: bazelbuild/bazel#5636
PiperOrigin-RevId: 246384617
GitOrigin-RevId: 5b911dcb631637cadc42d83597955058d5987556
g-easy pushed a commit to census-instrumentation/opencensus-cpp that referenced this issue May 10, 2019
We were picking up ABSL flags transitively.
After bazelbuild/bazel#5636 this no longer works.
load() the flags directly from ABSL's GENERATED_copts.bzl.
chuckx added a commit to tink-crypto/tink that referenced this issue May 14, 2019
In bazel 0.25 the flag --incompatible_no_transitive_loads is now enabled by
default. To fix this, we must not rely on imported symbols being exported by
default.

Context: bazelbuild/bazel#5636
PiperOrigin-RevId: 246384617
guibou added a commit to tweag/rules_haskell that referenced this issue Jun 25, 2019
guibou added a commit to tweag/rules_haskell that referenced this issue Jun 26, 2019
guibou added a commit to tweag/rules_haskell that referenced this issue Jun 26, 2019
guibou added a commit to tweag/rules_haskell that referenced this issue Jun 26, 2019
guibou added a commit to tweag/rules_haskell that referenced this issue Jun 26, 2019
guibou added a commit to tweag/rules_haskell that referenced this issue Jun 26, 2019
guibou added a commit to tweag/rules_haskell that referenced this issue Jun 27, 2019
bazel-io pushed a commit that referenced this issue Nov 7, 2019
#5636

RELNOTES: None.
PiperOrigin-RevId: 279183449
pudelkoM added a commit to stratum/stratum that referenced this issue Jan 9, 2020
pudelkoM added a commit to stratum/stratum that referenced this issue Jan 9, 2020
Yi-Tseng pushed a commit to stratum/stratum that referenced this issue Jan 11, 2020
@ittaiz
Copy link
Member

ittaiz commented Jan 16, 2020

@laurentlb to verify- the fact that this issue is closed means new code can use load "regularly" and not have to worry about it being exported, right?

@laurentlb
Copy link
Contributor Author

Yes.
We close an issue about an incompatible flag when the change is enabled by default at head. So you can expect all Bazel releases after March 2019 to behave correctly in this regard.

Yi-Tseng pushed a commit to stratum/stratum that referenced this issue Jan 19, 2020
Yi-Tseng pushed a commit to stratum/stratum that referenced this issue Mar 3, 2020
Yi-Tseng pushed a commit to stratum/stratum that referenced this issue Mar 4, 2020
pudelkoM added a commit to stratum/stratum that referenced this issue Mar 4, 2020
* Bump Bazel to 1.0.0

* Fix transitive macro load

See: bazelbuild/bazel#5636

* Fix memory leak in AdminService

* Fix linkopts being copts

* Update p4c bazel rules

* Combine build targets

* Fix bazel_gazelle

* Bump bazel version to 2.0.0

* Fix PI deps

* Fix p4c rules (for real)

* Fix load() in BUILD files

* python gRPC library cleanup

* update build image

* Skip Bazel profile

* Add gcov-wrapper

Sometimes the gcov tool won't print "Creating ...gcov" which may leads the
bazel coverage rules failed

* break tests to small one

* Fix BUILD file

* disable bcm tests

* Fix "add gcov wrapper" step

* Fix CDLang dependency

Should be https://repo1.maven.org

* Use new cache

* disable cdlang tests

* Cleanup

* move gcov wrapper script to Docker image

* add bcm tests back

* remove gcov wrapper step from CI

* Bump bazel version to 2.2.0

* Fix build

* Put bazel analyze-profile back

* move back to v2 cache

* update gnoi path

* resolve comment

* address comments

Co-authored-by: Maximilian Pudelko <pudelkoM@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
incompatible-change Incompatible/breaking change P1 I'll work on this now. (Assignee required)
Projects
None yet
Development

No branches or pull requests

7 participants