On Jan 22, 2017, Alexandre Oliva <aol...@redhat.com> wrote: > On Jan 13, 2017, Jason Merrill <ja...@redhat.com> wrote: >> On 09/23/2016 08:41 PM, Alexandre Oliva wrote: >>> +/* Create a modified version of a function type that has default >>> + values for some of its arguments. The returned type should ONLY be >>> + used to define functions or methods, never to declare parameters, >>> + variables, types or the like.
>> Handling these in the function type seems like an artifact of the GCC >> implementation of default arguments that needn't be exposed to GDB, >> particularly since you already also offer >> set_deferred_function_default_args to apply them to the decl directly. > Will do. set_deferred_function_default_args was a late addition, when I > realized some cases required it, and I was undecided between keeping the > machinery that had been introduced before or removing it. So removing > it is ;-) Houston, we have a problem, it seems to me. The reason the present arrangement seemed to work nicely was that add_function_default_args would create a type variant, and set_deferred_function_default_args would merely adjust pre-reserved parts of the argument list of that previously-created variant. This gave e.g. ctor clones with default args the same type sharing under libcc1 that they'd get under normal compilation. However, if we were to remove these two entry points in favor of one that modified a function decl in place, we'd have to somehow reintroduce the sharing after creating the type variants, or hope the sharing doesn't matter. The latter isn't appealing, whereas the former would require either an additional entry point (or additional smarts in the replacement entry point) for functions with e.g. the same original type and default arg list to get the same modified type. Now, if ctor cloning is the only situation in which this might arise (can you think of any other?), we stand a chance of dealing with it ourselves, saving the client from this burden, but I'm not sure how we'd deal with cases in which default arg exprs contain references to args or to the function proper that would require remapping of the cloned args. The one case that comes to mind is that of a lambda whose context is a parm of the original function, but that should remain pointing to the original parm even in the clones. But then, if there are cases in which different clones of a ctor need to have different exprs for default args, even the current API won't do, because (I think) the ctor clones all share the same type (and thus default arg list), so if the client were to attempt to set the deferred args for each clone, only the first would succeed. I believe the language does not allow such references in default args, so this shouldn't arise. Yuck. Now, it might be that default args don't even have to be in ctor clones, since the clones won't be used for overload resolution, they'll only be selected once we determine which ctor we want to call. So, in the end, maybe none of this concern of mine matters and, Houston, maybe we don't have a problem after all. Thoughts? Another possibility of type sharing that I'm concerned about is when a function template has (non-template) default args. If the type without default args is copied/derived-from before the libcc1 user gets a chance to add default args to it, we'd have inconsistencies in the libcc1 decls not present in the original decls. I could investigate this risk myself but, not being so familiar with the FE and in the interest of time, I ask: do you see reason for concern there? Of course one way out of this would be to introduce default arguments at the point of declaration of a function, so that the type variant could be constructed before the function declaration and everything would follow its normal course (with the caveat the some default args might have to be deferred just like in the current interface), but... we already have too many arguments for new_decl. It wouldn't be too hard to extend the RPC machinery in libcc1 to support one more, but I'm hesitant to add one more argument to it, or to introduce an alternate entry point to introduce functions with one extra argument (all the other new_decl args would still be needed). At this point, considering that: - default args are not even present in debug info (so this functionality is unused), and - it's not at all certain that either the current API or the alternate proposal are enough to represent all the richness of different sets of default args for the same function in different scopes, or even within the same scope, and that we don't know what if any of this flexibility will ever make to debug info, I must point out the possibility that we drop support for non-template default args entirely for now, and revisit these concerns when the interfaces stand at least a chance of being used. Thanks in advance for your insights, -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
