Same attribute can be matched by multiple ppxes.

[jaymody]

The following:

let () =
  let make_rule name =
    Context_free.Rule.attr_str_type_decl_expect
      (Attribute.declare
         name
         Type_declaration
         Ast_pattern.(pstr nil)
         (fun x -> x))
      (fun ~ctxt:_ _ _ _ ->
        let loc = Location.none in
        [ Ast_builder.Default.(pstr_eval ~loc (estring ~loc ("I am " ^ name)) []) ])
  in
  Driver.register_transformation
    "foobar"
    ~rules:[ make_rule "bar.foo"; make_rule "qux.foo" ];

Would allow:

type t = int [@@bar.foo]
"I am bar.foo"
[@@@end]

type u = int [@@qux.foo]
"I am qux.foo"
[@@@end]

type v = int [@@foo]
"I am bar.foo";;
"I am qux.foo"
[@@@end]

It seems that ppxlib doesn't protect against an attribute from being matched by two (or more) different Attribute.t declarations in instances when the name is ambiguous. The same issue exists for Attribute.Floating.ts.

[NathanReb]

I wonder how much of a problem that actually is. Aside from the ambiguity to the user, it does not seem to be particularly harmful.

Do you have an example of a concrete issue this has lead to? Do you think fixing this a prerequisite to releasing #560 ?

I want to clarify that I'm not saying we should necessarily keep this behaviour, I'm simply trying to assess the implications.

[jaymody]

The concrete issue here would be that some ppxes may decide to use their own [@@@myppx.end] attribute. In such cases, [@@@end] would get interpreted for both myppx and as deriving.end.

Users can always temporarily work around this by forcing their [@@@myppx.end] to be fully qualified, but thought I'd just file an issue to document this bug, if ever it becomes more relevant to fix in the future.

I don't think this is blocking for releasing #560.