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

proto_lang_toolchain: Add original sources of ProtoInfo to blacklistedProtos #10493

Closed
wants to merge 2 commits into from

Conversation

Yannic
Copy link
Contributor

@Yannic Yannic commented Dec 27, 2019

Fixes #10484

@rebello95
Copy link

Thanks for opening this, @Yannic!

I was able to confirm that cleaning/building Envoy Mobile with this patch applied to the bazel binary resolves the issue we're seeing in envoyproxy/envoy-mobile#617 🎉

rebello95 added a commit to envoyproxy/envoy-mobile that referenced this pull request Dec 31, 2019
Fixes #617, which resulted in duplicate symbols from protobuf being present in the final Envoy Mobile binary.

The [root cause](bazelbuild/bazel#10484) is being [patched in Bazel](bazelbuild/bazel#10493). In the meantime, we can revert these two commits in protobuf ([first](protocolbuffers/protobuf@7b28278), [second](protocolbuffers/protobuf@a03d332)) and apply the diff as a patch until we're able to update Bazel with the fix. More context on the protobuf issue is available [here](protocolbuffers/protobuf#7046).

Notes:
- This should be reverted after updating Bazel with the fix
- The version of protobuf specified in the `http_archive` should be in lockstep with upstream Envoy's version
- Upstream Envoy's `@envoy//bazel:protobuf.patch` patch is also included here

Signed-off-by: Michael Rebello <me@michaelrebello.com>
@keith
Copy link
Member

keith commented Jan 2, 2020

@Yannic any change this could get merged soon so we can make the next cut?

@irengrig irengrig removed the request for review from hlopko January 2, 2020 14:13
@irengrig irengrig added the team-Rules-Server Issues for serverside rules included with Bazel label Jan 2, 2020
@gnossen
Copy link

gnossen commented Jan 7, 2020

@Yannic Bump. Great change! This PR resolves an issue that's been blocking gRPC from upgrading its version of protobuf.

@Yannic
Copy link
Contributor Author

Yannic commented Jan 8, 2020

@cushon landed a similar change (01df1e5), but the issue was the difference between direct sources and original direct sources, so I don‘t think the issue is resolved by that commit.

This issue is blocking users from upgrading past Protobuf 3.9(?), so it would be great if we could get it merged soon.

/cc @laurentlb

@lberki
Copy link
Contributor

lberki commented Jan 9, 2020

I was about to lament that #getOriginalDirectProtoSources() is arguably a hack and demand that you at least add a test case but then I realized that:

  1. You actually have a test case
  2. It was me who did not add a test case in 46c95dc
    3 (I don't know what I was thinking)
  3. It might actually be better to check for the direct source file since (at least in theory) the same source file might give rise to multiple virtual ones if multiple proto_library rules reference it (I haven't thought it through as to whether that's a realistic risk)

Let me try to run this through our internal test battery.

@lberki
Copy link
Contributor

lberki commented Jan 9, 2020

...aaand, failures :(

@Yannic
Copy link
Contributor Author

Yannic commented Jan 9, 2020

I agree that this is a hack, but blacklisted_protos = ["a.proto", "b.proto"] will always reference the original file, so we have to filter by original files for now. We probably can (and should!) get rid of getOriginalDirectProtoSources() (& friends) when blacklisted_protos requires the ProtoInfo provider.

Let me know if there's anything I can do to fix the failing tests.

blacklistedProtos.addTransitive(protoInfo.getTransitiveProtoSources());
// TODO(yannic): Switch to getTransitiveProtoSources() and remove references to
// original proto sources when ProtoInfo is mandatory.
blacklistedProtos.addAll(protoInfo.getOriginalDirectProtoSources());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using direct instead of transitive sources un-does a change made in 01df1e5 that I think is going to break some uses of proto_lang_toolchain.blacklisted_protos.

Copy link
Contributor

@lberki lberki Jan 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, this is exactly what I found out after debugging the aforementioned test failures. Adding both here isn't very nice so I'll try adding the set of transitive original sources (I'd totally ask Yannic to do so, but since the tests that break are internal, he'd be flying blind...)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...and it blends! I'm sending this out (+my changes) for internal review.

@meteorcloudy
Copy link
Member

meteorcloudy commented Jan 14, 2020

@Yannic Yannic deleted the fix_10484 branch January 14, 2020 14:36
@Yannic
Copy link
Contributor Author

Yannic commented Jan 14, 2020

Suspecting that this shouldn't have been changed to transitive original sources: 4162cc5#diff-42ff97786b96eb7e34507430633100d5L279

This will fail for all proto_library targets that have at least one blacklisted source as a transitive dependency.

@meteorcloudy
Copy link
Member

@Yannic Can you send a fix for this?

@meteorcloudy
Copy link
Member

@Yannic Sorry, I'll rollback this change to get our CI green again.

bazel-io pushed a commit that referenced this pull request Jan 15, 2020
*** Reason for rollback ***

Broken Bazel CI in Downstream pipeline
#10588

*** Original change description ***

proto_lang_toolchain: Add original sources of ProtoInfo to blacklistedProtos

Fixes #10484

Closes #10493.

PiperOrigin-RevId: 289828390
Yannic added a commit to Yannic/bazel that referenced this pull request Jan 15, 2020
jpsim pushed a commit to envoyproxy/envoy that referenced this pull request Nov 28, 2022
Fixes envoyproxy/envoy-mobile#617, which resulted in duplicate symbols from protobuf being present in the final Envoy Mobile binary.

The [root cause](bazelbuild/bazel#10484) is being [patched in Bazel](bazelbuild/bazel#10493). In the meantime, we can revert these two commits in protobuf ([first](protocolbuffers/protobuf@7b28278), [second](protocolbuffers/protobuf@a03d332)) and apply the diff as a patch until we're able to update Bazel with the fix. More context on the protobuf issue is available [here](protocolbuffers/protobuf#7046).

Notes:
- This should be reverted after updating Bazel with the fix
- The version of protobuf specified in the `http_archive` should be in lockstep with upstream Envoy's version
- Upstream Envoy's `@envoy//bazel:protobuf.patch` patch is also included here

Signed-off-by: Michael Rebello <me@michaelrebello.com>
Signed-off-by: JP Simard <jp@jpsim.com>
jpsim pushed a commit to envoyproxy/envoy that referenced this pull request Nov 29, 2022
Fixes envoyproxy/envoy-mobile#617, which resulted in duplicate symbols from protobuf being present in the final Envoy Mobile binary.

The [root cause](bazelbuild/bazel#10484) is being [patched in Bazel](bazelbuild/bazel#10493). In the meantime, we can revert these two commits in protobuf ([first](protocolbuffers/protobuf@7b28278), [second](protocolbuffers/protobuf@a03d332)) and apply the diff as a patch until we're able to update Bazel with the fix. More context on the protobuf issue is available [here](protocolbuffers/protobuf#7046).

Notes:
- This should be reverted after updating Bazel with the fix
- The version of protobuf specified in the `http_archive` should be in lockstep with upstream Envoy's version
- Upstream Envoy's `@envoy//bazel:protobuf.patch` patch is also included here

Signed-off-by: Michael Rebello <me@michaelrebello.com>
Signed-off-by: JP Simard <jp@jpsim.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes team-Rules-Server Issues for serverside rules included with Bazel
Projects
None yet
Development

Successfully merging this pull request may close these issues.

proto_lang_toolchain and blacklisted_protos with ProtoInfo not propagated correctly
9 participants