Bot releases are visible (Hide)
Published by KronicDeth almost 6 years ago
runWriteAction
when adding new JDKs in Small IDES
:crypto
wasn't in the default module filters even though its NIFs can't be interpreted.
defmodule
in distillery broke the GoTo Symbol contributor.
alias __MODULE__, as: Mod
did not work for resolving references through Mod
.
deps
are properly marked as Libraries and no longer count as being in the project scope for the Go To tools.in_umbrella
is used, the Project Module for each apps/#{APP_NAME}
will be marked a dependency,deps
and the _build/#{MIX_ENV}/lib/#{DEP_NAME}
will be marked as Excluded, so that Libraries appear in External Libraries at the bottom of the Project Pane.New ModuleName index keeps track of only the names of modulars:
It is used to power gotoClassContributor for Go To Class action.
commit
and override
for Mix.Dep
. - @KronicDeth
.eex
to .ex
and .exs
for accepted file extensions used to hyperlink files in stacktraces. - @KronicDeth
alias __MODULE__, as: Mod
Mod
in alias __MODULE__, as Mod
Mod
__MODULE__
in alias __MODULE__
defmodule MyModule
that is enclosing __MODULE__
.ProcessCanceledException
for runIde
gradle task, to allow for easier manual testing of completion and Go To actions during development.Mod.
after alias __MODULE__, as: Mod
.alias
calls in presentations, like "Choose Declaration" pop up for Go To Declaration.
__MODULE__
name (alias MyModule
) when using alias __MODULE__
.alias MyModule, as: Mod
when listing Mod
in alias __MODULE__, as Mod
.cover
for test coveragedoc
for ex_doc
logs
for log filesassets/node_modules/phoenix
for phoenix
assets/node_modules/phoenix_html
for phoenix_html
vMAJOR.MINOR.PATCH-pre+YYYYMMDDHHMMSS
) from master
branch
null
useCall
as __MODULE__
dependency. - @KronicDeth
LibraryTable#removeLibrary
in write action.Library#modifiableModule#commit
in write action.Mix.Dep
has already been seen to prevent recursive loops. - @KronicDeth
inspect
ExUnit failure reason
as ##teamcity
message
..formatter.exs
input globs would not match file paths because it was default that needed lib
on top and not version-dependent paths used in resources/exunit
.:excluded
and :skipped
(added in elixir-lang/elixir#7245) to testIgnored
teamcity message, thereby restoring ignored test counts and markers from Elixir 1.6.initComponent
time in DepsWatcher
or mix.Watcher
, the child directories of the project basedDir
aren't shown in the Project Pane until a change is applied in Project Structure.invokeAndWait
instead of invokeLater
to ensure order of syncs.defmodule
, check that it is an ancestor of the entrance of the ResolveState
, so that nested sibling modules are not scanned for potential call definition clauses, but only the outer module of the entrance. - @KronicDeth
org.elixir_lang.debugger.settings.stepping.module_filter.editor.table.Model.getValueAt
, so we can detect if there is an off-by-1 error. - @KronicDeth
@2x
and @3x
SVG icons that render wrong size in 2018.3 EAP. - @KronicDeth
TeamCityExUnitFormatting
reason
was completely unused.details
should have been used.flushBufferBeforeTerminating
was deprecated and in newer IntelliJ the call to processStatuses
does not occur unless flushBufferOnProcessTermination
is also overridden.== Compilation error
in STDOUT
as ERROR
for ExUnit reporter(CompileError)
of a test file to test failure. The "Test framework quit unexpectedly" is converted to a failed run with a single test with the compilation error as the failure message.defmodule
macro as module definition (as occurs in @bitwalker's distillery's Mix.Tasks.Release.Init.MixMock
AllName
VERSION
to re-index and drop bad call definition head from #1301.mix test
does not work, so log those compilation errors as normal build messages instead. - @KronicDeth
:crypto
by default: :crypto
includes NIFs that can't be reloaded and so kills the debugger. - @KronicDeth
null
containingFile
for modular names during completion. - @KronicDeth
syncPublisher(JDK_TABLE_TOPIC)
in invokeLater
runWriteAction
. - @KronicDeth
apps
or deps
directories or subdirectories change. - @KronicDeth
Builds on master
will produce pre-release builds of format NEXT_VERSION-pre+YYYYMMDDHHMMSS
.
You will need to add the canary
repository once to your IDE:
canary
URL: https://plugins.jetbrains.com/plugins/list?channel=canary&pluginId=7522
With the canary
repository setup:
Published by KronicDeth almost 6 years ago
Published by KronicDeth almost 6 years ago
Published by KronicDeth almost 6 years ago
Published by KronicDeth almost 6 years ago
Published by KronicDeth almost 6 years ago
Published by KronicDeth almost 6 years ago
Published by KronicDeth almost 6 years ago
Published by KronicDeth almost 6 years ago
Published by KronicDeth almost 6 years ago
Published by KronicDeth almost 6 years ago
Published by KronicDeth almost 6 years ago
Published by KronicDeth about 6 years ago
use AnAlias
calls
AnAlias
will be resolved to its modular (module, implementation, or protocol)__using__
macro in the modular is found__using__
is checkedIf it is a quote
block, check for call definitions recursively inside the block
If it is an apply/3
call
modular
This handling is what specifically makes use MyAppWeb, :controller
in Phoenix apps now work.
If it is a general call
Ctrl+Cmd+Up
) can be used to Go To the decompiled Module or call definitions when on a source modular (defimpl
, defmodule
, or defprotocol
) or callable (def
, defp
, defmacro
, defmacrop
). This somewhat restores the ability to go to both source and decompiled module and calls before 9.0.0, but now the source is preferred for Go To Declaration and the decompiled will only be available if there is no source and if you definitely want decompiled, you'll need to use Go To Related.CONTRIBUTING.md
, so IntelliJ plays nice. - @sfat
var
in var[key]
) to variables or 0
-arity calls.
var[key]
).name/arity
) is no longer shown if the Call Definition Clause is also included. This isn't a large loss because the /arity
was not searchable and only part of the presentation.<protocol>.<for>
)./1
and /2
, for example.Module.function(...)
where Module
is an alias does not return the decompiled version of Module
when the source is available. - @KronicDeth
import
s.
?.let
I accidentally hid the if
from running when there was no ENTRANCE_CALL_DEFINITION_CLAUSE
, so the correct form is add if there is no entrance or if there is a non-equivalent entrance.Go To Related is like Go To Declaration, but more general, for anything that is related to an element, but not its declaration.
In IntelliJ Elixir, Go To Related can be used to go to the decompiled version of a modular (defimpl
, defprotocol
, or defmodule
) or a callable (def
, defp
, defmacro
, defmacrop
) definition.
EExTest.Accounts
in defmodule EExTest.Accounts do
Ctrl+Cmd+Up
get_user!
in def get_user!(id)
Ctrl+Cmd+Up
Published by KronicDeth about 6 years ago
Decimal.base10?
could not resolve its enclosing modular
pluginIcon
compatibility with IntelliJ IDEA 2018.3. - @KronicDeth
Enum.reduce
for enclosing macro call. - @KronicDeth
.beam
modules was lost because Small IDEs don't index SDKs, but only External Libraries, so add Application-wide External Libraries for SDKs when they are created (and update, remove on edit or delete), which are then added as a Dependency for the facet's module when the SDK is set for the Small IDE project.
Use #AEB9C0 for JetBrains Default/Light Gray. Use #87939A for JetBrains Darcula Gray. Colors based on IntelliJ's color picker picking its own colors.
Icon matching testing done under both themes in 2018.2.1. Weirdly, the colors are different in the SVGs in my intellij-community@master. Hopefully, this doesn't mean the colors change again in 2018.3.
createLibrary
inside runWriteAction
.Published by KronicDeth about 6 years ago
getPresentation
quote
inside a literal [head | tail]
list code not be parsed to find the parent modular.
@
was allowed in atoms, but not atom keyword keys.
eachEbinPath
did not restrict itself to directories and blow up on files.
Module.aliasedName
still contained assert
even though it uses Normalized
to protect from PsiError
s.
Unaliased.down
did not have a useful error message
console
, foreground
, etcconsole
)erl
arguments (ERL_OPTS
)elixir -extra
arguments (EXTRA_OPTS
)CODE_LOADING_MODE
)RUNNER_LOG_DIR
)REPLACE_OS_VARS
)sys.config
file (SYS_CONFIG_PATH
)RELEASE_CONFIG_DIR
)PIPE_DIR
)console
because it uses an iex
-like shell.iex
console with proper PTY support (colors, tab completion, history)iex
argumentserl
argumentselixir
with colorselixir
argumentserl
argumentsmix
tasks getting expanded options to match the new configurations
mix
arguments, which used to be called "Program Arguments" (I figured out how to customize that name. 😉)elixir
argumentserl
argumentsiex -S mix
mix
argumentsiex
argumentserl
argumentsmix test
mix test
arguments, which used to be called "Program Arguments"elixir
argumentserl
argumentsmix
-based configurations.credo
inch_ex
earmark
ex_doc
Add all OTP 21 opcodes to disassembler. Previous opcode set was
frozen prior to OTP 21 release and missed some later additions.
number | name | Added |
---|---|---|
160 |
build_stacktrace |
Before OTP 21 release |
161 |
raw_raise |
Now |
162 |
get_hd |
Now |
163 |
get_tl |
Now |
_<elixirVariableName>@<counter>
while Elixir 1.6 used V<elixirVariableName>@<counter>
elixir_erl
record and %Macro.Env{}
, which changed how :elixir.quoted_to_erl
needed to be called.2018.2
to 2018.2.1
in build matrix. - @KronicDeth
...
for module name when Dbgi
has no module name as happens for instrumented modules from IEx.break/4
. - @KronicDeth
callDefinitionClause
is non-null
. - @KronicDeth
QuotableKeywordPair
- @KronicDeth
TerminalExecutionConsole
itself echos input in 2018.2
and 2018.2.1
, which was introduced in https://github.com/JetBrains/intellij-community/commit/fd7bbd0cb7f3c2a5add8872e0e6c5172be5f074a#diff-5acc2eb2e78fe52d7458d4a48b0eac9f, but it was reverted in JetBrains/intellij-community@5f4465b, so this uses that version to maintain compatibility across supported versions. - @KronicDeth
Phoenix.Router.Helpers
, a quote
block appears as the head of [head | tail]
list, so add support for search for enclosing macro call above |
. - @KronicDeth
StabBody
for use scope. - @KronicDeth
ATOM
for keyword keys instead of IDENTIFIER_TOKEN
as ATOM
allows for @
, which is needed for correctness. - @KronicDeth
eachEbinPath
, the ebin directories were found by iterating <SDK_HOME_PATH>/lib
and then iterating grandchild of that, so that all paths matching <SDK_HOME_PATH>/lib/<APP>/ebin
would be added, but for some installs from source, like SDK, there are non-OTP-app files in <SDK_HOME_PATH>/lib
, so filter <SDK_HOME_PATH>/lib/<APP>
to only directories. - @KronicDeth
org.elixir.lang.psi.scope.Module.aliasedName(QualifiedAlias)
was already converted to use org.elixir_lang.psi.operation.Normalized
and org.elixir_lang.psi.infix.Normalized
, which makes it work with errors in the PSI tree, so there's no need protect with an assert and that assert would be wrong in times of errors handled by Normalized
. - @KronicDeth
org.elixir_lang.reference.module.UnaliasedName.down(PsiElement)
only expects ElixirAccessExpression
or QualifiableAlias
, but for unexpected classes of elements, it was a simple Kotlin TODO()
, which didn't log anything useful for enhancements. Replace the TODO()
with an org.elixir_lang.errorreport.Logger.error
, so that the element's class and content can be reported when this happens again. - @KronicDeth
/
in paths passed to Erlang, even on Windows - @notriddle
TerminalExecutionConsole
used to run iex
in a PTY. - @KronicDeth
*.ex
filesIt takes awhile, once the debugged process is started to configure the debugger in BEAM. To ensure that breakpoints are setup before allow the debugged code to run, the debugger blocks until setup is complete.
.beam
files
.beam
files will be interpreted unless they match the Module Filter PatternBinaries show each byte at the byte's offset.
Bitstrings show each byte with any partial byte annotated with its bitwidth.
Boolean variables are rendered as their value.
Charlists show the integer values because they're treated as lists
Functions don't have literal representation, so the inspect form starting with #Fun<...>
is shown
Lists render differently based on whether the list is improper or not. Improper lists show the head and tail while proper lists show their element by offset.
Maps render differently based on the key type. If the map uses all atom
keys, the key will equal the value in the nested children while non-atom keys are shown as entries at a specific offset with the key and value. This is done, so that complex keys that have subterms can be expanded or collapsed, which is not possible for the simpler atom rendering.
Floats and integers are rendered as literals.
Pids are broken up into their hidden node,
id, and
serial`.
Strings show their literal value and unicode is fully supported.
Tuples show their elements at their offsets.
While Elixir allows rebinding variable names, Erlang does not, so when viewed in the Variables pane, rebound variables will have an @VERSION
after their name indicating which rebinding of a the variable is.
When stopped at a breakpoint, you can use the Evaluate button (it looks like a simple pocket calculator) to open an editor to type code to be executed in the current stack frame.
The evaluator supports the full syntax.
The result of evaluating the code with be shown as the value of result
below the entered "Expression".
Errors in the code will report back as a result
tuple with an :EXIT
tag. This reflects that the error has crashed the process that was evaluating the code. Thankfully, due to how how the interpreter is written, this does not lose the current stack frame and stepping or other evaluation can continue.
Distillery's mix release
produces a CLI for running the release.
mix release
==> Release successfully built!
You can run it in one of the following ways:
Interactive: _build/ENV/rel/NAME/bin/NAME console
Foreground: _build/ENV/rel/NAME/bin/NAME foreground
Daemon: _build/ENV/rel/NAME/bin/NAME start
_build/ENV/rel/NAME/bin/NAME
path produed by mix release
above.console
runs a shell with the release loaded similar to iex -S mix
.foreground
to runs the release without a shell, like mix
or mix run
.rel/config.exs
that Distillery uses.erl
arguments" with arguments to erl
before it runs elixir
.ERL_OPTS
environment variable supported by Distillery.elixir -extra
arguments" with arguments to pass to elixir
before it run the release.EXTRA_OPTS
environment variable supported by Distillery.CODE_LOADING_MODE
environment variable supported by Distillery.
rel/config.exs
. Don't set CODE_LOADING_MODE
environment variable.embedded
- load all code immediately on boot. Set CODE_LOADING_MODE=embedded
.interactive
- load code on-demand as it is needed/referenced. Set CODE_LOADING_MODE=interactive
.RUNNER_LOG_DIR
environment variable supported by Distillery.REPLACE_OS_VARS
environment variable supported by Distillery.
rel/config.exs
. Don't set REPLACE_OS_VARS
environment variable.false
- don't replace "${A_VAR_NAME}" in the generated configuration with A_VAR
environment variable at runtime. Set REPLACE_OS_VARS=false
.true
- replace "${A_VAR_NAME}" in the generated configuration with A_VAR
environment variable at runtime. Set REPLACE_OS_VARS=true
.sys.config
File"SYS_CONFIG_PATH
environment variable supported by Distillery.RELEASE_CONFIG_DIR
environment variable supported by Distillery.PIPE_DIR
environment variable supported by Distillery.attach
, console
, console_boot
, console_clean
, or remote_console
)....
button...
button on the "Environment variables" line to add environment variables._build/ENV/rel/NAME/bin/NAME
iex
commands.:debugger
application to your release
rel/config.exs
release NAME
block, in the set :applications
block add :debugger
:
--- a/rel/config.exs
+++ b/rel/config.exs
@@ -41,6 +41,8 @@ end
release :intellij_elixir do
set version: current_version(:intellij_elixir)
set applications: [
+ # needed for IntelliJ Elixir debugger
+ :debugger,
:runtime_tools
]
end
mix test
sAlthough it is exceedingly rare, as most Elixir projects use mix
, it is supported to run/debug elixir
directly, such as when doing elixir script.exs
.
elixir
arguments".erl
arguments" with arguments to erl
before it runs elixir
....
button...
button on the "Environment variables" line to add environment variables.With the Run Configuration defined, you can either Run or Debug elixir
elixir
.elixir
.elixir
iex
run configurations allow you to run iex
with IntelliJ Elixir attached. It is most useful when debugging, but it also allows you save customizations in the configuration when it is more complicated than just iex
.
iex
arguments" with arguments to iex
.erl
arguments" with arguments to erl
before it runs iex
....
button...
button on the "Environment variables" line to add environment variables.With the Run Configuration defined, you can either Run or Debug the iex
configuration.
iex
iex
.Much like rake
tasks in Rubymine, this plugin can run mix
tasks.
mix
arguments" starting with the name of the mix
task followed by any arguments to that task.elixir
arguments" with arguments to elixir
before it runs mix
.erl
arguments" with arguments to erl
before it runs elixir
....
button...
button on the "Environment variables" line to add environment variables.With the Run Configuration defined, you can either Run or Debug the Mix Task
mix
taskmix
task.
mix
taskIf you want to run iex
in the context of the project, you need to run iex -S mix
, but if you don't want to have to worry about forgetting whether it's -s
or -S
or if it is mix -S iex
or iex -S mix
, you can use an IEx Mix configuration.
mix
arguments", such as phx.server
if you want to launch Phoenix inside of iex
.iex
arguments" with arguments to iex
before -S mix
.erl
arguments" with arguments to erl
before it runs iex
....
button...
button on the "Environment variables" line to add environment variables.Wih the Run Configuration defined, you can either Run or Debug iex -S mix
iex -S mix
iex -S mix
.mix test
The mix test
task gets a special type of Run Configuration, Elixir Mix ExUnit
. Using this Run Configuration type instead, of the basic Elixir Mix
Run Configuration will cause the IDE to attach a special formatter to mix test
, so that you get the standard graphical tree of Test Results
The Run pane will show Test Results. If there is a compilation error before or during mix test
, it will be shown as a test failure. If the compilation failure is in a _test.exs
file can it can be inferred from the stacktrace, the compilation error will show up as a test failure in that specific module.
doctest
names are rearranged to emphasize the function being tested: "test doc at MODULE.FUNCTION/ARITY (COUNT)"
becomes "MODULE.FUNCTION/ARITY doc (COUNT)"
. If MODULE
is the same as the test case without the Test
suffix, then MODULE
is stripped too and the test name becomes only FUNCTION/ARITY doc (COUNT)
.
mix test
Run Configurations Manuallymix test
arguments" with the argument(s) to pass to mix test
. Normally, this will be a directory like test
, relative to the "Working directory"elixir
arguments" with the arguments to elixir
before it runs mix test
.erl
arguments"with the arguments to
erlbefore it runs
elixir`....
button...
button on the "Environment variables" line to add environment variables.With the Run Configuration defined you can either Run or Debug the mix test
s
mix test
taskmix test
sWhile you can create Elixir Mix ExUnit
run configurations manually using the Run > Edit Configurations...
menu, it is probably more convenient to use the context menu.
mix test
Run Configurations from contextThe context menu must know that the the directory, file, or line you are right-clicking is a test. It does this by checking if the current directory or an ancestor is marked as a Test Sources Root.
test
directory is marked as a Test Sources Roottest
directory is green. If it is, it is likely a Test Sources Root. This color may differ in different themes, so to be sure you can check the context menutest
directory.mix test
Run Configurations from directoryAlternatively, you can use keyboard shortcuts
Ctrl+Shift+R
will create the Run Configuration and Run it.mix test
Run Configurations from fileAlternatively, you can use keyboard shortcuts
Ctrl+Shift+R
will create the Run Configuration and Run it.Finally, you can use the editor tabs
mix test
Run Configurations from lineIf you want to be able to run a single test, you can create a Run Configuration for a line in that test
Alternatively, you can use keyboard shortcuts
Ctrl+Shift+R
will create the Run Configuration and Run it.Published by KronicDeth over 6 years ago
true:
and false:
did not work as keyword keys
#{
auto-close with }
.beam
file when it is being rebuilt.
.beam
files that are test cases in Erlang's :kernel
test code were correctly caught by the bug reporter, but they should be ignored since they're a known failure.
startingReference
in ElixirPsiImplUtil.aliasToModular
.
ElixirPsiImplUtil
into separate files tied to specific classes or interfaces to shrink its size. - @KronicDeth
#{
with }
. - @KronicDeth
alias
es and the defmodule
that is being aliased because element description now include alias
or defmodule
before the Alias name based on how the Alias is defined in the scope.2018.1
and latest patch version of other versions. - @KronicDeth
master
..beam
files in the OTP source are purposely invalid, so ignore them when trying to parse and don't log the expected error. - @KronicDeth
FOR1
. - @KronicDeth
erl_abstract_code
format Dbgi
chunks can now be navigated similar to how elixir_erl
format Dbgi chunks can be navigated. Instead of converting the Erlang Abstract Code back to Erlang, which would not be highlighted if intellij-erlang and requires the user to know Erlang, the Erlang Abstract Code is translated back to Elixir source, so you can use the Dbgi chunk view to translate Erlang to Elixir. - @KronicDeth
{
). - @KronicDeth
In order to prevent Access is allowed from event dispatch thread only
errors when creating read-only code editor in subtabs of the BEAM Chunks editor, only create those editors when their parent tab is selected.
Affected tabs:
VariableInplaceRenameHandler
used. - @KronicDeth
true
and false
to be keyword keys. - @KronicDeth
.beam
FilesDbgi
The Dbgi
tab appearance varies based on whether it was created with Erlang or Elixir, reflecting the fact that the Dbgi format is dependent on the backend that wrote it.
####### Elixir (:elixir_erl
backend)
The Dbgi
tab show the single value map entries: :file
, :line
, and :module
.
For the multi-value keys: :attributes
, :compile_opts
, and :definitions
, there are individual tabs.
######## Attributes
The Attributes tab has the same format as the Attr
s chunk.
######## Compile Options
The Compile Options tab is usually empty, much like the CInf
options
key for Erlang.
######## Definitions
The Definitions tab is split between a tree of Module, Function/Arity and clauses.
Clicking on a clause will show only that clause, but clicking on a higher level in the tree will show all clauses in the function or the entire Module.
The AST stored in the definitions
tab and the process of converting it back to code is not format preserves, so it will not look precisely like the source code as the AST has undergone some macro expansion before its put in the Dbgi
chunk. As common idioms are understood, reversals will be add to the renderer.
####### Erlang (:erlang_abstract_code
backend)
The Dbgi
tab has Abstract Code and Compile Options tabs.
######## Abstract Code
The Abstract Code tab is split between a tree of Attributes, Functions, Function/Arity, and clauses.
Clicking on a clause will show only that clause, but clicking on a higher level in the tree will show all clauses in the function or the entire Module.
The abstract code stored in the :erlang_abstract_code
backend format is the Erlang Abstract Format. Instead of converting the Erlang Abstract Format back to Erlang, which would require IntelliJ Erlang to highlight and annotate and for you to be used to reading Erlang, the Erlang Abstract Format is translated back to Elixir. Using the BEAM Chunk Dbgi viewer can be a way to convert compiled Erlang code to Elixir source automatically.
Find Usages is a feature of JetBrains IDEs. It is the dual of Go To Declaration. While Go To Declaration jumps from a usage to the declaration, Find Usages finds all usages that could jump to a declaration. When used on a usage, Find Usage first finds the declaration(s) and then finds usages of those declaration(s).
Find Usages will open all the found usages in the Find Tool Window (unless you have it configured to not open and jump direct if only one usage is found). If you want to jump to usages quickly, Show Usages, which opens a lookup dialog at the cursor and allows you to select a usage to jump to in the lookup dialog with the arrow keys may be more useful.
hd
in the definition def hd([h | t]]) do
or hd
in a usage hd(list)
.Alt+F7
If a function has multiple clauses, all clauses for the function will be resolved and used as targets.
You can be sure that all clauses were correctly identified as targets because of the multiple entries in the top "Functions" target grouping.
If instead of bringing up the Find Tool Window, you'd like a lookup dialog above the cursor, you can use Show Usages.
hd
in def hd([h | t]]) do
Alt+Cmd+F7
Published by KronicDeth over 6 years ago
bcrypt
killed the debugger
lz4
and re2
killed the debugger
asdf
SDK incompatibilities and correct configuration
mix format
debuggerINTELLIJ_ELIXIR_DEBUG_BLACKLIST
environment variable. INTELLIJ_ELIXIR_DEBUG_BLACKLIST
should be reserved to additional modules that need to not be interpreted only for specific runs.
mix phx.new
dependencies, so that debugger boots faster for most users..eex
templates
.eex
template files, to allow stepping through Elixir tags in those templates..eex
files when a .beam
file using the template's relative can be found. This means that the Phoenix view module .beam
file must exist in _build
prior to setting a breakpoint. Run the Run Configuration once, before debugging to complete the build if setting a breakpoint does not work.
.beam
files are now indexed by their Line
chunk filenames
subsection to power this feature..beam
Beam
Cache
on VirtualFile
. Cache is invalidated and refreshed on modification of the VirtualFile
. Cache is used for both BEAM Chunks read-only editors and Line
chunk file name index.ProcessAdapter
turns warning text into errors that IDE understands.Bcrypt.Base
:erocksdb
:lz4
:re2
dbeug
flag when starting IntelliJElixir.DebugServer
, which removes the *DBG*
statements that kept printing in the ExUnit output when using the debugger.INTELLIJ_ELIXIR_DEBUG_BLACKLIST
environment variable.null
SDK Release
, so that when Elixir is configured, but the Erlang path is broken (such as after a brew unlink erlang
, the Release
calculating using elixir
Macro.atomToString
|
for presenationhead
and tail
instead of index.0
-based) instead of Erlang indices (1
-based`) for lists and tuples.lib
and not lib/erlang/lib
, so that it works for both Homebrew's ebin
paths and ASDF's ebin
paths. - @KronicDeth
MixBuilder
because building with mix
is just an option in ElixirBuilder
.mix
to pattern used in Run Configuration runners.
mix
path from SDKmix
errors
mix compile
output for compilation errors and warnings
erlang_module_name_patterns_to_regex
before pinning: I always forget that the |
swallows the ^
and $
in regexes.Enum.reduce
to track rejections.:
to start of Erlang module names for included debugger excludesBy default, the debugger will scan all the load paths and build path for .beam
files and the corresponding modules will be interpreted which causes the Module's Erlang abstract code chunk to be interpreted in Erlang instead of the bytecode chunk being executed in the C parts of the BEAM. This interpretation is much slower than execution, so by default all of the Elixir standard library and the common modules installed in Phoenix projects are excluded from being interpreted when the debugger starts. The modules can be still be stepped into or have breakpoints explicitly set.
You can customize these module patterns as an application setting.
If you want to customize the modules to ignore on a per-Run-Configuration basis, you can set an environment variable in the Run Configuration.
Variable | Example | Description |
---|---|---|
INTELLIJ_ELIXIR_DEBUG_BLACKLIST | iconv,some | Excluding modules from debugger |
Notice: If you want non Elixir.
module in blacklist, write it with: :
. This rule applies only to module atoms.
A line breakpoint is a breakpoint assigned to a specific line in the source code.
Line breakpoints can be set on executable lines. Comments, declarations and empty lines are not valid locations for the line breakpoints. Line break points can be set in .ex
and .eex
files.
.eex
line breaks will only work on Elixir code that is used in Phoenix view modules.
.eex
breakpoints only work if a .beam
file using the template's relative can be found. This means that the Phoenix view module .beam
file must exist in _build
prior to setting a breakpoint. Run the Run Configuration once, before debugging to complete the build if setting a breakpoint does not work.
Cmd+F8
mix compile
instead of elixirc
directly)--no-docs
elixirc
flag)--no-debug-info
elixirc
flag)--warnings-as-errors
elixirc
flag)--ignore-module-conflict
elixirc
flag)If a file has errors and warnings, they are group together in Build Messages under that file.
You can jump to errors and warnings in the Build Messages
Highlight the error or warning you want to jump to source
Do one of the following
Right-Click the error or warning
Select Jump to Source from the context menu
OR
You can also turn on Autoscroll to Source, which will Jump To Source whenever you Click or select an error or warning.
If you enable Warnings as Errors in the settings, then the Warnings will be treated as Errors by elixirc
and mix
and the Build Messages will show the Warnings as Errors.
If only warnings remain in the source.
With Warnings as Errors On, all the Warnings will appear as Errors and still fail the build
With Warnings as Errors Off, the Warnings will appear as Warnings and the build will succeed
When configuring an SDK, if you don't want to use the suggested SDK home path, you'll need to know where each package manager puts Elixir and Erlang.
If you can can't see hidden files, such as .asdf
in your home directory (~
), or system directories, such as /usr
, you will need to enable Show Hidden Files in the Home Path dialog.
If your dialog looks like this, click the Show Hidden Files button
If you're using the macOS native File Picker, use the keyboard shortcut ⌘⇧. (Command+Shift+Period).
Published by KronicDeth over 6 years ago
StreamEx
is missing nonNull
on some IDEs/versions
2017.3
to 2017.3.2
1.5.2
to 1.5.3
.beam
files: "BEAM Chunks". The decompiled binary file will continue to be shown on the default "Text" editor tab..beam
file..beam
file.
The Atom
chunk holds LATIN-1
atoms while AtU8
holds UTF8
atoms. There will only be one of these atom-related chunks in any given .beam
file. AtU8
is used in newer versions of OTP that support UTF8 atoms.
The Atom
/AtU8
tab shows a table with the columns
Column | Description | Source |
---|---|---|
Index | Which is 1-based to match Erlang convention. In the Code chunk, atom(0) is reserved to always translate to nil
|
Derived |
Byte Count | The byte count for the atom's bytes | Raw |
Characters | From encoding the bytes as LATIN-1 for Atom chunk or UTF-8 for AtU8 chunk |
Derived |
Index 1 is always the module name for the .beam
file. Since .beam
is originally an Erlang format, for Elixir modules, you'll see the full atom name of with the Elixir.
prefix instead of the Alias name used in Elixir source.
The Attr
chunk holds the module attributes, but only those that are persisted.
The Attr
tab shows a table with the columns
Column | Description | Source |
---|---|---|
Key | Attribute name | Raw |
Value | Attribute value. Note: The value always appears as a list as read from the binary format. I don't know why. | Raw |
All modules will have a :vsn
attribute that is either set explicitly or defaults to the MD5 of the module.
The CInf
chunk is the Compilation Information for the Erlang or Erlang Core compiler. Even Elixir modules have it because Elixir code passes through this part of the Erlang Core compiler.
The CInf
tab shows a table with the columns
Column | Description | Source |
---|---|---|
Key | Option name | Raw |
Value | Inspected value | Raw |
The Code
chunk contains the byte code for the module. It is encoded in BEAM Compact Term Encoding, which differs from the binary format produced by term_to_binary
.
The Code
tab shows a read-only editor with one byte code operation on each line. For ease of reading, operations are grouped by function and then label block with indentation indicating scope.
By default as many references to other chunks and references to other parts of Code
chunk are inlined to ease understanding. If you want to see the raw byte code operations, you can turn off the various inliners.
The Dbgi
chunk contains Debug Info. It was introduced in OTP 20 as a replacement for the Abst
chunk. While the Abst
chunk was required to contain the Erlang AST, the Dbgi
format can contain the debug info for other languages, such as Elixir quoted
form AST.
Because the format is language neutral, the format is a set of nested, versioned formats. The outer most layer is
{:debug_info_v1, backend, metadata | :none}
For :debug_info_v1
, Elixir's backend
is :elixir_erl
. The metadata
for :elixir_erl
is further versioned: {:elixir_v1, map, specs}
.
map
contains the bulk of the data.
Key | Value |
---|---|
:attributes |
Attributes similar to the Attr chunk, but at the Elixir, instead of Core Erlang level. Usually they match with the exception that attributes doesn't contain vsn when Attr contains the MD5 version |
:compile_opts |
Compilation options similar to CInf chunk's options key, but at for Elixir, instead of Core Erlang level. |
:definitions |
The Elixir quoted AST for reach function clause. |
:file |
The name of the file the module was generated from. |
:line |
The line in :file where the module was defined, such as the line defmodule occurred. |
:module |
The name of the module as an atom
|
:unreachable |
Unreachable functions |
The Dbgi
tag show the single value map entries: :file
, :line
, and :module
For the multi-value keys: :attributes
, :compile_opts
, and :definitions
, there are individual tabs.
The Attributes tab has the same format as the Attr
s chunk
The Compile Options tab is usually empty, much like the CInf
options
key for Erlang.
The Definitions tab is split between a tree of Module, Function/Arity and clauses.
Clicking on a clause will show only that clause, but clicking on a higher level in the tree will show all clauses in the function or the entire Module.
The AST stored in the definitions
tab and the process of converting it back to code is not format preserves, so it will not look precisely like the source code as the AST has undergone some macro expansion before its put in the Dbgi chunk. As common idioms are understood, reversals will be add to the renderer.
The ExDc
chunk stores ExDoc. Not the rendered HTML from the ex_doc
package, but the the @doc
, @moduledoc
, and @typedoc
attribute values that work even without ex_doc
installed. This chunk is what is consulted when the h
helper is used in iex
.
The ExDc
binary format is from term_to_binary
, so it can be reversed with binary_to_term
. The term format is a versioned as {version, versioned_format}
. The current version
tag is :elixir_docs_v1
and the versioned_format
is a Keyword.t with :callback_docs
, :docs
, :moduledoc
, and :type_docs
keys.
Like Dbgi
, the ExDc
tab is split between a tree to navigate and an editor to show the decompiled value.
Node | Description |
---|---|
Root | All docs |
Module | @moduledoc |
Types | All @typedoc s |
Types child | A specific @typedoc
|
Callbacks | All @callback @doc s |
Callbacks child | A specific @callback 's @doc
|
Functions/Macros | All @doc s for functions/macros |
Functions/Macros child | A specific function/macro's @doc
|
The ExpT
chunk is the Export Table. The name "Export" derives from the Erlang
module attribute -export
, which is used to "export" functions from a module. It is the equivalent of making a function or macro public with def
and defmacro
as opposed to making it private with defp
and defmacrop
in Elixir.
The ExpT
tab shows a table with the columns
Column | Description | Source |
---|---|---|
Atom Index | Index into the Atom or AtU8 chunk for the function's name |
Raw |
Name | The atom referenced by "Atom Index" | Derived |
Arity | The arity (argument count) of the function | Raw |
Label | Label index in the Code chunk where the function is defined. This label is usually immediately after the func_info operation and before the first pattern match or guard operation. |
Raw |
You'll notice the first entry starts with MACRO-
. This is because the BEAM, being made for Erlang has no concept of macros. It only understands functions, so Elixir macros, like __using__/1
called by use
are compiled to plain Erlang functions with MACRO-
prefixed to their name and an extra argument (the __CALLER__
environment) as the first argument, which increases the arity, yielding a full MFA of MACRO-__using__/2
as seen above.
The ImpT
chunk is the Import Table. It DOES NOT encode just the Erlang -import
attributes or Elixir import
macro calls: it tracks any external function or macro called from another module. call_ext_*
operations in the Code
chunk don't store the Module and Function (MF) of the function they will call directly in the bytecode, instead, one of the arguments is an index into the ImpT
chunk. This way, all external calls are normalized into the ImpT
chunk instead of being denormalized to the call site. The arity still appears at the call site to help with checking the argument count.
The ImpT
tab shows a table with the columns
Column | Description | Source |
---|---|---|
Index | 0-based index used by references in the Code chunk. |
Derived |
Module Atom Index | Index into the Atom or AtU8 chunk for the Module's name |
Raw |
Module Atom | The atom referenced by "Module Atom Index". | Derived |
Function Atom Index | Index into the Atom or AtU8 chunk for the functon's name |
Raw |
Function Atom | The atom referened by "Function Atom Index". | Derived |
You may notice that erlang.byte_size/1
is included in the table. This is because even bifs are referenced by MFA and not a pre-assigned number as would be the case for system calls in operating systems like Linux. BEAM is like an Operation System, but not in all ways.
The LitT
chunk contains literals loaded as arguments in Code
chunk. Confusingly, in the Code
chunk sometimes the literal(N)
term is used to encode integer N
, an index into another chunk, or an actual index
into the LitT
. How literal
terms are handled is completely dependent on the specific operation, so without having outside knowledge about the bytecode operation arguments for BEAM, the best way to figure out if literal
terms are an integer or an index is to toggle the various controls in the Code
tab to see if literal
with no inlining turns into a LitT
literal, FunT
function reference, ImpT
function reference, or integer.
The LitT
tab shows a table with the columns
Column | Description | Source |
---|---|---|
# | 0-based index used by references in the Code chunk. |
Derived |
Term | The equivalent of `raw | > binary_to_term() |
The LocT
chunk is the dual to the ExpT
chunk: it contains all private functions and macros.
The LocT
tab shows a table with the columns
Column | Description | Source |
---|---|---|
Atom Index | Index into the Atom or AtU8 chunk for the function's name |
Raw |
Name | The atom referenced by "Atom Index" | Derived |
Arity | The arity (argument count) of the function | Raw |
Label | Label index in the Code chunk where the function is defined. This label is usually immediately after the func_info operation and before the first pattern match or guard operation. |
Raw |
You'll notice the first entry -__struct__/1-fun-0-
, starts with -
and have a /
suffix with fun
in it. This naming scheme is used for anonymous functions such as those defined with fn
or the capture operator (&
) in Elixir. Much like how macros don't really exist and use a MACRO-
suffix, anonymous functions/lambdas don't exist, and instead use a distinct naming scheme -<PARENT_FUNCTION>/*fun*
. Unlike MACRO-
, which is an Elixir invention, anonymous functions/lambdas really being local named functions with derived names is also done in pure Erlang modules. Erlang's anonymous functions are defined with fun
, which is where the fun
part of the naming scheme comes from.
The StrT
chunk contains a single contiguous pool of all Erlang strings (that is, Elixir charlists) used in the Code
chunk. These strings are used for byte code operations like bs_put_string
. Not all strings appear in StrT
. Some strings, including most Elixir strings (Erlang binaries) appear in the LitT
chunk that holds literals.
The StrT
is contiguous with no separation of strings. Instead of encoding the start and length of each string in the chunk itself, the start and length for any given string is passed as arguments to the byte code operations in the Code
chunk. By doing this, shared substrings can be efficiently encoded in StrT
.
Support for https://github.com/elixir-lang/elixir/commit/23c7542d95683a497a7b93071b9ccbbeb9e45d2f
Version | Struct | Started Event | Finished Event |
%ExUnit.Test{} field |
---|---|---|---|---|
< 1.6.0 | %ExUnit.TestCase{} |
:case_started |
:case_finished |
case |
>= 1.6.0 | %ExUnit.TestCase{} |
:module_started |
:module_finished |
module |
Because Elixir 1.6.0 could not introduce a breaking change, the < 1.6.0
events are fired, but resources/exunit/1.6.0/team_city_ex_unit_formatting.ex
will ignore them and only convert the >= 1.6.0
events to TeamCity event used in the JetBrains Test Runner UI.
StreamEx
because support is inconsistent across IDEs - @KronicDeth
@https://github.com/thirdshift
) shown instead of his GitHub username (@thirdshift
)README.md
Updates.beam
Files.beam
files are the compiled version of modules on the BEAM virtual machine used by Elixir and Erlang. They are the equivalent of .class
files in Java.
.beam
files are not detected purely by their file extension: the BEAM file format starts with a magic number, FOR1
, that is checked for before decompiling.
.beam
files have 2 editors registered: decompiled Text and BEAM Chunks
If the .beam
module was compiled with the compressed
compiler directive, which in Erlang looks like
-compile([compressed])
and in Elixir looks like
@compile [:compressed]
then the outer file format is GZip (which is detected by checking for the gzip magic number, 1f 8b
, at the start of the file) and the .beam
will be (stream) decompressed before the .beam
header is checked and the chunks decoded.
.beam
files are composed of binary chunks. Each chunk is formatted
This format is generically referred to as Type-Length-Value
The BEAM Chunks editor tab is subdivided into further tabs, one for each chunk in the .beam
file.
The tabs are listed in the order that the chunks occur in the .beam file.
Atom
/ AtU8
The Atom
chunk holds LATIN-1 encoded atoms while AtU8
chunk holds UTF-8 atoms. There will only be one of these atom-related chunks in any given .beam
file. AtU8
is used in newer versions of OTP that support UTF-8 atoms. AtU8
was introduced in OTP 20.
The Atom
/AtU8
tab shows a table with the columns
Column | Description | Source |
---|---|---|
Index | 1-based to match Erlang convention. In the Code chunk, atom(0) is reserved to always translate to nil
|
Derived |
Byte Count | The byte count for the atom's bytes | Raw |
Characters | From encoding the bytes as LATIN-1 for Atom chunk or UTF-8 for AtU8 chunk |
Derived |
Attr
The Attr
chunk holds the module attributes, but only those that are persisted. Erlang module attributes are persisted by default, but in Elixir module attributes need to be marked as persisted with Module.register_attribute/3
The Attr
chunk uses External Term Format (term_to_binary
's output) to encode a proplist, which is similar to, but not quite the same an Elixir Keyword list
All modules will have a :vsn
attribute that is either set explicitly or defaults to the MD5 of the module.
The Attr
tab shows a table with the columns
Column | Description | Source |
---|---|---|
Key | Attribute name | Raw |
Value | Attribute value. Note: The value always appears as a list as read from the binary format. I don't know why. | Raw |
CInf
The CInf
chunk is the Compilation Information for the Erlang or Erlang Core compiler. Even Elixir modules have it because Elixir code passes through this part of the Erlang Core compiler
The CInf
chunk uses External Term Format (term_to_binary
's output) to encode a proplist, which is similar to, but not quite the same an Elixir Keyword list
The CInf
tab shows a table with the columns
Column | Description | Source |
---|---|---|
Key | Option name | Raw |
Value | Inspected value | Raw |
Code
The Code
chunk contains the byte code for the module.
It is encoded in BEAM Compact Term Encoding, which differs from the binary format produced by term_to_binary
.
The Code
tab shows a read-only editor with one byte code operation on each line. For ease of reading, operations are grouped by function and then label block with indentation indicating scope.
By default as many references to other chunks and references to other parts of Code
chunk are inlined to ease understanding. If you want to see the raw byte code operations, you can turn off the various inliners.
####### Controls
If any of the inliners are incorrect or you have an argument name that makes more sense, please open an issue.
Dbgi
The Dbgi
chunk contains Debug Info. It was introduced in OTP 20 as a replacement for the Abst
chunk. While the Abst
chunk was required to contain the Erlang AST, the Dbgi
format can contain the debug info for other languages, such as Elixir quoted
form AST.
Because the format is language neutral, the format is a set of nested, versioned formats. The outer most layer is
{:debug_info_v1, backend, metadata | :none}
For :debug_info_v1
, Elixir's backend
is :elixir_erl
. The metadata
for :elixir_erl
is further versioned: {:elixir_v1, map, specs}
.
map
contains the bulk of the data.
Key | Value |
---|---|
:attributes |
Attributes similar to the Attr chunk, but at the Elixir, instead of Core Erlang level. Usually they match with the exception that attributes doesn't contain vsn when Attr contains the MD5 version |
:compile_opts |
Compilation options similar to CInf chunk's options key, but at for Elixir, instead of Core Erlang level. |
:definitions |
The Elixir quoted AST for reach function clause. |
:file |
The name of the file the module was generated from. |
:line |
The line in :file where the module was defined, such as the line defmodule occurred. |
:module |
The name of the module as an atom
|
:unreachable |
Unreachable functions |
The Dbgi
tag show the single value map entries: :file
, :line
, and :module
.
For the multi-value keys: :attributes
, :compile_opts
, and :definitions
, there are individual tabs.
####### Attributes
The Attributes tab has the same format as the Attr
s chunk.
####### Compile Options
The Compile Options tab is usually empty, much like the CInf
options
key for Erlang.
####### Definitions
The Definitions tab is split between a tree of Module, Function/Arity and clauses.
Clicking on a clause will show only that clause, but clicking on a higher level in the tree will show all clauses in the function or the entire Module.
The AST stored in the definitions
tab and the process of converting it back to code is not format preserves, so it will not look precisely like the source code as the AST has undergone some macro expansion before its put in the Dbgi
chunk. As common idioms are understood, reversals will be add to the renderer.
ExDc
The ExDc
chunk stores ExDoc. Not the rendered HTML from the ex_doc
package, but the the @doc
, @moduledoc
, and @typedoc
attribute values that work even without ex_doc
installed. This chunk is what is consulted when the h
helper is used in iex
.
The ExDc
chunk is the encoded with term_to_binary
. The term format is a versioned as {version, versioned_format}
. The current version
tag is :elixir_docs_v1
and the versioned_format
is a Keyword.t with keys matching the Code.get_docs/2
tags :callback_docs
, :docs
, :moduledoc
, and :type_docs
keys.
Like Dbgi
, the ExDc
tab is split between a tree to navigate and an editor to show the decompiled value.
Click on a node in the tree will show all docs at that level and any descendants.
Node | Description |
---|---|
Root | All docs |
Module | @moduledoc |
Types | All @typedoc s |
Types child | A specific @typedoc
|
Callbacks | All @callback @doc s |
Callbacks child | A specific @callback 's @doc
|
Functions/Macros | All @doc s for functions/macros |
Functions/Macros child | A specific function/macro's @doc
|
ExpT
The ExpT
chunk is the Export Table. The name "Export" derives from the Erlang
module attribute -export
, which is used to "export" functions from a module. It is the equivalent of making a function or macro public with def
and defmacro
as opposed to making it private with defp
and defmacrop
in Elixir.
The BEAM format and the ExpT
chunk, being made for Erlang, has no concept of macros. It only understands functions, so Elixir macros, like __using__/1
called by use
are compiled to plain Erlang functions with MACRO-
prefixed to their name and an extra argument (the __CALLER__
environment) as the first argument, which increases the arity, yielding a full MFA of MACRO-__using__/2
as seen above.
The ExpT
tab shows a table with the columns
Column | Description | Source |
---|---|---|
Atom Index | Index into the Atom or AtU8 chunk for the function's name |
Raw |
Name | The atom referenced by "Atom Index" | Derived |
Arity | The arity (argument count) of the function | Raw |
Label | Label index in the Code chunk where the function is defined. This label is usually immediately after the func_info operation and before the first pattern match or guard operation. |
Raw |
ImpT
The ImpT
chunk is the Import Table. It DOES NOT encode just the Erlang -import
attributes or Elixir import
macro calls: it tracks any external function or macro called from another module. call_ext_*
operations in the Code
chunk don't store the Module and Function (MF) of the function they will call directly in the bytecode, instead, one of the arguments is an index into the ImpT
chunk. This way, all external calls are normalized into the ImpT
chunk instead of being denormalized to the call site. The arity still appears at the call site to help with checking the argument count.
You may notice that erlang.byte_size/1
is included in the table. This is because even BIFs are referenced by MFA and not a pre-assigned number as would be the case for system calls in operating systems like Linux. BEAM is like an Operation System, but not in all ways.
The ImpT
tab shows a table with the columns
Column | Description | Source |
---|---|---|
Index | 0-based index used by references in the Code chunk. |
Derived |
Module Atom Index | Index into the Atom or AtU8 chunk for the Module's name |
Raw |
Module Atom | The atom referenced by "Module Atom Index". | Derived |
Function Atom Index | Index into the Atom or AtU8 chunk for the functon's name |
Raw |
Function Atom | The atom referened by "Function Atom Index". | Derived |
LitT
The LitT
chunk contains literals loaded as arguments in Code
chunk.
Confusingly, in the Code
chunk sometimes the literal(N)
term is used to encode integer N
, an index into another chunk, or an actual index
into the LitT
. How literal
terms are handled is completely dependent on the specific operation, so without having outside knowledge about the bytecode operation arguments for BEAM, the best way to figure out if literal
terms are an integer or an index is to toggle the various controls in the Code
tab to see if literal
with no inlining turns into a LitT
literal, FunT
function reference, ImpT
function reference, or integer.
The LitT
tab shows a table with the columns
Column | Description | Source |
---|---|---|
# | 0-based index used by references in the Code chunk. |
Derived |
Term | The equivalent of `raw | > binary_to_term() |
Line
The Line
chunk encodes both the file name and line number for each line(literal(n))
operation in the Code
chunk. The n
in line(literal(n))
is an index in to the Line References table in the Line
chunk. This is used in Phoenix view modules to show where code from templates comes from.
The Line
chunk is composed of 2 subsections: (1) Line References and (2) File Names. First there is a header setting up the number of each entry to expect.
####### Line References
This uses the Compact Term Format used for the Code
chunk. The format ends up producing {file_name_index, line}
pairs using the following algorithm:
Term | Interpretation |
---|---|
atom(n) |
Change file_name_index to n
|
integer(n) |
Add {file_name_index, n} to end of Line References |
####### File Names
The Line
tab has one subtab for each subsection in the tab. Each subsection has its own table.
LocT
The LocT
chunk is the dual to the ExpT
chunk: it contains all private functions and macros.
You'll notice entries like -__struct__/1-fun-0-
, starts with -
and have a /
suffix with fun
in it. This naming scheme is used for anonymous functions such as those defined with fn
or the capture operator (&
) in Elixir. Much like how macros don't really exist and use a MACRO-
suffix, anonymous functions/lambdas don't exist, and instead use a distinct naming scheme -<PARENT_FUNCTION>/*fun*
. Unlike MACRO-
, which is an Elixir invention, anonymous functions/lambdas really being local named functions with derived names is also done in pure Erlang modules. Erlang's anonymous functions are defined with fun
, which is where the fun
part of the naming scheme comes from.
The LocT
tab shows a table with the columns
Column | Description | Source |
---|---|---|
Atom Index | Index into the Atom or AtU8 chunk for the function's name |
Raw |
Name | The atom referenced by "Atom Index" | Derived |
Arity | The arity (argument count) of the function | Raw |
Label | Label index in the Code chunk where the function is defined. This label is usually immediately after the func_info operation and before the first pattern match or guard operation. |
Raw |
StrT
The StrT
chunk contains all Erlang strings (that is, Elixir charlists) used in the Code
chunk.
The StrT
chunk contains a single contiguous pool. These strings are used for byte code operations like bs_put_string
. Not all strings appear in StrT
. Some strings, including most Elixir strings (Erlang binaries) appear in the LitT
chunk that holds literals. I'm not sure how the compiler determines whether to use StrT
or LitT
. I think it all depends on the byte code operation.
Instead of encoding the start and length of each string in the chunk itself, the start and length for any given string is passed as arguments to the byte code operations in the Code
chunk. By doing this, shared substrings can be efficiently encoded in StrT
.
Published by KronicDeth almost 7 years ago
.bat
was no longer needed on WIndows
ExternalLanguageAnnotators.allForFile
was being called with a null
PsiFile
CLASSES
and SOURCES
Root Types are installed
documentionRootType
to indirectly get the documentation OrderRootType
in the Erlang SDK Type, so that it works in Small IDEs that have more than CLASSES
and SOURCES
root types installed. - @KronicDeth
The credo
annotator is disabled by default as numerous users find running mix credo
in the background has a negative impact on their system performance. If you like to try enabling the annotation, you can turn it on using the configuration.
If you notice a degradation the in the responsiveness of the editor, it is recommended you disable the annotator again.
PsiFile
being null
in Local
credo inspector - @KronicDeth
Qualified#moduleName
getText
in Read Action. - @KronicDeth
Project
, but not a Module
, so change flow to use Project
when Module
is null
in credo annotator. - @KronicDeth
.bat
to mix
on Windows. mix
is never run as an executable. It is either run as a script to elixir.bat
OR as an argument to erl.exe
when erl.exe
is running elixir
. - @KronicDeth
When enabled, if credo
is not installed as a project dependency, nothing will happen, but if it is installed, mix credo PATH
will be called on any files after updates have quieted. Any credo
check failures will show up as warning annotations
Individual check failures will show the explanation (from mix credo PATH:LINE(:COLUMN)
) if you hover over the annotation
You can hover over the explanation and click the embedded links to jump to the line (and column) where the failure occurred.
The credo
annotator is disabled by default as numerous users find running mix credo
in the background has a negative impact on their system performance. If you like to try enabling the annotation, you can turn it on using the configuration.
If you notice a degradation the in the responsiveness of the editor, it is recommended you disable the annotator again.
Published by KronicDeth almost 7 years ago
OrderRootType.getOrderRootType
now has a @NotNull
annotation, which causes newer Small IDE releases to break when trying to access JavaDocRootType.getInstance()
.
mix
runs will be faster as they will no longer check to see if the SDK is updated. - @KronicDeth
@NotNull
to OrderRootType.getOrderRootType
, which JavaDocRootType.getInstance
calls, which means any Small IDE using intellij-community
since 4 months ago, including the newest CLion cannot have JavadocOrderRootType.getInstance
safely called. - @KronicDeth
projectSdksModel.apply()
was being called before the editor.apply()
, which would have copied to the editor'
s path changes to the projectSdksModel
. - @KronicDeth