Skip to content

Conversation

@whatyouhide
Copy link
Member

On the road to #5388.

I'm on the fence on what to do with :elixirc_options here, since they're not set and changed here. Not sure where would be the best place to validate those 😕

@josevalim
Copy link
Member

Regarding elixirc_options, I would validate them in the same place, even if they are used downstream. There is a chance Code.compiler_options/1 already validate them too.


defp assert_valid_elixirc_paths(paths) do
unless is_list(paths) do
Mix.raise ":elixirc_paths should be a list of paths, got: #{inspect(paths)}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we say ":elixirc_paths in project configuration should be...."?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about that but if we get here I think users had to explicitly use :elixirc_paths so they likely know where it comes from?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point. It will fail as soon as they set it to a wrong value, so we should be good.

@whatyouhide
Copy link
Member Author

@josevalim since I merged #5472 should we go ahead and merge this one as well? The compiler options should be covered.

@josevalim josevalim merged commit f091c60 into elixir-lang:master Nov 21, 2016
@josevalim
Copy link
Member

❤️ 💚 💙 💛 💜

@whatyouhide whatyouhide deleted the better-validation-in-mix-compile-elixir branch November 21, 2016 10:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants