Richard Smith 77e9e84a8e Don't mark a member as a member specialization until we know we're keeping the specialization. ... This improves our behavior in a few ways: * We now guarantee that if a member is marked as being a member specialization, there will actually be a member specialization declaration somewhere on its redeclaration chain. This fixes a crash in modules builds where we would try to check that there was a visible declaration of the member specialization and be surprised to not find any declaration of it at all. * We don't set the source location of the in-class declaration of the member specialization to the out-of-line declaration's location until we have actually finished merging them. This fixes some very silly looking diagnostics, where we'd point a "previous declaration is here" note at the same declaration we're complaining about. Ideally we wouldn't mess with the prior declaration's location at all, but too much code assumes that the first declaration of an entity is a reasonable thing to use as an indication of where it was declared, and that's not really true for a member specialization unless we fake it like this. llvm-svn: 302596		2017-05-09 23:02:10 +00:00
..
clang	Don't mark a member as a member specialization until we know we're keeping the specialization.	2017-05-09 23:02:10 +00:00
clang-c	[libclang] Expose some target information via the C API.	2017-04-28 15:56:39 +00:00
CMakeLists.txt	…