Cool, I'll see if I can jot a proposal on a PR with a possible implementation. On Monday, July 12, 2021 at 2:25:52 PM UTC+1 José Valim wrote:
> I think this would be welcome but would we need special flags to control > the deps? And again, there is a huge disclaimer that this won't work for > rebar3 dependencies and similar. It may also be not very straightforward to > implement. > > > On Mon, Jul 12, 2021 at 3:12 PM Guilherme Duarte <gjsd...@gmail.com> > wrote: > >> No worries. Thanks for detailing it better. >> >> The benefit for the users would be the possibility to know where exactly >> the compilation errors are coming from. This would be especially useful >> when users use path dependencies. >> Perhaps it could be even be implemented as a path dependency-only >> feature. Although, I do think that *--return-errors *should never exit, >> but instead return a list of errors, as the documentation suggests. >> >> What do you think? >> >> On Monday, July 12, 2021 at 1:34:49 PM UTC+1 José Valim wrote: >> >>> Gabriel, sorry my question was not clear enough. What is the benefit for >>> users in this case? Why should an IDE should warnings from their deps in a >>> way that capturing stderr is not enough? >>> >>> On Mon, Jul 12, 2021 at 13:43 Guilherme Duarte <gjsd...@gmail.com> >>> wrote: >>> >>>> Hey José, >>>> >>>> Thanks for the quick response. >>>> The *mix deps.compile* diagnostic errors could be reported similarly >>>> to the *mix compile* ones. I believe the logic needed to decide if the >>>> location of the file where the error is being reported belongs to *deps >>>> *or to the developer's current source code could easily be handled by >>>> either *elixir-ls* or the editor. >>>> >>>> The fact that the task current eagerly exits is what makes removes all >>>> flexibility from being able to decide what to do with the errors at a >>>> later >>>> stage. >>>> >>>> On Monday, July 12, 2021 at 9:18:20 AM UTC+1 José Valim wrote: >>>> >>>>> Quick question: how would the errors in mix deps.compile be used in >>>>> the editor? How could that be useful? >>>>> >>>>> Also note that we won't be able to do this for all dependencies... so >>>>> for dependencies the best choice may be to capture stderr. >>>>> >>>>> On Sat, Jul 10, 2021 at 3:16 PM Guilherme Duarte <gjsd...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> *Proposal:* >>>>>> >>>>>> In order to facilitate the implementation of development tooling, >>>>>> such as *elixir-ls*, I propose the propagation of the *--return-errors >>>>>> *flag from Mix.Tasks.Compile to Mix.Tasks.Deps.Compile. >>>>>> >>>>>> With this, it would be possible to report diagnostic errors during >>>>>> dependency compilation. >>>>>> With the current behavior, the *mix compile --return-errors *task does >>>>>> an early exit when dependency compilation fails, making it extremely >>>>>> hard >>>>>> to report error reasons. >>>>>> >>>>>> This behavior change would be especially helpful when path >>>>>> dependencies exist. >>>>>> >>>>>> *Proposed Implementation:* >>>>>> >>>>>> In order to achieve this, the flag should be passed down from >>>>>> Mix.Tasks.Compile -> Mix.Tasks.Loadpaths -> Mix.Tasks.Deps.Loadpaths -> >>>>>> Mix.Tasks.Deps.Compile. >>>>>> Mix.Tasks.Deps.Compile.compile should then accumulate the diagnostics >>>>>> messages returned by Mix.Tasks.Compile for each compiled dependency, and >>>>>> the returned values propagated back up call tree to be reported by the >>>>>> original task invocation (mix compile --return-errors) >>>>>> >>>>>> Thanks for considering this! >>>>>> >>>>> -- >>>>>> 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/03daf960-dc81-4d76-b9b5-015d2e47e72bn%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/03daf960-dc81-4d76-b9b5-015d2e47e72bn%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-co...@googlegroups.com. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/elixir-lang-core/cac47a1c-c153-4cec-9dbb-bc43a6bb2192n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/elixir-lang-core/cac47a1c-c153-4cec-9dbb-bc43a6bb2192n%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-co...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/92d78373-6c4c-468c-a30b-869d1b1825fcn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/92d78373-6c4c-468c-a30b-869d1b1825fcn%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/765528ed-71ab-43ec-90b6-23a77cc7452cn%40googlegroups.com.
