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 schrieb am Sonntag, 10. Oktober 2021 um 17:34:27 UTC+2: > 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. > > On Sun, Oct 10, 2021 at 17:20 Jonatan Männchen <maen...@joshmartin.ch> > wrote: > >> 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 >> >> -- >> 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 >> >> <https://groups.google.com/d/msgid/elixir-lang-core/a51ab9f7-30d3-4fa6-a7a3-b3653bc52470n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/0747ff1a-efd1-425f-a047-f5549b3c5f72n%40googlegroups.com.
