aboutsummaryrefslogtreecommitdiffstats
path: root/lib/stdlib/src
AgeCommit message (Collapse)Author
2016-03-17stdlib: Fix filename:basedir/2,3Björn-Egil Dahlberg
Handle the case when the environment APPDATA is not set.
2016-03-15update copyright-yearHenrik Nord
2016-03-03Merge branch 'bjorn/compiler/binary-comprehensions/OTP-13289'Björn Gustavsson
* bjorn/compiler/binary-comprehensions/OTP-13289: Generalize bit string comprehensions
2016-03-03Rename state_timeout -> event_timeoutRaimo Niskanen
2016-03-03Fix most of the system docs and emacs modeRaimo Niskanen
2016-03-02stdlib: Add filename:basedir/2,3Björn-Egil Dahlberg
2016-03-02Change code_change/4 to {ok,State,Data}Raimo Niskanen
2016-03-01Generalize bit string comprehensionsBjörn Gustavsson
The expression in a bit string comprehension is limited to a literal bit string expression. That is, the following code is legal: << <<X>> || X <- List >> but not this code: << foo(X) || X <- List >> The limitation is annoying. For one thing, tools that transform the abstract format must be careful not to produce code such as: << begin %% Some instrumentation code. <<X>> end || X <- List >> One reason for the limitation could be that we'll get reduce/reduce conflicts if we try to allow an arbitrary expression in a bit string comprehension: binary_comprehension -> '<<' expr '||' lc_exprs '>>' : {bc,?anno('$1'),'$2','$4'}. Unfortunately, there does not seem to be an easy way to work around that problem. The best we can do is to allow 'expr_max' expressions (as in the binary syntax): binary_comprehension -> '<<' expr_max '||' lc_exprs '>>' : {bc,?anno('$1'),'$2','$4'}. That will work, but functions calls must be enclosed in parentheses: << (foo(X)) || X <- List >>
2016-03-01Update appups in kernel, stdlib and sasl for OTP-19Siri Hansen
2016-02-29Sharpen test suiteRaimo Niskanen
2016-02-29Remove the remove_event action and all alikeRaimo Niskanen
Removing events from the internal queues is not necessary with the choosen semantics of the event queue vs. hibernate. In an early implementation it was possible by combining hibernate with e.g. postpone to get an event in the queue that you would not see before processing the postponed event, and therefore should you decide to cancel a timer it was essential to be able to remove that unseen event from the queue. With the choosen semantics you will have to postpone or generate an event for it to be in the event queue, and if you e.g. postpone a timeout event and then cancel the timer it is your mistake. You have seen the event and should know better than to try to cancel the timer. So, the actions: remove_event, cancel_timer, demonitor and unlink are now removed. There have also been some cleanup of the timer handling code.
2016-02-29Merge branch 'maint'Siri Hansen
2016-02-26Relax caller() type check and cleanupRaimo Niskanen
2016-02-26Optimize postponed handlingRaimo Niskanen
2016-02-26Allow actions without containing listRaimo Niskanen
Type check atom state as early as possible
2016-02-26Implement 'keep_state_and_data' and 'stop'Raimo Niskanen
2016-02-25Merge branch 'siri/remove-overload/OTP-13184'Siri Hansen
* siri/remove-overload/OTP-13184: Remove module 'overload' from SASL
2016-02-25Remove {keep_state_and_data}Raimo Niskanen
Correct typo reported by Luïc Hoguin.
2016-02-25Update appups in kernel, stdlib and sasl for OTP-18.3Siri Hansen
2016-02-25Merge branch 'maint'Henrik Nord
2016-02-25Merge branch 'benwilson512/better-maps-with' into maintHenrik Nord
* benwilson512/better-maps-with: Improved maps:with/2 and maps:without/2 algorithm OTP-13376
2016-02-24Type check in APIRaimo Niskanen
2016-02-24Ditch PrevStateRaimo Niskanen
StateName/4 -> StateName/3 handle_event/5 -> handle_event/4
2016-02-24Make first next_event in list arrive firstRaimo Niskanen
Define options as actions that set options, rework the documentation about this.
2016-02-24Ditch State so StateName/5 -> StateName/4Raimo Niskanen
2016-02-23Add {stop_and_reply,Reason,Replies [,Data])Raimo Niskanen
Cleanup some error handling
2016-02-23Rename Client -> CallerRaimo Niskanen
2016-02-22Make callback_option() mandatoryRaimo Niskanen
2016-02-19Hide Data in default format_status/2 if callback crashesRaimo Niskanen
2016-02-19Update terminology to data(), transition_op(), etcRaimo Niskanen
2016-02-19Remove module 'overload' from SASLSiri Hansen
The reason is that the module is not used, and that we se no obvious use case for it.
2016-02-19Add reply([Reply])Raimo Niskanen
2016-02-19Add {keep_state,...} and {keep_state_and_data,...}Raimo Niskanen
2016-02-19stdlib: Let beam_lib restore typed record formsHans Bolinder
Forms with record field types created before OTP 19.0 are replaced by well-formed record forms holding the type information. Tools reading the 'abstract_code' chunk can rely on the returned forms being well-formed, that is, there are no badly formed 'type' attribute forms.
2016-02-18Change initial PrevState to 'undefined'Raimo Niskanen
2016-02-18Write some convenience helpersRaimo Niskanen
2016-02-18Rename retry -> postponeRaimo Niskanen
2016-02-18Rename insert_event -> next_eventRaimo Niskanen
2016-02-18Clean up error report printoutsRaimo Niskanen
2016-02-18Implement option callback_modeRaimo Niskanen
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: Update qlc_pt to handle typed record fieldsHans Bolinder
2016-02-17stdlib: Let the linter detect old typed recordsHans Bolinder
2016-02-17stdlib: Update the linter to handle typed record fieldsHans Bolinder
2016-02-17stdlib: Update erl_expand_records to handle typed record fieldsBjörn Gustavsson
2016-02-17stdlib: Update module shell to handle typed record fieldsHans Bolinder
2016-02-17stdlib: Update ms_transform to handle typed record fieldsHans Bolinder
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.
2016-02-17Merge branch 'maint'Hans Bolinder
* maint: xmerl: Remove 'no_return' Dialyzer warnings xmerl: Add suppression of Dialyzer warnings eunit: Add suppression of Dialyzer warnings debugger: Add suppression of Dialyzer warnings kernel: Add suppression of Dialyzer warnings mnesia: Add suppression of Dialyzer warnings observer: Add suppression of Dialyzer warnings runtime_tools: Add suppression of Dialyzer warnings stdlib: Add suppression of Dialyzer warnings test_server: Add suppression of Dialyzer warnings tools: Add suppression of Dialyzer warnings Conflicts: lib/stdlib/src/erl_lint.erl lib/stdlib/src/otp_internal.erl