Fix #476: Ensure modules are loadABLE instead loadED #478
Conversation
elbrujohalcon
left a comment
There was a problem hiding this comment.
I like it!
Thanks, @sg2342 🫶
| false | ||
| ExportedRules = | ||
| try | ||
| Module:module_info(exports) |
There was a problem hiding this comment.
| Module:module_info(exports) | |
| erlang:get_module_info(Module, exports) |
To avoid using dynamic calls.
There was a problem hiding this comment.
Oh, I see… it fails if it's not loaded… 🤦🏻
We need a non-dynamic way of doing what module_info/1 does.
There was a problem hiding this comment.
Maybe…
| Module:module_info(exports) | |
| {ok, Module} = code:ensure_loaded(Module), | |
| erlang:get_module_info(Module, exports) |
…?
There was a problem hiding this comment.
erlang:get_module_info/2 is undocumented.
i think without resorting to beam_lib ... the only documented way to get the exported functions of a module is the dynamic call.
There was a problem hiding this comment.
Or maybe just change line 130 from {file, _} ?= code:is_loaded(Module), to {ok, Module} ?= code:ensure_loaded(Module),.
There was a problem hiding this comment.
Ohh, I thought I added this suggestion to that PR I will review how I missed it.
There was a problem hiding this comment.
Since the other 2 maintainers are OK with it, let's conclude that we should use:
- code:ensure_loaded
- dynamic call to get exports (with -elvis attribute to avoid it in elvis_core)
There was a problem hiding this comment.
I tested this locally and see no big issue in just replacing
- {file, _} ?= code:is_loaded(Module),
+ {module, _} ?= code:ensure_loaded(Module),and
- false ->
+ {error, _}There was a problem hiding this comment.
Ohh, I thought I added this suggestion to that PR I will review how I missed it.
@bormilan, it's not a big issue. I guess we got concentrated on conversation (the resolvable elements in the description) and since this was a "generic comment" it got lost. I should've payed more attention, too...
There was a problem hiding this comment.
Nope. And that's why I wrote #479. We can merge that one and generate releases 4.1.1 now…
| elvis_utils:warn_prn( | ||
| "Invalid module (~p) specified in elvis.config.~n", | ||
| [Module] | ||
| ), |
There was a problem hiding this comment.
Why are we avoiding this warning, though?
There was a problem hiding this comment.
Because the code (as it is in the PR right now) would not fail in that way… But… since we're going to use code:ensure_loaded/1, we can recover this.
There was a problem hiding this comment.
Gimme a few minutes so I can try to check this better. If you wanna move forward, it's also no biggie.
There was a problem hiding this comment.
Because the code (as it is in the PR right now) would not fail in that way… But… since we're going to use code:ensure_loaded/1, we can recover this.
I assumed we would, so best to ask 😄
| {invalid_rule, {elvis_style, what_is_this_rule}}, | ||
| {invalid_rule, {not_existing_module, dont_repeat_yourself}}, | ||
| {invalid_rule, {not_existing_module, dont_repeat_yourself}} |
fail config validation if:
Description
module_info(exports)(runtime will attempt to load the module) to get the list of exported functionselvis_SUITE:rock_with_invalid_rules/1Closes #476