On 2/1/20 6:55 AM, Iain Sandoe wrote:
Nathan Sidwell <nat...@acm.org> wrote:
On 1/30/20 9:43 AM, Iain Sandoe wrote:
Hi Nathan,
however. ….
also, what if you find something, but it's not a type template?
… I’ve switched the complain off on lookup_qualified_name and now check for
a type template.
I'm not sure that's helpful. I think you should still complain on the lookup.
If that returns error_mark_node, you're done. If it returns NULL, does it emit
an error? If not, you should emit a not found error. Finally, if it does
return a thing, check if it's a class template decl (or alias template I guess
-- DECL_TEMPLATE_RESULT being a TYPE_DECL is close enough) and if not, error
on that (X is not a template class). Then the user's fully clued in.
I took the liberty of repeating this treatment in the coroutine handle lookup
code
(new testcases attached).
so the errors now look like:
"cannot find a valid coroutine traits template using 'std::coroutine_traits’”
hm, 'valid'. If you find a template_decl, but cannot instantiate it, that
sounds not valid. But I suspect you do not diagnose that here, because in
general you cannot :)
OK. So in my mind there are two cases here:
1. The user doesn’t know to, or forgot to, add <coroutine> (or can’t spell it).
- this would trigger the top level error and mean that nothing much is going to
work.
2.
2a The user has a corrupted installation and the <coroutine> header is broken.
2b The user has been more creative and tried to invent their own header.
- this might result in many more unexpected pathways leading to error.
———
I have revised the code to:
a) re-enable “complain” on the lookup_qualified_name (providing no error for
missing traits has been emitted).
b) I added an inform “perhaps '#include <coroutine>' is missing (I couldn’t get
the rich location missing include logic to fire here).
c) the diagnostic now will consist of:
- any emitted by “lookup_qualified_name()" (usually, there will be none,
since we are supplying std namespace as the scope).
- "coroutines require a traits template; cannot find
‘std::coroutine_traits’”
- "note: perhaps ‘#include <coroutine>’ is missing”
I think that deals reasonably with the common case (1) without being too
annoying in terms of diagnostic verbosity.
it leaves “lookup_qualified_name()" reported errors to deal with the less
common and more exotic possibilities in (2).
The handle is treated the same way (without the <coroutine> note, since we must
have already found or made a usable traits). In any case, I think bad handle fails
only really occur under (2) above.
still open to rewording of error messages, of course,
OK / reword?
thanks, looks good now.
nathan
--
Nathan Sidwell
