@@ -654,6 +654,8 @@ defmodule Code do
654
654
655
655
## Options
656
656
657
+ Regular options (do not change the AST):
658
+
657
659
* `:file` - the file which contains the string, used for error
658
660
reporting
659
661
@@ -677,28 +679,29 @@ defmodule Code do
677
679
If you set it to `false` later on, `do`-`end` blocks won't be
678
680
converted back to keywords.
679
681
680
- * `:normalize_bitstring_modifiers` (since v1.14.0) - when `true`,
682
+ Migration options (change the AST), see the "Migration formatting" section below:
683
+
684
+ * `:migrate` (since v1.18.0) - when `true`, sets all other migration options
685
+ to `true` by default. Defaults to `false`.
686
+
687
+ * `:migrate_bitstring_modifiers` (since v1.18.0) - when `true`,
681
688
removes unnecessary parentheses in known bitstring
682
689
[modifiers](`<<>>/1`), for example `<<foo::binary()>>`
683
690
becomes `<<foo::binary>>`, or adds parentheses for custom
684
691
modifiers, where `<<foo::custom_type>>` becomes `<<foo::custom_type()>>`.
685
- Defaults to `true` . This option changes the AST.
692
+ Defaults to the value of the `:migrate` option . This option changes the AST.
686
693
687
- * `:normalize_charlists_as_sigils ` (since v1.15 .0) - when `true`,
694
+ * `:migrate_charlists_as_sigils ` (since v1.18 .0) - when `true`,
688
695
formats charlists as [`~c`](`Kernel.sigil_c/2`) sigils, for example
689
696
`'foo'` becomes `~c"foo"`.
690
- Defaults to `true` . This option changes the AST.
697
+ Defaults to the value of the `:migrate` option . This option changes the AST.
691
698
692
699
## Design principles
693
700
694
701
The formatter was designed under three principles.
695
702
696
- First, the formatter never changes the semantics of the code.
703
+ First, the formatter never changes the semantics of the code by default .
697
704
This means the input AST and the output AST are almost always equivalent.
698
- The only cases where the formatter will change the AST is when the input AST
699
- would cause *compiler warnings* and the output AST won't. The cases where
700
- the formatter changes the AST can be disabled through formatting options
701
- if desired.
702
705
703
706
The second principle is to provide as little configuration as possible.
704
707
This eases the formatter adoption by removing contention points while
@@ -986,6 +989,21 @@ defmodule Code do
986
989
## Newlines
987
990
988
991
The formatter converts all newlines in code from `\r\n` to `\n`.
992
+
993
+ ## Migration formatting
994
+
995
+ As part of the Elixir release cycle, deprecations are being introduced,
996
+ emitting warnings which might require existing code to be changed.
997
+ In order to reduce the burden on developers when upgrading Elixir to the
998
+ next version, the formatter exposes some options, disabled by default,
999
+ in order to automate this process.
1000
+
1001
+ These options should address most of the typical use cases, but given they
1002
+ introduce changes to the AST, there is a non-zero risk for meta-programming
1003
+ heavy projects that relied on a specific AST, or projects that are
1004
+ re-defining functions from the `Kernel`. In such cases, migrations cannot
1005
+ be applied blindly and some extra changes might be needed in order to
1006
+ address the deprecation warnings.
989
1007
"""
990
1008
@ doc since: "1.6.0"
991
1009
@ spec format_string! ( binary , keyword ) :: iodata
0 commit comments