-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Expand file tree
/
Copy pathcode.ex
More file actions
2393 lines (1863 loc) · 83.7 KB
/
Copy pathcode.ex
File metadata and controls
2393 lines (1863 loc) · 83.7 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
# SPDX-License-Identifier: Apache-2.0
# SPDX-FileCopyrightText: 2021 The Elixir Team
# SPDX-FileCopyrightText: 2012 Plataformatec
defmodule Code do
@moduledoc ~S"""
Utilities for managing code compilation, code evaluation, and code loading.
This module complements Erlang's [`:code` module](`:code`)
to add behavior which is specific to Elixir. For functions to
manipulate Elixir's AST (rather than evaluating it), see the
`Macro` module.
## Working with files
This module contains three functions for compiling and evaluating files.
Here is a summary of them and their behavior:
* `require_file/2` - compiles a file and tracks its name. It does not
compile the file again if it has been previously required.
* `compile_file/2` - compiles a file without tracking its name. Compiles the
file multiple times when invoked multiple times.
* `eval_file/2` - evaluates the file contents without tracking its name. It
returns the result of the last expression in the file, instead of the modules
defined in it. Evaluated files do not trigger the compilation tracers described
in the next section.
In a nutshell, the first must be used when you want to keep track of the files
handled by the system, to avoid the same file from being compiled multiple
times. This is common in scripts.
`compile_file/2` must be used when you are interested in the modules defined in a
file, without tracking. `eval_file/2` should be used when you are interested in
the result of evaluating the file rather than the modules it defines.
The functions above work with Elixir source. If you want to work
with modules compiled to bytecode, which have the `.beam` extension
and are typically found below the _build directory of a Mix project,
see the functions in Erlang's [`:code`](`:code`) module.
## Code loading on the Erlang VM
Erlang has two modes to load code: interactive and embedded.
By default, the Erlang VM runs in interactive mode, where modules
are loaded as needed. In embedded mode the opposite happens, as all
modules need to be loaded upfront or explicitly.
You can use `ensure_loaded/1` (as well as `ensure_loaded?/1` and
`ensure_loaded!/1`) to check if a module is loaded before using it and
act.
## `ensure_compiled/1` and `ensure_compiled!/1`
Elixir also includes `ensure_compiled/1` and `ensure_compiled!/1`
functions that are a superset of `ensure_loaded/1`.
Since Elixir's compilation happens in parallel, in some situations
you may need to use a module that was not yet compiled, therefore
it can't even be loaded.
When invoked, `ensure_compiled/1` and `ensure_compiled!/1` halt the
compilation of the caller until the module becomes available. Note that
the distinction between `ensure_compiled/1` and `ensure_compiled!/1`
is important: if you are using `ensure_compiled!/1`, you are
indicating to the compiler that you can only continue if said module
is available.
If you are using `Code.ensure_compiled/1`, you are implying you may
continue without the module and therefore Elixir may return
`{:error, :unavailable}` for cases where the module is not yet available
(but may be available later on).
For those reasons, developers must typically use `Code.ensure_compiled!/1`.
In particular, do not do this:
case Code.ensure_compiled(module) do
{:module, _} -> module
{:error, _} -> raise ...
end
Finally, note you only need `ensure_compiled!/1` to check for modules
being defined within the same project. It does not apply to modules from
dependencies as dependencies are always compiled upfront.
In most cases, `ensure_loaded/1` is enough. `ensure_compiled!/1`
must be used in rare cases, usually involving macros that need to
invoke a module for callback information. The use of `ensure_compiled/1`
is even less likely.
## Compilation tracers
Elixir supports compilation tracers, which allow modules to observe constructs
handled by the Elixir compiler when compiling files. A tracer is a module
that implements the `trace/2` function. The function receives the event name
as first argument and `Macro.Env` as second and it must return `:ok`. It is
very important for a tracer to do as little work as possible synchronously
and dispatch the bulk of the work to a separate process. **Slow tracers will
slow down compilation**.
You can configure your list of tracers via `put_compiler_option/2`. The
following events are available to tracers:
* `:start` - (since v1.11.0) invoked whenever the compiler starts to trace
a new lexical context. A lexical context is started when compiling a new
file or when defining a module within a function. Note evaluated code
does not start a new lexical context (because they don't track unused
aliases, imports, etc) but defining a module inside evaluated code will.
Note this event may be emitted in parallel, where multiple files/modules
invoke `:start` and run at the same time. The value of the `lexical_tracker`
of the macro environment, albeit opaque, can be used to uniquely identify
the environment.
* `:stop` - (since v1.11.0) invoked whenever the compiler stops tracing a
new lexical context, such as a new file.
* `{:import, meta, module, opts}` - traced whenever `module` is imported.
`meta` is the import AST metadata and `opts` are the import options.
* `{:imported_function, meta, module, name, arity}` and
`{:imported_macro, meta, module, name, arity}` - traced whenever an
imported function or macro is invoked. `meta` is the call AST metadata,
`module` is the module the import is from, followed by the `name` and `arity`
of the imported function/macro. A :remote_function/:remote_macro event
may still be emitted for the imported module/name/arity.
* `{:imported_quoted, meta, module, name, [arity]}` - traced whenever an
imported function or macro is processed inside a `quote/2`. `meta` is the
call AST metadata, `module` is the module the import is from, followed by
the `name` and a list of `arities` of the imported function/macro.
* `{:alias, meta, alias, as, opts}` - traced whenever `alias` is aliased
to `as`. `meta` is the alias AST metadata and `opts` are the alias options.
* `{:alias_expansion, meta, as, alias}` traced whenever there is an alias
expansion for a previously defined `alias`, i.e. when the user writes `as`
which is expanded to `alias`. `meta` is the alias expansion AST metadata.
* `{:alias_reference, meta, module}` - traced whenever there is an alias
in the code, i.e. whenever the user writes `MyModule.Foo.Bar` in the code,
regardless if it was expanded or not.
* `{:require, meta, module, opts}` - traced whenever `module` is required.
`meta` is the require AST metadata and `opts` are the require options.
If the `meta` option contains the `:from_macro`, then module was called
from within a macro and therefore must be treated as a compile-time dependency.
* `{:struct_expansion, meta, module, keys}` - traced whenever `module`'s struct
is expanded. `meta` is the struct AST metadata and `keys` are the keys being
used by expansion
* `{:remote_function, meta, module, name, arity}` and
`{:remote_macro, meta, module, name, arity}` - traced whenever a remote
function or macro is referenced. `meta` is the call AST metadata, `module`
is the invoked module, followed by the `name` and `arity`.
* `{:local_function, meta, name, arity}` and
`{:local_macro, meta, name, arity}` - traced whenever a local
function or macro is referenced. `meta` is the call AST metadata, followed by
the `name` and `arity`.
* `{:compile_env, app, path, return}` - traced whenever `Application.compile_env/3`
or `Application.compile_env!/2` are called. `app` is an atom, `path` is a list
of keys to traverse in the application environment and `return` is either
`{:ok, value}` or `:error`.
* `:defmodule` - (since v1.16.2) traced as soon as the definition of a module
starts. This is invoked early on in the module life cycle, `Module.open?/1`
still returns `false` for such traces
* `{:on_module, bytecode, _ignore}` - (since v1.13.0) traced whenever a module
is defined. This is equivalent to the `@after_compile` callback and invoked
after any `@after_compile` in the given module. The third element is currently
`:none` but it may provide more metadata in the future. It is best to ignore
it at the moment. Note that `Module` functions expecting not yet compiled modules
(such as `Module.definitions_in/1`) are still available at the time this event
is emitted.
The `:tracers` compiler option can be combined with the `:parser_options`
compiler option to enrich the metadata of the traced events above.
New events may be added at any time in the future, therefore it is advised
for the `trace/2` function to have a "catch-all" clause.
Below is an example tracer that prints all remote function invocations:
defmodule MyTracer do
def trace({:remote_function, _meta, module, name, arity}, env) do
IO.puts("#{env.file}:#{env.line} #{inspect(module)}.#{name}/#{arity}")
:ok
end
def trace(_event, _env) do
:ok
end
end
"""
@typedoc """
A list with all variables and their values.
The binding keys are usually atoms, but they may be a tuple for variables
defined in a different context.
"""
@type binding :: [{atom() | tuple(), any}]
@typedoc """
Diagnostics returned by the compiler and code evaluation.
The file and position relate to where the diagnostic should be shown.
If there is a file and position, then the diagnostic is precise
and you can use the given file and position for generating snippets,
IDEs annotations, and so on. An optional span is available with
the line and column the diagnostic ends.
Otherwise, a stacktrace may be given, which you can place your own
heuristics to provide better reporting.
The source field points to the source file the compiler tracked
the error to. For example, a file `lib/foo.ex` may embed `.eex`
templates from `lib/foo/bar.eex`. A syntax error on the EEx template
will point to file `lib/foo/bar.eex` but the source is `lib/foo.ex`.
"""
@type diagnostic(severity) :: %{
required(:source) => Path.t() | nil,
required(:file) => Path.t() | nil,
required(:severity) => severity,
required(:message) => String.t(),
required(:position) => position(),
required(:stacktrace) => Exception.stacktrace(),
required(:span) => {line :: pos_integer(), column :: pos_integer()} | nil,
optional(:details) => term(),
optional(any()) => any()
}
@typedoc "The line. 0 indicates no line."
@type line() :: non_neg_integer()
@typedoc """
The position of the diagnostic.
Can be either a line number or a `{line, column}`.
Line and columns numbers are one-based.
A position of `0` represents unknown.
"""
@type position() :: line() | {line :: pos_integer(), column :: pos_integer()}
@typedoc """
Options for code formatting functions.
"""
@type format_opt ::
{:file, binary()}
| {:line, pos_integer()}
| {:line_length, pos_integer()}
| {:locals_without_parens, keyword()}
| {:force_do_end_blocks, boolean()}
| {:migrate, boolean()}
| {:migrate_bitstring_modifiers, boolean()}
| {:migrate_call_parens_on_pipe, boolean()}
| {:migrate_charlists_as_sigils, boolean()}
| {:migrate_unless, boolean()}
| {atom(), term()}
@typedoc """
Options for `quoted_to_algebra/2`.
"""
@type quoted_to_algebra_opt ::
{:line, pos_integer() | nil}
| {:escape, boolean()}
| {:locals_without_parens, keyword()}
| {:comments, [term()]}
@typedoc """
Options for parsing functions that convert strings to quoted expressions.
"""
@type parser_opts :: [
file: binary(),
line: pos_integer(),
column: pos_integer(),
indentation: non_neg_integer(),
columns: boolean(),
unescape: boolean(),
existing_atoms_only: boolean(),
token_metadata: boolean(),
literal_encoder: (term(), Macro.metadata() -> term()),
static_atoms_encoder: (binary(), Macro.metadata() -> {:ok, term()} | {:error, binary()}),
emit_warnings: boolean()
]
@typedoc """
Options for evaluation environment, accepted by `env_for_eval/1`.
"""
@type env_eval_opt ::
{:file, binary()}
| {:line, pos_integer()}
| {:module, module()}
@typedoc """
Options for evaluation functions like `eval_string/3`, `eval_quoted/3`
and `eval_quoted_with_env/4`.
"""
@type eval_opt ::
{:prune_binding, boolean()}
| {:dbg_callback, {module(), atom(), list()}}
@boolean_compiler_options [
:docs,
:debug_info,
:ignore_already_consolidated,
:ignore_module_conflict,
:relative_paths
]
@list_compiler_options [:tracers, :parser_options]
@available_compiler_options @boolean_compiler_options ++
@list_compiler_options ++
[
:on_undefined_variable,
:infer_signatures,
:no_warn_undefined,
:module_definition
]
@doc """
Lists all required files.
## Examples
Code.require_file("../eex/test/eex_test.exs")
List.first(Code.required_files()) =~ "eex_test.exs"
#=> true
"""
@doc since: "1.7.0"
@spec required_files() :: [binary]
def required_files do
:elixir_code_server.call(:required)
end
@deprecated "Use Code.required_files/0 instead"
@doc false
def loaded_files do
required_files()
end
@doc false
@deprecated "Use Code.Fragment.cursor_context/2 instead"
def cursor_context(code, options \\ []) do
Code.Fragment.cursor_context(code, options)
end
@doc """
Removes files from the required files list.
The modules defined in the file are not removed;
calling this function only removes them from the list,
allowing them to be required again.
The list of files is managed per Erlang VM node.
## Examples
# Require EEx test code
Code.require_file("../eex/test/eex_test.exs")
# Now unrequire all files
Code.unrequire_files(Code.required_files())
# Note that modules are still available
function_exported?(EExTest.Compiled, :before_compile, 0)
#=> true
"""
@doc since: "1.7.0"
@spec unrequire_files([binary]) :: :ok
def unrequire_files(files) when is_list(files) do
:elixir_code_server.cast({:unrequire_files, files})
end
@deprecated "Use Code.unrequire_files/1 instead"
@doc false
def unload_files(files) do
unrequire_files(files)
end
@doc """
Appends a path to the Erlang VM code path list.
This is the list of directories the Erlang VM uses for
finding module code. The list of files is managed per Erlang
VM node.
The path is expanded with `Path.expand/1` before being appended.
It requires the path to exist. Returns a boolean indicating if
the path was successfully added.
## Examples
Code.append_path(".")
#=> true
Code.append_path("/does_not_exist")
#=> false
## Options
* `:cache` - (since v1.15.0) when true, the code path is cached
the first time it is traversed in order to reduce file system
operations.
"""
@spec append_path(Path.t(), cache: boolean()) :: true | false
def append_path(path, opts \\ []) do
apply(:code, :add_pathz, [to_charlist(Path.expand(path)) | cache(opts)]) == true
end
@doc """
Prepends a path to the Erlang VM code path list.
This is the list of directories the Erlang VM uses for
finding module code. The list of files is managed per Erlang
VM node.
The path is expanded with `Path.expand/1` before being prepended.
It requires the path to exist. Returns a boolean indicating if
the path was successfully added.
## Examples
Code.prepend_path(".")
#=> true
Code.prepend_path("/does_not_exist")
#=> false
## Options
* `:cache` - (since v1.15.0) when true, the code path is cached
the first time it is traversed in order to reduce file system
operations.
"""
@spec prepend_path(Path.t(), cache: boolean()) :: boolean()
def prepend_path(path, opts \\ []) do
apply(:code, :add_patha, [to_charlist(Path.expand(path)) | cache(opts)]) == true
end
@doc """
Prepends a list of `paths` to the Erlang VM code path list.
This is the list of directories the Erlang VM uses for
finding module code. The list of files is managed per Erlang
VM node.
All paths are expanded with `Path.expand/1` before being prepended.
Only existing paths are prepended. This function always returns `:ok`,
regardless of how many paths were prepended. Use `prepend_path/1`
if you need more control.
## Examples
Code.prepend_paths([".", "/does_not_exist"])
#=> :ok
## Options
* `:cache` - when true, the code path is cached the first time
it is traversed in order to reduce file system operations.
"""
@doc since: "1.15.0"
@spec prepend_paths([Path.t()], cache: boolean()) :: :ok
def prepend_paths(paths, opts \\ []) when is_list(paths) do
apply(:code, :add_pathsa, [Enum.map(paths, &to_charlist(Path.expand(&1))) | cache(opts)])
end
@doc """
Appends a list of `paths` to the Erlang VM code path list.
This is the list of directories the Erlang VM uses for
finding module code. The list of files is managed per Erlang
VM node.
All paths are expanded with `Path.expand/1` before being appended.
Only existing paths are appended. This function always returns `:ok`,
regardless of how many paths were appended. Use `append_path/1`
if you need more control.
## Examples
Code.append_paths([".", "/does_not_exist"])
#=> :ok
## Options
* `:cache` - when true, the code path is cached the first time
it is traversed in order to reduce file system operations.
"""
@doc since: "1.15.0"
@spec append_paths([Path.t()], cache: boolean()) :: :ok
def append_paths(paths, opts \\ []) when is_list(paths) do
apply(:code, :add_pathsz, [Enum.map(paths, &to_charlist(Path.expand(&1))) | cache(opts)])
end
defp cache(opts) do
if function_exported?(:code, :add_path, 2) do
if opts[:cache], do: [:cache], else: [:nocache]
else
[]
end
end
@doc """
Deletes a path from the Erlang VM code path list.
This is the list of directories the Erlang VM uses for finding
module code. The list of files is managed per Erlang VM node.
The path is expanded with `Path.expand/1` before being deleted. If the
path does not exist, this function returns `false`.
## Examples
Code.prepend_path(".")
Code.delete_path(".")
#=> true
Code.delete_path("/does_not_exist")
#=> false
"""
@spec delete_path(Path.t()) :: boolean
def delete_path(path) do
case :code.del_path(to_charlist(Path.expand(path))) do
result when is_boolean(result) ->
result
{:error, :bad_name} ->
raise ArgumentError,
"invalid argument #{inspect(path)}"
end
end
@doc """
Deletes a list of paths from the Erlang VM code path list.
This is the list of directories the Erlang VM uses for finding
module code. The list of files is managed per Erlang VM node.
The path is expanded with `Path.expand/1` before being deleted. If the
path does not exist, this function returns `false`.
"""
@doc since: "1.15.0"
@spec delete_paths([Path.t()]) :: :ok
def delete_paths(paths) when is_list(paths) do
for path <- paths do
_ = :code.del_path(to_charlist(Path.expand(path)))
end
:ok
end
@doc """
Evaluates the contents given by `string`.
The `binding` argument is a list of all variables and their values.
The `opts` argument is a keyword list of environment options.
**Warning**: `string` can be any Elixir code and will be executed with
the same privileges as the Erlang VM: this means that such code could
compromise the machine (for example by executing system commands).
Don't use `eval_string/3` with untrusted input (such as strings coming
from the network).
## Options
It accepts the same options as both `env_for_eval/1` and
`eval_quoted_with_env/4`. Additionally, you may also pass an environment
as third argument, so the evaluation happens within that environment.
## Return
Returns a tuple of the form `{value, binding}`, where `value` is the value
returned from evaluating `string`. If an error occurs while evaluating
`string`, an exception will be raised.
`binding` is a list with all variable names and their values after evaluating
`string`. The binding keys are usually atoms, but they may be a tuple for variables
defined in a different context. The names are in no particular order.
## Examples
iex> {result, binding} = Code.eval_string("a + b", [a: 1, b: 2], file: __ENV__.file, line: __ENV__.line)
iex> result
3
iex> Enum.sort(binding)
[a: 1, b: 2]
iex> {result, binding} = Code.eval_string("c = a + b", [a: 1, b: 2], __ENV__)
iex> result
3
iex> Enum.sort(binding)
[a: 1, b: 2, c: 3]
iex> {result, binding} = Code.eval_string("a = a + b", [a: 1, b: 2])
iex> result
3
iex> Enum.sort(binding)
[a: 3, b: 2]
For convenience, you can pass `__ENV__/0` as the `opts_or_env` argument and
all imports, requires and aliases defined in the current environment
will be automatically carried over:
iex> require Integer, warn: false
iex> {result, binding} = Code.eval_string("if Integer.is_odd(a), do: a + b", [a: 1, b: 2], __ENV__)
iex> result
3
iex> Enum.sort(binding)
[a: 1, b: 2]
"""
@spec eval_string(List.Chars.t(), binding, Macro.Env.t() | [eval_opt | env_eval_opt]) ::
{term, binding}
def eval_string(string, binding \\ [], opts_or_env \\ [])
def eval_string(string, binding, %Macro.Env{} = env) do
validated_eval_string(string, validate_binding(binding), env_for_eval(env), [])
end
def eval_string(string, binding, opts) when is_list(opts) do
validated_eval_string(string, validate_binding(binding), env_for_eval(opts), opts)
end
defp validate_binding(binding) when is_list(binding), do: binding
defp validate_binding(binding) do
raise ArgumentError, "binding must be a list, got: #{inspect(binding)}"
end
defp validated_eval_string(string, binding, env, opts) do
%{line: line, file: file} = env
forms = :elixir.string_to_quoted!(to_charlist(string), line, 1, file, [])
{value, binding, _env} = eval_verify(:eval_forms, [forms, binding, env, opts])
{value, binding}
end
defp eval_verify(fun, args) do
Module.ParallelChecker.verify(fn ->
apply(:elixir, fun, args)
end)
end
@doc """
Executes the given `fun` and capture all diagnostics.
Diagnostics are warnings and errors emitted during code
evaluation or single-file compilation and by functions
such as `IO.warn/2`.
If using `mix compile` or `Kernel.ParallelCompiler`,
note they already capture and return diagnostics.
## Options
* `:log` - if the diagnostics should be logged as they happen.
Defaults to `false`.
> #### Rescuing errors {: .info}
>
> `with_diagnostics/2` does not automatically handle exceptions.
> You may capture them by adding a `try/1` in `fun`:
>
> {result, all_errors_and_warnings} =
> Code.with_diagnostics(fn ->
> try do
> {:ok, Code.compile_quoted(quoted)}
> rescue
> err -> {:error, err}
> end
> end)
"""
@doc since: "1.15.0"
@spec with_diagnostics([log: boolean()], (-> result)) ::
{result, [diagnostic(:warning | :error)]}
when result: term()
def with_diagnostics(opts \\ [], fun) do
value = :erlang.get(:elixir_code_diagnostics)
log = Keyword.get(opts, :log, false)
:erlang.put(:elixir_code_diagnostics, {[], log})
try do
result = fun.()
{diagnostics, _log?} = :erlang.get(:elixir_code_diagnostics)
{result, Enum.reverse(diagnostics)}
after
if value == :undefined do
:erlang.erase(:elixir_code_diagnostics)
else
:erlang.put(:elixir_code_diagnostics, value)
end
end
end
@doc """
Prints a diagnostic into the standard error.
A diagnostic is either returned by `Kernel.ParallelCompiler`
or by `Code.with_diagnostics/2`.
## Options
* `:snippet` - whether to read the code snippet in the diagnostic location.
As it may impact performance, it is not recommended to be used in runtime.
Defaults to `true`.
"""
@doc since: "1.15.0"
@spec print_diagnostic(diagnostic(:warning | :error), snippet: boolean()) :: :ok
def print_diagnostic(diagnostic, opts \\ []) do
read_snippet? = Keyword.get(opts, :snippet, true)
:elixir_errors.print_diagnostic(diagnostic, read_snippet?)
:ok
end
@doc ~S"""
Formats the given code `string`.
The formatter receives a string representing Elixir code and
returns iodata representing the formatted code according to
pre-defined rules.
## Options
Regular options (do not change the AST):
* `:file` - the file which contains the string, used for error
reporting
* `:line` - the line the string starts, used for error reporting
* `:line_length` - the line length to aim for when formatting
the document. Defaults to `98`. This value indicates when an expression
should be broken over multiple lines but it is not guaranteed
to do so. See the "Line length" section below for more information
* `:locals_without_parens` - a keyword list of name and arity
pairs that should be kept without parens whenever possible.
The arity may be the atom `:*`, which implies all arities of
that name. The formatter already includes a list of functions
and this option augments this list.
* `:force_do_end_blocks` (since v1.9.0) - when `true`, converts all
inline usages of `do: ...`, `else: ...` and friends into `do`-`end`
blocks. Defaults to `false`. Note that this option is convergent:
once you set it to `true`, **all keywords** will be converted.
If you set it to `false` later on, `do`-`end` blocks won't be
converted back to keywords.
Migration options (change the AST), see the "Migration formatting" section below:
* `:migrate` (since v1.18.0) - when `true`, sets all other migration options
to `true` by default. Defaults to `false`.
* `:migrate_bitstring_modifiers` (since v1.18.0) - when `true`,
removes unnecessary parentheses in known bitstring
[modifiers](`<<>>/1`), for example `<<foo::binary()>>`
becomes `<<foo::binary>>`, or adds parentheses for custom
modifiers, where `<<foo::custom_type>>` becomes `<<foo::custom_type()>>`.
Defaults to the value of the `:migrate` option. This option changes the AST.
* `:migrate_call_parens_on_pipe` (since v1.19.0) - when `true`,
formats calls on the right-hand side of the pipe operator to always include
parentheses, for example `foo |> bar` becomes `foo |> bar()` and
`foo |> mod.fun` becomes `foo |> mod.fun()`.
Parentheses are always added for qualified calls like `foo |> Bar.bar` even
when this option is `false`.
Defaults to the value of the `:migrate` option. This option changes the AST.
* `:migrate_charlists_as_sigils` (since v1.18.0) - when `true`,
formats charlists as [`~c`](`Kernel.sigil_c/2`) sigils, for example
`'foo'` becomes `~c"foo"`.
Defaults to the value of the `:migrate` option. This option changes the AST.
* `:migrate_unless` (since v1.18.0) - when `true`,
rewrites `unless` expressions using `if` with a negated condition, for example
`unless foo, do:` becomes `if !foo, do:`.
Defaults to the value of the `:migrate` option. This option changes the AST.
## Design principles
The formatter was designed under three principles.
First, the formatter never changes the semantics of the code by default.
This means the input AST and the output AST are almost always equivalent.
The second principle is to provide as little configuration as possible.
This eases the formatter adoption by removing contention points while
making sure a single style is followed consistently by the community as
a whole.
The formatter does not hard code names. The formatter will not behave
specially because a function is named `defmodule`, `def`, or the like. This
principle mirrors Elixir's goal of being an extensible language where
developers can extend the language with new constructs as if they were
part of the language. When it is absolutely necessary to change behavior
based on the name, this behavior should be configurable, such as the
`:locals_without_parens` option.
## Running the formatter
The formatter attempts to fit the most it can on a single line and
introduces line breaks wherever possible when it cannot.
In some cases, this may lead to undesired formatting. Therefore, **some
code generated by the formatter may not be aesthetically pleasing and
may require explicit intervention from the developer**. That's why we
do not recommend to run the formatter blindly in an existing codebase.
Instead you should format and sanity check each formatted file.
For example, the formatter may break a long function definition over
multiple clauses:
def my_function(
%User{name: name, age: age, ...},
arg1,
arg2
) do
...
end
While the code above is completely valid, you may prefer to match on
the struct variables inside the function body in order to keep the
definition on a single line:
def my_function(%User{} = user, arg1, arg2) do
%{name: name, age: age, ...} = user
...
end
In some situations, you can use the fact the formatter does not generate
elegant code as a hint for refactoring. Take this code:
def board?(board_id, %User{} = user, available_permissions, required_permissions) do
Tracker.OrganizationMembers.user_in_organization?(user.id, board.organization_id) and
required_permissions == Enum.to_list(MapSet.intersection(MapSet.new(required_permissions), MapSet.new(available_permissions)))
end
The code above has very long lines and running the formatter is not going
to address this issue. In fact, the formatter may make it more obvious that
you have complex expressions:
def board?(board_id, %User{} = user, available_permissions, required_permissions) do
Tracker.OrganizationMembers.user_in_organization?(user.id, board.organization_id) and
required_permissions ==
Enum.to_list(
MapSet.intersection(
MapSet.new(required_permissions),
MapSet.new(available_permissions)
)
)
end
Take such cases as a suggestion that your code should be refactored:
def board?(board_id, %User{} = user, available_permissions, required_permissions) do
Tracker.OrganizationMembers.user_in_organization?(user.id, board.organization_id) and
matching_permissions?(required_permissions, available_permissions)
end
defp matching_permissions?(required_permissions, available_permissions) do
intersection =
required_permissions
|> MapSet.new()
|> MapSet.intersection(MapSet.new(available_permissions))
|> Enum.to_list()
required_permissions == intersection
end
To sum it up: since the formatter cannot change the semantics of your
code, sometimes it is necessary to tweak or refactor the code to get
optimal formatting. To help better understand how to control the formatter,
we describe in the next sections the cases where the formatter keeps the
user encoding and how to control multiline expressions.
## Line length
Another point about the formatter is that the `:line_length` configuration
indicates when an expression should be broken over multiple lines but it is
not guaranteed to do so. In many cases, it is not possible for the formatter
to break your code apart, which means it will go over the line length.
For example, if you have a long string:
"this is a very long string that will go over the line length"
The formatter doesn't know how to break it apart without changing the
code underlying syntax representation, so it is up to you to step in:
"this is a very long string " <>
"that will go over the line length"
The string concatenation makes the code fit on a single line and also
gives more options to the formatter.
This may also appear in keywords such as do/end blocks and operators,
where the `do` keyword may go over the line length because there is no
opportunity for the formatter to introduce a line break in a readable way.
For example, if you do:
case very_long_expression() do
end
And only the `do` keyword is beyond the line length, Elixir **will not**
emit this:
case very_long_expression()
do
end
So it prefers to not touch the line at all and leave `do` above the
line limit.
## Keeping user's formatting
The formatter respects the input format in some cases. Those are
listed below:
* Insignificant digits in numbers are kept as is. The formatter,
however, always inserts underscores for decimal numbers with more
than 5 digits and converts hexadecimal digits to uppercase
* Strings, charlists, atoms and sigils are kept as is. No character
is automatically escaped or unescaped. The choice of delimiter is
also respected from the input
* Newlines inside blocks are kept as in the input except for:
1) expressions that take multiple lines will always have an empty
line before and after and 2) empty lines are always squeezed
together into a single empty line
* The choice between `:do` keyword and `do`-`end` blocks is left
to the user
* Lists, tuples, bitstrings, maps, structs and function calls will be
broken into multiple lines if they are followed by a newline in the
opening bracket and preceded by a new line in the closing bracket
* Newlines before certain operators (such as the pipeline operators)
and before other operators (such as comparison operators)
The behaviors above are not guaranteed. We may remove or add new
rules in the future. The goal of documenting them is to provide better
understanding on what to expect from the formatter.
### Multi-line lists, maps, tuples, and the like
You can force lists, tuples, bitstrings, maps, structs and function
calls to have one entry per line by adding a newline after the opening
bracket and a new line before the closing bracket lines. For example:
[
foo,
bar
]
If there are no newlines around the brackets, then the formatter will
try to fit everything on a single line, such that the snippet below
[foo,
bar]
will be formatted as
[foo, bar]
You can also force function calls and keywords to be rendered on multiple
lines by having each entry on its own line:
defstruct name: nil,
age: 0
The code above will be kept with one keyword entry per line by the
formatter. To avoid that, just squash everything into a single line.
### Parens and no parens in function calls
Elixir has two syntaxes for function calls. With parens and no parens.
By default, Elixir will add parens to all calls except for:
1. calls that have `do`-`end` blocks
2. local calls without parens where the name and arity of the local
call is also listed under `:locals_without_parens` (except for
calls with arity 0, where the compiler always require parens)