- User Since
- Jul 12 2012, 2:19 PM (253 w, 5 d)
I like it, and it seems like it would nicely generalize if there are more cases that we find need this treatment.
Mon, May 22
Counterproposal: in -std=*++14 onwards, treat this construct as a user-defined literal, but fall back on the built-in interpretation if name lookup doesn't find an operator""i function. (The two interpretations only conflict if the source code explicitly does something like using namespace std::complex_literals;, which seems like a pretty big clue that the user expected 1.0ito be std::complex<double> rather than _Complex double.)
Do we really need two different notions of "definition" and "odr definition" here? What goes wrong if we always treat the "instantiation of a friend function definition" case as being a definition?
Does it still make sense for us to have a UO_Coawait at all? As I recall, the only purpose it ever had was to represent a dependent co_await expression that couldn't yet be resolved to a CoawaitExpr. But now we have (and need!) a separate DependentCoawaitExpr node to store unqualified lookup results, it seems that the UnaryOperator portion of the representation serves no purpose (and as seen in this patch, it's getting in the way). Can we remove it?
Fri, May 19
This is supposed to be handled by Sema::DeclareGlobalAllocationFunction:
So, on the whole, the stray ellipsis treatment is both too complicated and not complicated enough.
Thu, May 18
Should I assume our "misplaced ellipsis" diagnostic requires that we disambiguate the ill-formed ellipsis-after-declarator-id as a declaration in some cases? If so, do we have tests for that somewhere?
Some comments, but I'm happy for you to go ahead and commit after addressing them. Thanks!
Wed, May 17
Tue, May 16
Mon, May 15
Fri, May 12
Thu, May 11
Clang's regression test suite is not a sensible home for these tests. We should have a home and a plan for system-specific integration tests, but this is not it. Perhaps this should instead be a part of LNT / the test-suite project?
Wed, May 10
I'd like to suggest an alternative design: don't add a new attribute., and instead change the semantics of __attribute__((overloadable)) to permit at most one non-overloadable function in an overload set. That one function would implicitly get the transparently_overloadable semantics: it can be overloaded by overloadable functions and doesn't get a mangled name. This is basically exactly how extern "C" and extern "C++" functions overload in C++: you can have up to one extern "C" function plus as many (overloadable) C++ functions as you like.
Tue, May 9
Er, please ignore the inline review comments; those predated the realisation that this doesn't actually fix the glibc build problem.
Thank you, some of these test typos are ... alarming. =)
Please first check in a change that just regenerates cxx_dr_status without your changes, to separate out the changes due to the new issues list from the changes due to this patch. (You can go ahead and do that with no review.)
This makes a lot of sense to me. See also r302463: I think we probably want three levels of shadowing here: the main input shadows -fmodule-map-file, which shadows module maps loaded implicitly. (There's also a question of what we do with module map information loaded from an AST file: currently when that happens, we ignore the tokens for the parsed module map entirely. It might make more sense to have the module loaded from the AST file shadow the module from the module map, especially for an explicit module build, now that we have that functionality.)
Let's go ahead with this. I've been unable to find a testcase that triggers the problem, but we shouldn't keep a known latent bug around just because we don't know how to expose it yet.
Mon, May 8
Fri, May 5
Wed, May 3
Tue, May 2
Mon, May 1
Committed as r301822.
Sun, Apr 30
Thanks. Could you also add something like:
Fri, Apr 28
Thanks, this looks good, just a couple of minor things and then it should be ready to land.
Yes, let's first revert back to the clang 4.0 behavior, then please mail cfe-dev to discuss what the right behavior should be.
Thu, Apr 27
I'm OK with this from a mechanical perspective. But there's also a libclang design question here: what should the libclang methods to query template arguments for a type cursor representing an alias template specialization actually do? Should there be some way for a libclang user to choose what result they get?
Wed, Apr 26
If we're now catching integer overflow in more cases, please add some relevant testcases. If this is a pure refactoring that enables those additional diagnostics to be produced in future, then this is fine as-is. (For the benefit of other people looking at this, the test changes here are caused by a pre-existing bug: the notes for why a reference is not usable in a constant expression are only produced if we happen to produce diagnostics the first time we try to evaluate them.)
This change looks like it introduces a regression itself: given
The change in direction from diagnosing the lvalue-to-rvalue conversion to diagnosing the pointer arithmetic seems fine to me (and is likely a better approach overall), but this means we should now treat a designator referring to element 0 of an array of unknown / runtime bound as being valid. We have minimal support for this already for __builtin_object_size evaluation, which you should be able to generalize to support arbitrary designators ending with such a value.