There are problems discovering where an error occurred.
Suppose in procedure P you call Q which calls R and there's an error.
If R gets called a lot, knowing the problem was detected in R doesn't help
locate that it was called by Q which was called by P, and the real problem
is in P near the called to Q.
In a live program, one uses a stack trace and a debugger to discover this,
or tracing prints, etc.
However this doesn't work if the functions are inlined. If that happens there
are two choices for the source references: ref to the function being inlined,
or, refer to the caller.
Neither of these options is any good. If you refer to the called functions you
end
up with an error detected in a two liner which is used extensively all over the
place: for the c pointer stuff that just means a "match failure" can be
understood
as a "null pointer dereference". Woop. Which pointer? Where did it come from?
If you refer to the caller .. well you get a reference to the root procedure,
which is the same everywhere so you have no information at all.
What we need is a call stack. My thought is to add annotations to functions
EXE_reference sr;
EXE_popref;
which is a no-op. When functions are inlined, we get a list of these:
EXE_reference P;
...
EXE_reference Q;
..
EXE_reference R;
.. <<< error>>>
EXE_pop; ...
When the compiler scans this is maintains a reference stack. When there's a
diagnostic,
such as assert or match failure, it links to the whole stack. So the diagnostic
printed
will consist of the call chain.
To make tghis work we need a new Ocaml src reference that handles a whole chain,
and an error diagnostic 'clierr chain "..."' which can use it to generate the
backtrace.
The main problem here is that every match failure or assert or whatever will
create an leaf
in a tree, and the tree will have to be emitted in the generated code.
The tree leaves are small (a bunch of integers) provided the filenames are
replaced by pointers to a table of filenames, however the textual representation
of all this in C++ will look very ugly .. it will have to go in a *.diagnostic
file
similar to the *.rtti file.
Note that currently there is a clierr2 which can report two locations.
That's probably enough .. .if only we could figure out which ones they actually
are :)
--
john skaller
skal...@users.sourceforge.net
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
