`Ast_pattern` fails on attributes

[n-osborne]

Inspecting a construction containing a legal attribute fails with:

Fatal error: exception Attributes not allowed here

Reproduction case:

open Ppxlib

let ___bug =
  let loc = Location.none in
  let ast = [%expr x[@bug]]
  and prop _ = true and on_error () = false
  and pat = Ast_pattern.(pexp_ident __)
  in
  Ast_pattern.parse pat loc ast ~on_error prop

let () = if ___bug then print_endline "OK" else print_endline "KO"

[NathanReb]

Thanks for reporting this!

I'm a bit puzzled here, it seems that since the start of our github history, the generated patterns reject anything that has attributes.

I'd have to check but I assume the logic is that it's too easy to miss on important attributes when using Ast_pattern and that its use should be reserved for "controlled space" such as the payload of a ppx's extension, where you know exactly what attributes are present or not.

That being said I agree this is not an acceptable scenario on multiple accounts:

• It prevents users from writing more stable code using Ast_pattern in a lot of scenarios
• The failure mode is disastrous and can be extremely misleading to the end user (as opposed to the ppx author)
• We should provide variants that allow attributes and eventually that even allow you to capture/pattern match over them
• It seems a bit redundant with the unused attribute check that seems

I'll reached out to the original authors of ppxlib to make sure I have a complete understanding of the situation before deciding how to proceed here but this definitely needs some sort of fix!

Out of curiosity, can you describe in which context you encountered this bug? Why are you using Ast_pattern? Are the attributes here some you mean to consume yourself or are they unrelated to your ppx/program?

[n-osborne]

Out of curiosity, can you describe in which context you encountered this bug? Why are you using Ast_pattern? Are the attributes here some you mean to consume yourself or are they unrelated to your ppx/program?

It is in the context of a prototype for code instrumentation and using Ast_pattern here is for demonstration purpose. So that's pretty artificial I guess. Also I'm not at liberty to show the code.

The story is as follow:

• I have to instrument differently an expression depending on it containing an item of a certain type (think an identifier eg)
• A previous phase of the instrumentation could have introduced such an item
• But those should be ignored (they are not present in the original code on which the instrumentation should be based)
• I decide to watermark the items the instrumentation introduce with an attribute.
• The bug

Out of curiosity I wanted to see how testing is organised in this project, so I reproduced the bug in a test case in this branch.

[NathanReb]

So in your case, you might even want to write an Ast_pattern that extracts the identifier based on a specific attribute being present. That would not allow other attributes though so you might want to do it in two separate steps:

1. extract the identifier using Ast_pattern
2. check whether the attribute is present using Attribute.get_res and branch accordingly

Thanks for the input!