aboutsummaryrefslogtreecommitdiffstats
path: root/lib/stdlib/src/epp.erl
AgeCommit message (Collapse)Author
2018-05-09epp: Implement the -if and -elif preprocessor directivesBjörn Gustavsson
Libraries or applications that support more than one major release of OTP may need to use conditional compilation of Erlang source code. Here are few examples where it would be necessary or desirable: * To support a new data type or language feature only available in the latest major release (real-world examples: maps and the stacktrace syntax). * To avoid warnings for deprecated functions. * To avoid dialyzer warnings. Previously, to do conditional compilation, one would have to use a parse transform or some external tool such as 'autoconf'. To simplify conditional compilation, introduce the -if and -elif preprocessor directives, to allow code like this to be written: -if(?OTP_RELEASE =:= 21). %% Code that will only work in OTP 21. -else. %% Fallback code. -endif. What kind of expressions should be allowed after an -if? We certainly don't want to allow anything with a side effect, such as a '!' or a 'receive'. We also don't want it to be possible to call erlang:system_info/1, as that could make the code depedent on features of the run-time system that could change very easily (such as the number of schedulers). Requiring the expression to be a guard expression makes most sense. It is to explain in the documentation and easy for users to understand. For simplicity of implementation, only a single guard expression will be supported; that is, the ',' and ';' syntax for guards is not supported. To allow some useful conditions to be written, there is a special built-in function: defined(Symbol) tests whether the preprocessor symbol is defined, just like -ifdef. The reason for having this defined/1 is that the defined test can be combined with other tests, for example: 'defined(SOME_NAME) andalso ?OTP_RELEASE > 21'.
2018-05-06epp: Add the pre-defined macro OTP_RELEASEBjörn Gustavsson
Add a new pre-defined macro called OTP_RELEASE that will expand to an integer being the OTP version. Thus, in OTP 19 the value will be the integer 19. The OTP_RELEASE macro is particularly useful in order to have different source code depending on new language features or new features in the type specification syntax. Those features are only introduced in major versions of OTP. To be truly useful, the -if preprocessor directive need to be implemented. That is the purpose of the next commit. Code that will need to work in both OTP 18 and OTP 19 can be structured in the following way: -ifdef(OTP_RELEASE). %% Code that only works in OTP 19 and later. -else. %% Code that will work in OTP 18. -endif.
2018-02-23Merge branch 'maint'Hans Bolinder
* maint: stdlib: Correct a minor epp bug
2018-02-21stdlib: Correct a minor epp bugHans Bolinder
The bug was introduced in 87a0af4 (R18).
2017-07-06stdlib: Do not use deprecated functions in string(3)Hans Bolinder
2017-06-09stdlib: Handle Unicode macro namesHans Bolinder
2017-05-04Update copyright yearRaimo Niskanen
2017-03-08stdlib: Fix handling of locations and annotationsHans Bolinder
2016-06-13stdlib: Let epp handle long file namesHans Bolinder
2016-05-04epp: Add the -error and -warning directivesBjörn Gustavsson
If one of several alternatives configurations are required for an Erlang module to compile, but none are available, it would be useful to give a nice error message. For example: -ifdef(CONFIG_A). %% Some code if A is true. -else. -ifdef(CONFIG_B). %% Some code if B is true. -else. -error("Neither CONFIG_A nor CONFIG_B are available"). -endif. -endif. If neither CONFIG_A nor CONFIG_B are defined, the error message will be: module.erl:10: -error("Neither CONFIG_A nor CONFIG_B are available"). That is basically the same behavior as for the #error directive in GCC. For symmetry with the -error directive, add the -warning directive to generate a compiler warning. For example: -ifdef(HAVE_COOL_FEATURE). %% Code if we have Cool Feature. -else. %% Inefficient fallback code. -warning("Using inefficient fallback"). -endif. If HAVE_COOL_FEATURE is not defined, the warning message will be: module.erl:8: Warning: -warning("Using inefficient fallback"). That is basically the same behavior as for the #warning directive in GCC. Conflicts: lib/stdlib/src/epp.erl lib/stdlib/test/epp_SUITE.erl
2016-05-04epp: Refactor expansion of header pathBjörn Gustavsson
scan_include_lib/4 uses a helper function find_lib_dir/1, which has a strange interface. It takes a string and returns a tuple. The caller must match the tuple and call fname_join/1 to obtain the desired result. I assume that the strange interface was not noticed because the function is only used in one place. Replace the find_lib_dir/1 with a new expand_lib_dir/1 function which does the entire job in one go. The new function is much easier to reuse in other places, which we might want to do in a future commit.
2016-04-28stdlib: Correct a type in module eppHans Bolinder
2016-02-17Implement ?FUNCTION_NAME and ?FUNCTION_ARITY macrosBjörn Gustavsson
For a long time, users have asked for one or more macros that would return the name and arity of the current function. We could define a single ?FUNCTION macro that would return a {Name,Arity} tuple. However, to access just the name or just the arity for the function, element/2 must be used. That would limit its usefulness, because element/2 is not allowed in all contexts. Therefore, it seems that we will need two macros. ?FUNCTION_NAME that expands to the name of the current function and ?FUNCTION_ARITY that expands to arity of the current function. Converting the function name to a string can be done like this: f() -> atom_to_list(?FUNCTION_NAME) ++ "/" ++ integer_to_list(?FUNCTION_ARITY). f/0 will return "f/0". The BEAM compiler will evaluate the entire expression at compile-time, so there will not be any run-time penalty for the function calls. The implementation is non-trivial because the preprocessor is run before the parser. One way to implement the macros would be to replace them with some placeholder and then let the parser or possibly a later pass replace the placeholder with correct value. That could potentially slow down the compiler and cause incompatibilities for parse transforms. Another way is to let the preprocessor do the whole job. That means that the preprocessor will have to scan the function head to find out the name and arity. The scanning of the function head can be delayed until the first occurrence of a ?FUNCTION_NAME or ?FUNCTION_ARITY. I have chosen the second way because it seems less likely to cause weird compatibility problems.
2016-02-17epp: Refactor expand_macros()Björn Gustavsson
As a preparation for implementing a ?FUNCTION macro, pass the entire state record to expand_macros/2 and its helpers. That will allow us to have more information available when expanding ?FUNCTION.
2016-02-17stdlib: Modify the preprocessor as to expose typed record fieldsHans Bolinder
Problem: The types of record fields have since R12B been put in a separate form by epp:parse_file(), leaving the record declaration form untyped. The separate form, however, does not follow the syntax of type declarations, and parse transforms inspecting -type() attributes need to know about the special syntax. Since the compiler stores the return value of epp:parse_file() as debug information in the abstract code chunk ("Abst" or 'abstract_code'), tools too need to know about the special syntax, if they inspect -type() attributes in abstract code. Solution: As of this commit no separate form is created by epp:parse_file(), but the type information kept in the record fields. This means that all parse transforms and all tools inspecting -record() declarations need to recognize {typed_record_field, Field, Type}. We recommend that all parse transforms and tools be updated as to recognize typed record fields. Discussion: As of OTP 19.0, the abstract form of type declarations and function specifications is documented. An (unsatisfactory) alternative to the above solution is to document two formats of the abstract form of typed record fields: one if returned by epp:parse_file(); and one if returned by, for example, epp:parse_erl_form(). Yet another (bad) alternative is to not document the format returned by epp:erl_parse(), but instead document the idempotent function epp:restore_typed_record_fields/1, and urge authors of parse transform and tools to always call this function.
2015-11-18epp: Only flatten the original filenameBjörn Gustavsson
There is no need to flatten filenames using file_name/1 every time the current filename changes. Any filename obtained from a source file will be already flattened. Only the original source filename may need flattening.
2015-11-17epp: Modernize the internal data structuresBjörn Gustavsson
Use maps instead of 'dict'. Remove the {atom,MacroName} wrappers that were used for historical reasons.
2015-11-17epp: Eliminate the Type argument from expand_macros/5Björn Gustavsson
The Type argument is always 'atom', so there is no need for the argument.
2015-11-17epp: Refactor user_predef/2 to share more codeBjörn Gustavsson
2015-11-17epp: Refactor scan_define()Björn Gustavsson
Refactor scan_define() in order to share more between macros without any arguments and macros with arguments.
2015-11-17epp: Remove vestigial support for packagesBjörn Gustavsson
Packages were removed in 34d865a7dfdb33 (R16), but the 'epp' module was forgotten.
2015-10-08Update Kernel and STDLIBHans Bolinder
Record field types have been modified due to commit 8ce35b2: "Take out automatic insertion of 'undefined' from typed record fields".
2015-06-18Change license text to APLv2Bruce Yinhe
2015-04-30stdlib: Use module erl_annoHans Bolinder
2014-06-16Fix handling of latin1 characters in false ifdef branchesBjörn Gustavsson
The fallback to latin-1 encoding would not work if the invalid UTF-8 characters occurred in a skipped branch in an -ifdef/-ifndef.
2014-03-24stdlib: Add more types to epp and erl_lintHans Bolinder
2014-03-18epp: Make it possible to specify a default encodingBjörn Gustavsson
In the next commit, we will need a way to tell epp which the default encoding should be for files that have no encoding comment. We could add new open() and parse_file() functions with one extra argument for the encoding, but there are already too many variants. To avoid having to add an additional argument to epp:open() and epp:parse_file() each time new options are needed, introduce epp:open/1 and epp:parse_file/2 that takes a property list with options. Also support the new 'default_encoding' option for specifying the default encoding for source files. Thanks to Richard Carlsson for the idea and the implementation of the new functionality in epp.erl.
2014-02-23Deprecate pre-defined built-in typesHans Bolinder
The types array(), dict(), digraph(), gb_set(), gb_tree(), queue(), set(), and tid() have been deprecated. They will be removed in OTP 18.0. Instead the types array:array(), dict:dict(), digraph:graph(), gb_set:set(), gb_tree:tree(), queue:queue(), sets:set(), and ets:tid() can be used. (Note: it has always been necessary to use ets:tid().) It is allowed in OTP 17.0 to locally re-define the types array(), dict(), and so on. New types array:array/1, dict:dict/2, gb_sets:set/1, gb_trees:tree/2, queue:queue/1, and sets:set/1 have been added.
2014-02-20Fix a bug in epp concerning circular macro definitionsHans Bolinder
epp could loop when encountering a circular macro definition in an included file. Thanks to Maruthavanan Subbarayan for reporting the bug, and to Richard Carlsson for providing a bug fix.
2013-12-12EEP 37: Funs with namesAnthony Ramine
This adds optional names to fun expressions. A named fun expression is parsed as a tuple `{named_fun,Loc,Name,Clauses}` in erl_parse. If a fun expression has a name, it must be present and be the same in every of its clauses. The function name shadows the environment of the expression shadowing the environment and it is shadowed by the environment of the clauses' arguments. An unused function name triggers a warning unless it is prefixed by _, just as every variable. Variable _ is allowed as a function name. It is not an error to put a named function in a record field default value. When transforming to Core Erlang, the named fun Fun is changed into the following expression: letrec 'Fun'/Arity = fun (Args) -> let <Fun> = 'Fun'/Arity in Case in 'Fun'/Arity where Args is the list of arguments of 'Fun'/Arity and Case the Core Erlang expression corresponding to the clauses of Fun. This transformation allows us to entirely skip any k_var to k_local transformation in the fun's clauses bodies.
2013-05-06Fix unmatched_returns warnings in STDLIB and KernelHans Bolinder
2013-05-03Merge branch 'maint'Fredrik Gustafsson
Conflicts: bootstrap/lib/stdlib/ebin/epp.beam
2013-04-26Fix an inconsistent state in eppAnthony Ramine
When entering a new file, epp doesn't properly set #epp.name2 like it does on initialisation, generating a malformed file attribute when it leaves the file.
2013-04-19Change the default encoding of Erlang files to UTF-8Hans Bolinder
2013-04-05Use erlang:demonitor(Ref, [flush]) where applicableLoïc Hoguin
2013-02-15[stdlib] Correct handling of Unicode filenamesHans Bolinder
2013-02-11Make Unicode correctionsHans Bolinder
2013-01-25[stdlib] Introduce new functions epp:read_encoding_from_binary/1,2Hans Bolinder
2013-01-25Extend char() to Unicode charactersHans Bolinder
The code related to the introduction of unicode_string() and unicode_char() has been removed. The types char() and string() have been extended to include Unicode characters. In fact char() was changed some time ago; this commit is about cleaning up the documentation and introduce better names for some functions.
2013-01-16Remove support for the query keyword and query expressionsLoïc Hoguin
2013-01-02[stdlib, kernel] Introduce Unicode support for Erlang source filesHans Bolinder
Expect modifications, additions and corrections. There is a kludge in file_io_server and erl_scan:continuation_location() that's not so pleasing.
2012-08-31Update copyright yearsBjörn-Egil Dahlberg
2012-08-22Revert "Merge branch 'nox/compile-column-numbers' into maint"Lukas Larsson
Column numbers was merged without understanding all the whole story. See mail on erlang-patches for details. This reverts commit df8e67e203b83f95d1e098fec88ad5d0ad840069, reversing changes made to 0c9d90f314f364e5b1301ec89d762baabc57c7aa.
2012-06-02Allow setting of initial position in eppAnthony Ramine
2011-10-17Make epp search directory of current file first when including another fileRichard Carlsson
The expected behaviour of a C-style preprocessor (such as Erlang's epp) is to allow a header file to include another header file in the same directory even though that directory is not explicitly in the include path, and even if the actual include path might reference another directory containing a file with the same name. For example, if src/foo.erl explicitly includes "../include/foo.hrl", then foo.hrl should be able to include "bar.hrl" in that same directory even though "../include" might not be in the search path, and even if another file named bar.hrl could be found using the search path it should not override the one in the same directory as foo.hrl. In Erlang, the most common situation is that a user of an installed application includes a main public header file using include_lib ("appname/include/foo.hrl") and that file includes a secondary header file "bar.hrl". However, if it does this using include_lib, it causes a bootstrapping problem - in the build environment for the application itself, the application is not necessarily found by name. On the other hand, if foo.hrl uses a plain include, then bar.hrl might be found when the application is built (if explicit paths are set in the makefils) but not later on when a user includes the main header file of the installed application via include_lib. By making -include always look in the directory of the current file before it uses the search path, this problem is remedied, and include directives behave in a more intuitive way. This completes a partial fix in R11 that only worked for include_lib().
2011-08-16compiler: Don't create filenames starting with "./"Björn Gustavsson
In the location information tables in the run-time system, source filenames that are the same as the module name plus ".erl" extension are not stored explicitly, thus saving memory. To take advantage of that optimization, avoid complicating the names of files in the current working directory; specifically, make sure that "./" is not prepended to the name.
2011-05-12Types and specifications have been modified and addedHans Bolinder
2010-12-21Remove faulty change left by mistake in eppPatrik Nyblom
2010-12-20Removed dead codePatrik Nyblom
2010-10-28Fix epp bug concerning the file attribute and file inclusionHans Bolinder
Cover did not collect coverage data for files such as Yecc parses containing include directives. The bug has been fixed by modifying epp, the Erlang Code Preprocessor.