Intrinsics to return information on procedure name, source file name and line number

[sblionel]

Many times in my career I saw users asking for a way to obtain the current procedure name, source file name and/or source file line number, for use in logging and error messages. Some compilers offer preprocessor macros for this, but it is not standardized and macros that result in a string are hard to use in Fortran.

Intrinsic module ISO_FORTRAN_ENV already has two intrinsic functions COMPILER_OPTIONS and COMPILER_VERSION that return strings known to the compiler. I propose adding three more - the names I show here are for discussion purposes and different names might be desirable.

PROCEDURE_NAME() returns a string that is the function-name or subroutine-name of the enclosing function or subroutine, upcased. (Case as it appears in the source file would be another choice.) A constraint would be that this can appear only in a subroutine or function. (If the procedure is in a module, does the module name also appear somehow? I think not.)

SOURCE_FILE_NAME() returns an implementation-dependent string that represents the name of the source file in which the call appears. This can get tricky - full path? What about sources that have no name or include files?

SOURCE_LINE_NUMBER() returns an integer representing the line number of the source file in which the call appears. Is it OK if it's just relative to the actual file (could be an include file)? Interaction with preprocessors (they have pragmas that can set the original line number.)

All of these would be valid in constant expressions.

[cmacmackin]

Taking this a step further, we could also consider a functions which would return this sort of information for the entire callstack. Obviously that would not be safe to use in a constant expression. Many of the same questions apply, of course. Presumably the easiest thing to do would be return mangled procedure names generated during compilation, although I wouldn't imagine it would be too difficult to have an option for the compiler unmangle them. Personally, I'd like it if there were a way to see module names as part of the procedure name (e.g., MODULE_NAME[::SUBMODULE_NAME]::PROCEDURE_NAME).

[FortranFan]

I think this will be very useful for Fortran practitioners.

As I inquired in the comp.lang.fortran thread where too this was mentioned, what technical concerns and possible objections can compiler writers and commercial vendors have with this?

In other words, in what way can this not be a no-brainer i.e., a just do it item?

[jvdp1]

These would be very useful. I often use the macros FILE and LINE (with preprocessor) to get these info.

[certik]

I think these would be useful, thank you for proposing this @sblionel.

One objection from the committee that I can see coming is that the standard tries to describe Fortran in a way that is independent of the filesystem and filenames. I personally do not think that should be a problem, but it is one objection that might be raised against the SOURCE_FILE_NAME function.

[sblionel]

I would not be in favor of extending this to a run-time stack trace. Generally, procedure names are not kept around after compilation, and some implementations may not have a way of retrieving names of callers.

I can't think of any technical objection as this information is always available in the compilation phase where these would be processed. It would not require implementors to keep anything additional.

@certik , this could be handled similarly to INCLUDE - there would be something like "a processor-dependent string that represents the origin of the source text". The wording for INCLUDE has "An example of a possible valid interpretation is that char-literal-constant is the name of a file that contains the source text to be included." You're right that this needs to be carefully worded as to not imply a particular implementation. Indeed, some sources come from stdin or pipes. Maybe SOURCE_NAME would be a better choice. Certainly, a topic for discussion.

[ashe2]

I think this will be very useful for Fortran practitioners.

As I inquired in the comp.lang.fortran thread where too this was mentioned, what technical concerns and possible objections can compiler writers and commercial vendors have with this?

In other words, in what way can this not be a no-brainer i.e., a just do it item?

The best way to show this is a no-brainer would be for someone to implement it in one of the open source compilers. Assuming that shows it is well-defined, straight-forward to implement, and useful, that would encourage the committee to standardize it and other implementors to implement it.

[certik]

@valtteriB I agree and it is going to happen soon. I think @klausler and others might be very close to start implementing such prototypes in Flang, and we need few more months with LFortran to be able to do that also.

[klausler]

We already have __FILE__ and __LINE__ in the preprocessors available in all serious compilers.

[sblionel]

As @klausler says, compilers already know how to do this from preprocessor macros. I don't think implementors need to be convinced that it's doable. Truly, the hard part is getting the words right in the standard. Some work is needed in a compiler to recognize an intrinsic module function as valid in a constant expression, but there is already precedent for that and compilers have their own ways of handling it.

[klausler]

But people can use __FILE__ and __LINE__ today. What's the ROI on defining new intrinsic functions in the 202Y standard, implementing and testing them in multiple compilers, and shaking out the bugs and incompatibilities, just to get the same facilities with a different redundant spelling to users sometime in the 2030s? Everyone would be better off if you just blessed the existing common preprocessor features already in use today.

[sblionel]

They're not standard and some compilers don't support preprocessor macros by default.

This proposal was triggered by a request on c.l.f for a way to retrieve the current procedure name - I threw in source file and line number as obvious parallels that were requests I had seen before. Also note my comment about how hard it is to use string macros as character literals.

[klausler]

What's the problem with using __FILE__ as a character literal?

[septcolor]

I think another point is that the value of __FILE__ and __LINE__ found in some output file may not be "in sync" with the current source codes. Although the same can be true for procedure names (i.e., new source codes may have different routine names), it is still much more informative to have procedure names rather than line numbers (which can even vary depending on newly added comments etc).

[tskeith]

I think the value of something like PROCEDURE_NAME() is limited if you can't uniquely identify the subprogram with it. That means you need some kind of fully-qualified name (at least optionally), or a way to get the names of the enclosing module, submodule, and host subprogram (if any).