diff options
| author | Hans Bolinder <[email protected]> | 2019-04-29 16:13:37 +0200 |
|---|---|---|
| committer | Hans Bolinder <[email protected]> | 2019-05-03 12:17:02 +0200 |
| commit | 60e47cba35ff565a33b25ecb01e96881ab7fe0da (patch) | |
| tree | 511707cede18a65f93dd4d3d852de4da7b97c1e3 /otp_patch_apply | |
| parent | e4c8e5a7997205ccc371415ae5c1caf544b025c6 (diff) | |
| download | otp-60e47cba35ff565a33b25ecb01e96881ab7fe0da.tar.gz otp-60e47cba35ff565a33b25ecb01e96881ab7fe0da.tar.bz2 otp-60e47cba35ff565a33b25ecb01e96881ab7fe0da.zip | |
stdlib: Do not allow specs for functions in other modules
See also https://bugs.erlang.org/browse/ERL-845.
[Kostis:]
My suggestion is that the compiler refuses to compile modules that
contain specs for functions that are not from this module. I do not
remember when / why this `feature' was introduced, but thinking about
it I see a lot of (ugly) semantics issues with it. For example, should
one be allowed to declare in the foo module that lists:flatten/1 takes
an integer() as an argument and returns a binary()? Should one be
allowed to declare a spec in some module m1 for a function of m2 that
is not defined in m2?
There are all kinds of checks that will need to be added to dialyzer
to protect itself from these semantics issues. The compiler already
refuses to compile modules that contain specs for non-existing
functions of the module. Similarly, it should refuse to compile
modules that contain specs for functions of other modules - unless it
can somehow check that these functions are indeed defined, but it is
not how the compiler currently works.
Diffstat (limited to 'otp_patch_apply')
0 files changed, 0 insertions, 0 deletions