This was the documented behaviour on 1.9 that was broken on v1.10: (version `git` is this branch)
$ cat a.ex
defmodule A, do: nil
$ for v in 1.9.4-otp-22 1.10.2-otp-22 git; do asdf local elixir $v && echo $v; elixir -e 'IO.inspect Code.compile_file("a.ex")'; done
1.9.4-otp-22
[{A, <<70, 79, ...>>}
1.10.2-otp-22
[{A, %{attributes: [], ...}]
git
[{A, <<70, 79, ...>>}
$ for v in 1.9.4-otp-22 1.10.2-otp-22 git; do asdf local elixir $v && echo $v; elixir -e 'IO.inspect Code.require_file("a.ex")'; done
1.9.4-otp-22
[{A, <<70, 79, ...>>}]
1.10.2-otp-22
[{A, %{attributes: [], ...}]
git
[{A, <<70, 79, ...>>}]
$ for v in 1.9.4-otp-22 1.10.2-otp-22 git; do asdf local elixir $v && echo $v; elixir -e 'IO.inspect Code.load_file("a.ex")'; done
1.9.4-otp-22
[{A, <<70, 79, ...>>}]
1.10.2-otp-22
warning: Code.load_file/1 is deprecated. Use Code.require_file/2 or Code.compile_file/2 instead
nofile:1
[{A, %{attributes: [], ...}]
git
warning: Code.load_file/1 is deprecated. Use Code.require_file/2 or Code.compile_file/2 instead
nofile:1
[{A, <<70, 79, ...>>}]
This tracer is used to validate that all modules being invoked
in an application belongs to an application that is currently
listed as a dependency. This will help enforce umbrella application
boundaries and help users discover when they depend on Elixir and
Erlang libraries without declaring them upfront.
Thanks to @sasajuric for the proof of the concept and insights
that made this feature possible.
Closes#9847.
We need it there so we can retrieve it like this:
defmacro sigil_E({:<<>>, meta, [expr]}, []) do
options = [
line: __CALLER__.line + 1,
indentation: meta[:indentation] || 0
]
EEx.compile_string(expr, options)
end
This makes it so we're always capturing delimiter metadata for sigils
instead of requiring the `token_metadata` option. This means that we can
now show the correct sigils in ExUnit diffs (and elsewhere) for code
examples.
Mix stores the compile_env in each applications' .app file.
Releases and Mix tasks were also changed to validate against
the runtime configuration against any stored `compile_env`.
In case of mismatches, an error is raised during boot.
There are many implications behind using Code.ensure_compiled?/1,
so we do not want to hide it behind a simple boolean check.
Instead use `Code.ensure_compiled/1` which is clearer about intent
and on return values.
This feature allows IDEs and other tools wanting to
perform source code analysis to do so reliably without
a need to reimplement Elixir's compiler expansion and
without relying on Elixir's private APIs.
This commit also adds :parser_options to compiler
options, which allows developers to combine both options
to retrieve more accurate information, such as columns.
This introduces five new metadata nodes:
* `do` - contains metadata about do location in a function call with
`do/end` blocks
* `end` - contains metadata about end location in a function call with
`do/end` blocks
* `closing` - contains metadata about the closing pair, such as a `}`
in a tuple or in a map, or such as the closing `)` in a function call
with parens
* `eol` - is set to true when the opening pair, such as `{` or `(`, are
followed by the end of the line
* `delimiter` - contains the opening for sigils (such as `"{"`, `"/"`,
etc)
Erlang/OTP 20 warns if the stacktrace is read outside of a
catch/rescue. This commit mirrors this behaviour by consistently
warning on `System.stacktrace/0` being used outside of a
catch/rescue.
Erlang/OTP 21 warns whenever System.stacktrace/:erlang.get_stacktrace
are used. Therefore we need to promote the usage of `__STACKTRACE__`
and make sure to conditionally compile it according to the OTP version.
This requires changes to the Exception normalization mechanism
so we compute `__STACKTRACE__` only when strictly required.
In future Elixir releases, `System.stacktrace/0` will warn when
used even inside catch/rescue.
Currently there is no way to compile a file without leaving
footprints on the system. Plus, the term load_file/2 is very
confusing as loaded is the notation used by modules.
This commit focuses the whole loaded aspect of files exclusively
on require_file/2 (and renames two functions accordingly) and
introduces compile_file/2 which is semantically simpler than
load_file/2.