hm… I'm pretty sure that this issue exists for `defimpl` in the new code that you've added.
``` defmodule Foo.Bar.Baz ( http://foo.bar.baz/ ) do end alias Foo.Bar.Baz ( http://foo.bar.baz/ ) defimpl Proto, for: Baz do def foo(_thing), do: 10 end ``` will show an `unused alias Baz` warning. On Mon, Jul 11, 2022 at 1:48 PM, Zach Daniel < [email protected] > wrote: > > Interesting…I'll do some spelunking and try to figure out why `defimpl` > doesn't yield the same unused alias warnings that my code does then > > > > > > ``` > > defmodule Foo. Bar. Baz ( http://foo.bar.baz/ ) do > > end > > > > alias Foo. Bar. Baz ( http://foo.bar.baz/ ) > > > > defimpl Proto, for: Baz do > > def foo(_thing), do: 10 > > end > > ``` > > > > > On Mon, Jul 11, 2022 at 1:42 PM, José Valim < jose. valim@ dashbit. co ( > [email protected] ) > wrote: > >> In this case you pass lexical_tracker: nil indeed, that's what we do for >> defimpl for now, although it is a private API for now. >> >> >> On Mon, Jul 11, 2022 at 7:08 PM Zach Daniel < zachary. s. daniel@ gmail. com >> ( [email protected] ) > wrote: >> >> >>> So I tried out doing the same thing that you are currently doing in >>> `expand_literal/2` and I've hit a snag. >>> >>> In the Ash DSL, there are some module references where we don't want to >>> incur a runtime dependency *or* a compile time dependency. From what I can >>> tell, the pattern of `expand_literal/2` still incurs runtime dependencies. >>> In Ash, we have this code: >>> >>> ``` >>> def expand_alias(ast, %Macro.Env{} = env) do >>> Macro.prewalk(ast, fn >>> {:__aliases__, _, _} = node -> >>> Macro.expand(node, %{env | function: {:__ash_placeholder__, 0}}) >>> >>> other -> >>> other >>> end) >>> end >>> >>> def expand_alias_no_require(ast, %Macro.Env{} = env) do >>> Macro.prewalk(ast, fn >>> {:__aliases__, _, _} = node -> >>> Macro.expand(node, %{env | lexical_tracker: nil}) >>> >>> other -> >>> other >>> end) >>> end >>> ``` >>> >>> which models the difference between how we are currently doing things. The >>> primary issue here is that the things using `expand_alias_no_require/2` >>> currently are marked as unused alias, and from what I can tell >>> `expand_literal/2` doesn't solve for that issue. >>> On Monday, May 9, 2022 at 4:33:58 PM UTC-4 Zach Daniel wrote: >>> >>> >>>> Awesome, thanks! >>>> >>>> >>>> >>>> >>>> On Mon, May 09, 2022 at 4:10 PM, José Valim < jose.... @ dashbit. co > >>>> wrote: >>>> >>>> >>>> >>>>> It should be added when I fix this: https:/ / github. com/ elixir-lang/ >>>>> elixir/ >>>>> issues/ 11706 ( https://github.com/elixir-lang/elixir/issues/11706 ) :) >>>>> >>>>> >>>>> >>>> >>>> >>>>> On Mon, May 9, 2022 at 8:02 PM Zach Daniel < zachary. s. daniel@ gmail. >>>>> com >>>>> > wrote: >>>>> >>>>> >>>> >>>> >>>>> >>>>>> That sounds perfect! Is there any place that I can see what that public >>>>>> API will look like? I totally understand on being careful in that regard. >>>>>> Since Ash DSLs are more like static configuration, there are a few places >>>>>> where this is acceptable, but we don't use it for every (or even most) of >>>>>> the places where a module name might be. >>>>>> >>>>>> >>>>>> On Monday, May 9, 2022 at 2:00:11 PM UTC-4 José Valim wrote: >>>>>> >>>>>> >>>>>>> Btw, we will also have a public API on Elixir v1.14 for expanding >>>>>>> literals, so the problem shall disappear altogether. However, you must >>>>>>> be >>>>>>> extremely careful: this should only be used if you indeed don't use it >>>>>>> at >>>>>>> compile time. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, May 9, 2022 at 7:56 PM Zach Daniel < zachary.... @ gmail. com > >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> Also, I forgot to mention, it was @icecreamcohen on discord who had the >>>>>>>> idea that redefining alias may work (although they didn't really >>>>>>>> condone >>>>>>>> it), don't want to take credit for anyone elses ideas though. >>>>>>>> On Monday, May 9, 2022 at 1:53:50 PM UTC-4 Zach Daniel wrote: >>>>>>>> >>>>>>>> >>>>>>>>> This is something coming from a compile time optimization that Ash >>>>>>>>> Framework does. >>>>>>>>> >>>>>>>>> In an Ash resource there is something called a change its basically >>>>>>>>> like a >>>>>>>>> plug but it operates on an Ash.Changeset >>>>>>>>> >>>>>>>>> So you might see something like this: >>>>>>>>> ``` >>>>>>>>> # in the resource >>>>>>>>> actions do >>>>>>>>> create :create_with_employee do >>>>>>>>> change MyApp.CreateEmployee >>>>>>>>> end >>>>>>>>> end >>>>>>>>> # the change module >>>>>>>>> defmodule MyApp.CreateEmployee do >>>>>>>>> use Ash.Resource.Change >>>>>>>>> >>>>>>>>> def change(changeset, _opts, _context) do >>>>>>>>> Ash.Changeset.after_action(changeset, fn _changeset, result -> >>>>>>>>> MyApp.Employee.create!(result.stuff, ...) >>>>>>>>> end) >>>>>>>>> end >>>>>>>>> end >>>>>>>>> >>>>>>>>> Now, the change itself, when it comes to the resource, is simple >>>>>>>>> static >>>>>>>>> configuration. It cannot affect the compilation of the resource nor >>>>>>>>> should >>>>>>>>> any thing doing metaprogramming at compile time leverage the >>>>>>>>> internals of >>>>>>>>> that change >>>>>>>>> >>>>>>>>> Something that changes do often is refer to other related resources, >>>>>>>>> like >>>>>>>>> in this example case. So we drastically increase the surface area for >>>>>>>>> transitive compile time dependencies >>>>>>>>> >>>>>>>>> >>>>>>>>> Because a runtime dependency in one link becomes a compile time >>>>>>>>> dependency >>>>>>>>> when chained down the road. I.e I depend on the source resource, call >>>>>>>>> it >>>>>>>>> Post at compile time, and Post depends on Employee now at runtime, so >>>>>>>>> I >>>>>>>>> now depend on Employee at compile time. >>>>>>>>> >>>>>>>>> So to help people with their compile times, I've added some >>>>>>>>> metaprogramming magic that does the following (only in very specific >>>>>>>>> places for specific options) Macro.expand(node, %{env | >>>>>>>>> lexical_tracker: >>>>>>>>> nil}) and it works, no more unnecessary dependency. however, if you do >>>>>>>>> this: >>>>>>>>> ``` >>>>>>>>> alias MyApp.CreateEmployee >>>>>>>>> create :name do >>>>>>>>> change CreateEmployee >>>>>>>>> end >>>>>>>>> ``` >>>>>>>>> it yells at you for not using the alias, because I just disabled the >>>>>>>>> thing >>>>>>>>> that would inform the compiler that the alias was used >>>>>>>>> >>>>>>>>> I don't necessarily want to add back in those unnecessary compile time >>>>>>>>> increases, so I'm looking for a way to detect that an alias had been >>>>>>>>> used >>>>>>>>> in these cases, and produce a compiler warning if you didn't add warn: >>>>>>>>> false to the alias, that way you don't get a confusing "alias not >>>>>>>>> used" >>>>>>>>> error, you get (well, I guess you get both) an explanation of why the >>>>>>>>> alias wasn't used and instructions to add warn: false to fix it. >>>>>>>>> >>>>>>>>> >>>>>>>>> The options I have so far: >>>>>>>>> >>>>>>>>> 1. redefine `alias` and default to `warn: false` >>>>>>>>> 2. redefine `alias` and track which ones have `warn: false` and print >>>>>>>>> a >>>>>>>>> warning if its used in one of these instances, so they can add it >>>>>>>>> 3. if I detect that an alias is used, raise an error at compile time >>>>>>>>> and >>>>>>>>> say that aliases aren't supported here >>>>>>>>> 4. get something in elixir core that allows explicit control to add >>>>>>>>> something to an explicit list of "used aliases" >>>>>>>>> >>>>>>>>> Looking at the code for the lexical_tracker, it could be as simple as >>>>>>>>> tracking a separate list of explicitly provided modules, or it could >>>>>>>>> be a >>>>>>>>> different mode of reference, i.e `:compile` `:runtime` or `:ignore`, >>>>>>>>> that >>>>>>>>> kind of thing. >>>>>>>>> >>>>>>>>> Also, if there is another way to accomplish the goal here I'm open to >>>>>>>>> suggestions. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 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/ >>>>>>>> f8e4ed44-f3a8-41cc-b82c-f6175ea461fdn%40googlegroups. >>>>>>>> com ( >>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/f8e4ed44-f3a8-41cc-b82c-f6175ea461fdn%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+unsubscribe@ googlegroups. com. >>>>> >>>>> >>>>> >>>> >>>> >>>>> >>>>>> >>>>>> To view this discussion on the web visit https:/ / groups. google. com/ >>>>>> d/ >>>>>> msgid/ elixir-lang-core/ >>>>>> a249ae72-fc35-4ff2-be69-567aa53ceb87n%40googlegroups. >>>>>> com ( >>>>>> https://groups.google.com/d/msgid/elixir-lang-core/a249ae72-fc35-4ff2-be69-567aa53ceb87n%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+unsubscribe@ googlegroups. com. >>>>> To view this discussion on the web visit https:/ / groups. google. com/ d/ >>>>> msgid/ elixir-lang-core/ >>>>> CAGnRm4Lue_uJZdyChHFL_crrW6PVARBFUzm%3DvS5mmPGSSTFi9A%40mail. >>>>> gmail. com ( >>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4Lue_uJZdyChHFL_crrW6PVARBFUzm%3DvS5mmPGSSTFi9A%40mail.gmail.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+unsubscribe@ googlegroups. com ( >>> [email protected] ). >>> To view this discussion on the web visit https:/ / groups. google. com/ d/ >>> msgid/ elixir-lang-core/ >>> 136de6d8-f330-4135-8549-3ad70767a0efn%40googlegroups. >>> com ( >>> https://groups.google.com/d/msgid/elixir-lang-core/136de6d8-f330-4135-8549-3ad70767a0efn%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+unsubscribe@ googlegroups. com ( >> [email protected] ). >> To view this discussion on the web visit https:/ / groups. google. com/ d/ >> msgid/ elixir-lang-core/ >> CAGnRm4JFV6XO-3QsYYTCyFDSCUx%2BZvk8WNWYF3-HTE-ksnuC3Q%40mail. >> gmail. com ( >> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JFV6XO-3QsYYTCyFDSCUx%2BZvk8WNWYF3-HTE-ksnuC3Q%40mail.gmail.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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/l5h31mlq.8b02b89a-781a-410a-9f22-50c707b5e571%40we.are.superhuman.com.
