aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/src/sys_core_fold.erl
AgeCommit message (Collapse)Author
2011-05-20Update copyright yearsBjörn-Egil Dahlberg
2011-03-25sys_core_fold: Eliminate incorrect warningBjörn Gustavsson
The compiler (sys_core_fold) tries to avoid constructing tuples in case expressions. The following code: c(A, B) -> case {A,B} of {ok,X} -> X; {_,_} -> error end. will be rewritten so that no tuple is built. If a clause requires a tuple to be built as in this code: c(A, B) -> case {A,B} of {ok,X} -> X; V -> V %The tuple will be built here end. the tuple will be built in the clause(s) in which it is needed. If the value returned from the case is not used as in this code: c(A, B) -> case {A,B} of V -> V %Warning: a term is constructed, but never used end, ok. there will be an incorrect warning. Basically, what happens is that the code is reduced to: c(A, B) -> {A,B}, %Warning: a term is constructed, but never used ok. and the optimizer sees that the {A,B} tuple can't possibly be used. Eliminate the warning by adding a 'compiler_generated' annotation to the tuple. Reported-by: Kostis Sagonas
2011-03-25sys_core_fold: Be careful to preserve annotations while optimizingBjörn Gustavsson
2010-06-02Evaluate is_record/3 at compile-time using type informationBjörn Gustavsson
2010-06-02Evaluate element/2 at compile-time using type informationBjörn Gustavsson
The erl_expand_records compiler pass translates the following code: h(X) when X#r1.a =:= 1 -> ok. to (essentially): h({r1,V1,V2}=X) when element(2, X) =:= 1 -> ok. Since the guard can only be executed when the pattern matching has succeeded, we know that the second element in the tuple X must have been bound to V2. Thus we can eliminate the call to element/2 like this: h({r1,V1,V2}=X) when V1 =:= 1 -> ok.
2010-04-27Merge branch 'bg/compiler-suppress-result-ignored' into devErlang/OTP
* bg/compiler-suppress-result-ignored: compiler tests: Eliminate "result of expression is ignored" warnings Silence warnings for expressions that are assigned to "_" OTP-8602 bg/compiler-suppress-result-ignored It is now possible to suppress the warning in code such as "list_to_integer(S), ok" by assigning the ignored value "_" like this: "_ = list_to_integer(S), ok".
2010-04-15Silence warnings for expressions that are assigned to "_"Björn Gustavsson
There is currently no zero-cost way to silence the warning "the result of the expression is ignored", which is issued for code such as: list_to_integer(S), ok Such code can be useful for assertions or input validation. Teach the compiler to silence the warning for expressions that are explicitly assigned to to the "_" variable, such as: _ = list_to_integer(S), ok Implement it by having the v3_core pass annotate calls in Core Erlang like this: let <_> = ( call 'erlang':'list_to_integer'(S) -| ['result_not_wanted'] ) in 'ok' and modifiy sys_core_fold to suppress the warning for any call having the annotation. We deliberately do not make it possible to silence the warnings for expressions like: {build,an,unnecessary,term}, ok or is_list(L), ok because we don't know of any real-world scenarios in which that would be useful.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP