Warn if directive is not applicable

[RomainMuller]

Some directives may be present in AST places where they are actually inert. This may come as a surprise to the user, and should probably at least result in issuing a compilation time warning.

For example, applying //dd:span on something that is not a function node will do nothing.

[joobisb]

Hi @RomainMuller,

I would like to work on this issue.

First of all, I really loved the tech and the thought process behind orchestrion(AOP) and thanks to you and the team at DataDog for all the hard work behind this.

I did take a look at the code base and do have some questions, couldn't find this in the docs.

1. How can I debug and test this in local env?

   I tried building orchestrion binary locally and feeding the samples dir as below by enabling debug/trace logs

    go build .
    cd samples
    ../orchestrion go build -work ./...
   

   Is this the right way to go about it?

2. Does the build cache include the modified files ?

   I can see the modified files with traces added for dep such as net/http, gorm et al. in the $WORK dir, but I couldn't see the modified files for main.go and other_handlers.go when I ran orchestrion for samples/server

3. What role does the jobserver aka NATS play in this?

[RomainMuller]

Hey @joobisb

1. How can I debug and test this in local env?

You should be able to use the snapshot tests for this... in particular go test ./internal/injector -update (these are implemented using golden).

2. Does the build cache include the modified files ?

If there is no modified file in $WORK then no file has been modified. It's possible some of these files no longer incur modifications because the instrumentation is done library-side.

3. What role does the jobserver aka NATS play in this?

The jobserver's role is to prevent duplicate effort at large...

• It caches the value of the version string addendum that is appended to the output of -V=full invocations of the tools (which go uses to determine the complete -buildid, one of the inputs to the build artifact cache, so that orchestrion instrumented objects are separate to the regular objects); as this can be a little expensive to compute
• It does importPath -> package archive resolution for injected dependencies, so that these are done exactly once (preventing the possibility that 2 resolutions of the exact same package happen in parallel, which is a waste of time/resources).