!standard A.16(112/3) 11-12-30 AI12-0015-1/00 !standard A.17(23/3) !class Amendment 11-12-21 !status work item 11-12-21 !status received 11-10-13 !priority Low !difficulty Medium !subject Ada unit information !summary **TBD. !proposal There ought to be some standard way of retrieving compilation unit information. Discussion AI95-0282-1 suggests that the most appropriate way of doing this is with attributes of some sort. AI95-0282-1 was discussed at the February 2002 and October 2003 ARG meetings. Highlights of that discussion: The IBM/Rational compiler does not have line number information to report because of their incremental compilation technology; they use "source position" for debugging. It is suggested that the information be in terms of the enclosing call rather than the position of the attribute usage. A design similar to Exception_Information is suggested. Finally, the AI was killed because it was not deemed important enough. !wording ** TBD. !discussion ** TBD. !ACATS test ** TBD. !appendix From: Gregory D Moncreaff Sent: Thursday, October 13, 2011 6:59 PM Is there any standard way of retrieving compilation unit information via some mechanism in the Ada standard packages? In C/C++ compilers, there are common standard or vendor predefined macros: __FILE__, __LINE__ __function__ etc. It is often useful to have programs report (for developers) the package, routine, etc were something of interest occurred. With Ada, generics add complexity, as you often desire to know which instantiation of the generic encountered that interesting something. I noticed GNAT.Source_Information. Is there any likelihood that anything similar might become part of some future Ada standard? **************************************************************** From: Randy Brukardt Sent: Thursday, October 13, 2011 8:57 PM [BTW, what's the deal with the giant ugly green text?] > Is there any standard way of retrieving compilation unit information > via some mechanism in the Ada standard packages? No. This was discussed in the past, the context of Ada 2005, and it was rejected for reasons that I no longer remember. This was recorded in AI95-00282-1 (look it up on the Ada-auth.org site, and if you want more information, I'd suggest looking in the meeting minutes for that AI number). I vaguely remember difficulties defining precisely what the functions are expected to return, in cases like inlining and generic instantiation, because different implementations do these things differently. If we just allowed implementations to do what they want in those cases, any such information would be much less useful. (Imagine not knowing whether you would get information from a generic body or an instance of that body -- very different things.) Anyway, I think we would need to see stronger use-cases than just "some other language provides X", especially as we've already considered this once unsuccessfully. (Whether we'd reconsider also would depend on whether there were genuine technical difficulties with the old proposal or it was judged not important enough.) ****************************************************************