prost-build 0.8.0 only adds final type_attribute

[tommilligan]

In prost-build 0.7.0, it was possible to add any number of type attributes, and all would be added to the generated struct. In the following minimal example:

// src/example.proto
syntax = "proto3";
package example;

message Example {
  string example_field = 1;
}

// build.rs
use prost_build::Config;

fn main() {
    let mut config = Config::new();
    config.type_attribute(".", "#[derive(Display)]");
    config.type_attribute(".", "#[derive(PartialOrd)]");
    config
        .compile_protos(&["./src/example.proto"], &["./src"])
        .unwrap();
}

Generates the following on prost-build 0.7.0:

#[derive(Display)]
#[derive(PartialOrd)]
#[derive(Clone, PartialEq, ::prost::Message)]
pub struct Example {
    #[prost(string, tag="1")]
    pub example_field: ::prost::alloc::string::String,
}

Note that all configured type_attributes are added in the order they are configured. However, with prost-build 0.8.0, the generated output is:

#[derive(PartialOrd)]
#[derive(Clone, PartialEq, ::prost::Message)]
pub struct Example {
    #[prost(string, tag="1")]
    pub example_field: ::prost::alloc::string::String,
}

Note that only the most recent type_attribute, PartialOrd, has been added.

This appears to be an unintentional breaking change, I expect introduced here: 79f0dfd#diff-5283c009c22e833ce65e3b8a6d7f57c026e0562f79225a9375f8e738ad4080c2R252-R260

I'll investigate further and see if I can submit a fix today.

[tommilligan]

Added a minimal example that fails to compile with cargo build here: https://github.com/tommilligan/prost-502-reproduction

[tommilligan]

After investigation, there appear two be two distinct changes introduced by the PathMap refactoring in 79f0dfd. They are:

• calls to type_attribute and field_attribute are no longer cumulative. Calling again with the same pattern key will overwrite any previously inserted attributes. This is in contradiction to the docs which state:

The calls to this method are cumulative. They don’t overwrite previous calls and if a type is matched by multiple calls of the method, all relevant attributes are added to it.

• only attributes from one of the matched patterns are applied. For instance with the following config and the example.proto file shown above:

use prost_build::Config;

fn main() {
    let mut config = Config::new();
    config.type_attribute(".", "#[derive(PartialOrd)]");
    config.type_attribute("Example", "#[derive(Ord)]");
    config
        .compile_protos(&["./src/example.proto"], &["./src"])
        .unwrap();
}

The following rust code is generated:

#[derive(Ord)]
#[derive(Clone, PartialEq, ::prost::Message)]
pub struct Example {
    #[prost(string, tag="1")]
    pub example_field: ::prost::alloc::string::String,
}

Note that only the attribute matched by the Example key is applied, even though the . should still match and be applied to all messages. Again this doesn't match what the docs indicate.

[Veetaha]

@danburkert, this seems like a serious regression that blocks us from updating to the new version and fixing the RUSTSEC advisory...

[kalzoo]

^ sorry to +1 this, but same - can't use 0.8 with this issue (and #507), which means no security patch, no latest tonic, etc. of course, it's open-source and free, and I appreciate all you've made! just a friendly heads up.

[horacimacias]

just in case this helps anybody else, in my case I was able to use a single attribute with line break to achieve two attributes

.type_attribute(".", "// first attribute\n// second attribute")

not ideal and likely not covering all scenarios but at least does the trick in certain cases.

[ryankurte]

if you need a temporary workaround (probably wouldn't ship it...) it seems you can also revert just the commit (7940dfd) introducing the regression (i got part way through combining type attributes but, we have a lot). something like this.

[cab]

I think this is either a duplicate of or related to #490. If so, I think this issue is more comprehensive, so it might be worth folding into this one.

[LucioFranco]

Fixed in #522