Interplay between compiler inlining and -nifs

[josevalim]

Describe the bug

Today it is possible to inline functions declared as NIFs but the behaviour may not be intuitive:

-module(foo).
-compile(export_all).
-compile({inline, bar/0}).
-nifs([bar/0]).

bar() ->
  erlang:nif_error(oops).

baz() ->
  bar(),
  ok.

In the following code, even if a NIF is loaded for bar(), baz() will inline erlang:nif_error(oops). One could argue the behaviour is obvious. Others could argue it is surprising. Should we warn about it?

A similar problem exists with -compile(inline):

-module(foo).
-compile(export_all).
-compile(inline).
-nifs([bar/0]).

foo() ->
  erlang:load_nif("foo", "bar").

bar() ->
  erlang:nif_error(omg).

baz() ->
  bar(),
  ok.

In this case, although a inlining happens, a warning is also emitted:

foo.erl:7:3: Warning: inlining is enabled - local calls to NIFs may call their Erlang implementation instead
%    7|   erlang:load_nif("foo", "bar").
%     |   ^

Given the -nifs attribute exists, this could probably be improved to inline all functions, except the ones listed on NIFs.

I am not sure if any of these behaviours are desired, so feel free to close this. Happy holidays! 🎄 🍾

Affected versions

As far as I know all of them, but especially after OTP 25, since that's when -nifs was added.

[michalmuskala]

I think it should be an error to have an inline attribute for a function also marked as nif - it can effectively never work correctly. Those functions should also be skipped for inlining with a plain -compile(inline) attribute for the same reason - I don't think the warning is enough, since there's no way to fix it other than completely disabling the optimisation for the whole module.