Skip to content

Fix import option emitted as a regular dependency - #792

Merged
emcfarlane merged 4 commits into
mainfrom
ed/fixOptionDependency
Nov 10, 2026
Merged

emcfarlane merged 4 commits into
mainfrom
ed/fixOptionDependency

Conversation

@emcfarlane

Copy link
Copy Markdown
Contributor

When an option import publicly imports a file that another import also brings in, the experimental compiler cleared the option import's flag. The file was then written to dependency instead of option_dependency, and it lost its options-only restriction. For example:

// a.proto
import "other.proto";      // other.proto has `import option "b.proto"`
import option "b.proto";   // b.proto has `import public "c.proto"`

protoc emits option_dependency: ["b.proto"]. We emitted dependency: ["other.proto", "b.proto"]. Edition 2026 makes this common, because google/protobuf/json_options.proto publicly imports json_enumvalue_options.proto.

The cause was not enough details in the flags to handle this case. Both to record how the dependency was imported and whether it is restricted to options. New field dependency is true when a file is reachable through a non-option import. Which is either directly, or through that import's public export. Visibility checks now use dependency.

Comment thread experimental/ir/ir_imports.go Resolved
Comment thread experimental/ir/ir_imports.go Resolved
@emcfarlane
emcfarlane enabled auto-merge (squash) November 10, 2026 09:43
@emcfarlane
emcfarlane merged commit 2974fbc into main Nov 10, 2026
12 of 16 checks passed
@emcfarlane
emcfarlane deleted the ed/fixOptionDependency branch November 10, 2026 10:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants