Accommodate Starlark reserved keywords as Protobuf message field names

[LINKIWI]

The Protobuf language permits identifiers that are reserved in Starlark, like pass. Consider, for example:

package foo;

message Foo {
    bool pass = 1;
}

There is currently no way to express this in Skycfg, since this is (correctly) flagged as a Starlark syntax error. For example:

foopb = proto.package("foo");

def main(ctx):
    return [
        foopb.Foo(pass = True),
    ]

got pass, want primary expression

Language-specific Protobuf code generation plugins typically work around such collisions by suffixing identifiers with an underscore. This PR proposes using the same convention to enable use of such reserved keywords as attribute names when creating Protobuf messages in Skycfg.

This enables the above example to be expressed as:

foopb = proto.package("foo");

def main(ctx):
    return [
        foopb.Foo(pass_ = True),
    ]

Verification

I updated the unit tests.

$ bazelisk test //...
INFO: Invocation ID: 2aa156b0-26c2-4577-a35e-51ba751a7d18
Analyzing: 14 targets (15 packages loaded, 2996 targets configured)
INFO: Analyzed 14 targets (93 packages loaded, 7937 targets configured).
INFO: Found 8 targets and 6 test targets...
INFO: Elapsed time: 148.927s, Critical Path: 26.24s
INFO: 358 processes: 25 internal, 333 linux-sandbox.
INFO: Build completed successfully, 358 total actions
//:skycfg_test                                                           PASSED in 0.1s
//go/assertmodule:assertmodule_test                                      PASSED in 0.1s
//go/hashmodule:hashmodule_test                                          PASSED in 0.3s
//go/protomodule:protomodule_test                                        PASSED in 0.1s
//go/urlmodule:urlmodule_test                                            PASSED in 0.3s
//go/yamlmodule:yamlmodule_test                                          PASSED in 0.4s

Executed 6 out of 6 tests: 6 tests pass.

[CLAassistant]

All committers have signed the CLA.

[LINKIWI]

@seena-stripe @dl-stripe Apologies for the direct tag; would one of you be the right person to review this change? Thanks.

[sushain-stripe]

@LINKIWI Are these PRs still something you're interested in landing? If so, please rebase them and i'm happy to review. Sorry for the (extreme) delay.

[LINKIWI]

@LINKIWI Are these PRs still something you're interested in landing? If so, please rebase them and i'm happy to review. Sorry for the (extreme) delay.

Hi, thanks for the reply. Yes, we've been running these patches in production internally for about a year now, and it would be great if we could get these upstreamed as well. I've rebased #119, #120, and #121. Thanks!

[sushain-stripe]

Hm, do these work today? Little concerned that this is technically a breaking change.

[LINKIWI]

I tried a couple of these and it doesn't seem to work today.

message Foo {
    ...
    string import = ...;
}

pb.Foo(import = "a")

message Foo {
    ...
    string as = ...;
}

pb.Foo(as = "a")

For these cases, the evaluation error is: got illegal token, want binary expression

[sushain-stripe]

Ok!

[sushain97]

@LINKIWI , would you like to add yourself to CONTRIBUTORS as part of this PR?

[LINKIWI]

@LINKIWI , would you like to add yourself to CONTRIBUTORS as part of this PR?

Sure

[timothyg-stripe]

@LINKIWI just to dot the i's: who's the copyright holder of this change? Yourself

Kevin Lin <developer@kevinlin.info>

or an employer?

[LINKIWI]

@LINKIWI just to dot the i's: who's the copyright holder of this change? Yourself

Kevin Lin <developer@kevinlin.info>

or an employer?

The copyright holder is me.