This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++ Patch] PR 44516


Hi again,

> In any case, the general rule should be that input_location (or
> variants using that) should be only used in the parser (who actually
> knows what input_location is pointing at). Other functions should use
> a location coming from somewhere else (an argument or a tree).
> UNKNOWN_LOCATION should be used for anything that is
> artificial/compiler-generated.

Thus, in short, I understand that what I'm trying to do with my patch using LOC_OR_HERE follows the practice, right? Currently we happily call from the build_x_* functions the build_min_nt function which doesn't set a location for the new node. But it's compiler generated stuff. Definitely we are not regressing on this. Otherwise the build_x_* functions may call build_new_op and the like, which may immediately emit errors and I'm proposing to use LOC_OR_HERE for those, thus we are never going to pass down an UNKNOWN_LOCATION. Honestly, from the point of view of your considerations, I don't see how my patch could cause regressions.

Paolo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]