Function / Macro Arguments in Compiler Tracers

[Jonatan Männchen]

Hi All,

I have recently had some issues with the Gettext library (the issues are irrelevant for this suggestion) and thought that maybe the Gettext Extraction could be rebuilt using compiler tracers.

The basic idea was to collect all modules and gettext calls via a compiler tracer and replace the existing extractor with that. (See example in Attachment)

However, there seems to be no way to access the args for a call for any of the following trace events: remote_function, remote_macro, local_function, local_macro.

Did I overlook something or is there currently no way to access the arg values?

If not, I think it could be a great addition to somehow make those values accessible.

I'm playing around for the first time with compiler tracers. Therefore I'm sorry if this request doesn't make sense or this is a completely wrong approach.

Thanks & Best,

Jonatan

[José Valim]

Hi Jonatan,

Yes, the tracer does not receive the macro arguments, but we did not have a use case for such either. The biggest concern is that we could allow tracers to evaluate and execute arguments and that’s a very risky line to cross.

Maybe this is the use case we were waiting for but then we would need to expand if this would actually be better than macros.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/a51ab9f7-30d3-4fa6-a7a3-b3653bc52470n%40googlegroups.com.

[Jonatan Männchen]

Hi José,

I'm not sure if this is the best way to do it. Looking through the existing extraction mechanism looked a bit "hacky" in my personal opinion. I thought I could reduce complexity very much using a compiler tracer.

The approach of the tracer feels right to me, since extracting and executing are not done in the same macros/functions. This would separate the two functionalities more and would lead to cleaner and more understandable code.

I value your opinion very much in this discussion, especially since I have no experience with the tracer. Do you think this might be a legit use case?

What are the risks, if a compiler tracer can evaluate/execute arguments?

I agree, that executing functions inside the users codebase might be unexpected to the user and should probably be discouraged except when the user is made aware of this fact. Reading "scalar" values however, should not be an issue.

For example, I think a static analyzer could greatly profit from evaluating arguments to a function. (one example could be sobelow checking what headers were passed to the "put_secure_headers" plug)

If you think this is a good idea, I would offer to actually work on this :)

Best,

Jonatan

[José Valim]

If the tracer can execute code, then the tracer can have side-effects, which may affect the value of the compilation. So we can put ourselves into a position where the thing meant to observe the system is now affecting the system. Of course we can say, "well, don't do that", but I think the value of adding such capability in the first place has to be really justified. Especially because the tracer already runs in the same process as the compilation.

Here is an idea you can try though. An event tracer is just traversing __CALLER__.tracers and sending an event. So you could change the gettext macro to send the event that you want:

    for trace <- __CALLER__.tracers do

      trace.event({:gettext, string}, __CALLER__)

    end

And now you can use tracers to collect the messages you need. This will at least allow you to assess if the functionality is indeed better.

However, my suspicion is that the approaches are not really different. Both are dispatching events somewhere and both are using mutable state to store them.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/0747ff1a-efd1-425f-a047-f5549b3c5f72n%40googlegroups.com.