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 <gjsdua...@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-core+unsubscr...@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-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BQn-5bf1Xe7jKO8kJh4mCCCO5U%2Bei70s9upZn5JfkMCA%40mail.gmail.com.
