Comment author: @alainfrisch

In a "let-and" sequence of bindings, each binding gets its own attributes, as in:

let x = 1 [@@foo] and y = 2 [@@bar];;

So in your example, you'd need to repeat the attribute four times as well.

Comment author: @whitequark

I see. This is still much more convenient (and less invasive) than surrounding the whole body in parentheses or begin..end.

Comment author: @alainfrisch

I tend to agree, although current workarounds aren't too bad:

include struct
...
end [@ocaml.warning "-3"]

(attribute on the module expression)

or:

include struct [@@@ocaml.warning "-3"]
...
end

(floating attribute scoped to the current structure)

Comment author: @whitequark

I wrote a patch and a test (I don't know where to put the test and there are no tests for ocaml.warning already; it can be just run with ocamlc test.ml.)

The patch handles [@@ocaml.warning] on values, modules, module types and includes. The patch doesn't handle [@@ocaml.warning] on types, because most warnings on types are about unused types or constructors and they're ran delayed and thus aren't affected by the attribute anyway, and classes and class types, because I'm not smart enough to modify Typeclass.

Anyway this is an incomplete implementation that's less incomplete than the current incomplete implementation, so it should be good.

Comment author: @whitequark

Actually, the deprecation warning also appears on types, so [@@ocaml.warning] could be useful there, but Typedecl is as inextricable as Typeclass. I give up on it.

Comment author: @gasche

You could create a subdirectory tests/ppx-attributes in testsuite/, and imitate what is done in the other directories (the simplest thing to use is Makefile.several, but you might be interested in defining test validation in terms of what happens when the input is passed to the toplevel (Makefile.toplevel) instead of compiled).

Comment author: @whitequark

It doesn't matter; it works just as well at toplevel. Would that be simpler?

Comment author: @gasche

In my experience toplevel tests are a bit less robust, so if both options work for the things you want to test I'd recommend avoiding them.

Comment author: @whitequark

I've updated the patch to include tests.

Comment author: @gasche

There is no need to save the warning scope if the attributes do not concern warning (which I believe is the most common situation), but your with_warning_attributes interface allows to optimize that easily if that was ever found to be a concern.

I like the patch.

Comment author: @gasche

Patch merged in trunk.