<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in designated-initializers-base-class.cpp</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>5030928d - [c++20] Implement semantic restrictions for C++20 designated</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/SemaCXX/designated-initializers-base-class.cpp#5030928d</link>
        <description>[c++20] Implement semantic restrictions for C++20 designatedinitializers.This has some interesting interactions with our existing extensions tosupport C99 designated initializers as an extension in C++. Those areresolved as follows: * We continue to permit the full breadth of C99 designated initializers   in C++, with the exception that we disallow a partial overwrite of an   initializer with a non-trivially-destructible type. (Full overwrite   is OK, because we won&apos;t run the first initializer at all.) * The C99 extensions are disallowed in SFINAE contexts and during   overload resolution, where they could change the meaning of valid   programs. * C++20 disallows reordering of initializers. We only check for that for   the simple cases that the C++20 rules permit (designators of the form   &apos;.field_name =&apos; and continue to allow reordering in other cases).   It would be nice to improve this behavior in future. * All C99 designated initializer extensions produce a warning by   default in C++20 mode. People are going to learn the C++ rules based   on what Clang diagnoses, so it&apos;s important we diagnose these properly   by default. * In C++ &lt;= 17, we apply the C++20 rules rather than the C99 rules, and   so still diagnose C99 extensions as described above. We continue to   accept designated C++20-compatible initializers in C++ &lt;= 17 silently   by default (but naturally still reject under -pedantic-errors).This is not a complete implementation of P0329R4. In particular, thatpaper introduces new non-C99-compatible syntax { .field { init } }, andwe do not support that yet.This is based on a previous patch by Don Hinton, though I&apos;ve madesubstantial changes when addressing the above interactions.Differential Revision: https://reviews.llvm.org/D59754llvm-svn: 370544

            List of files:
            /llvm-project-15.0.7/clang/test/SemaCXX/designated-initializers-base-class.cpp</description>
        <pubDate>Fri, 30 Aug 2019 22:52:55 +0000</pubDate>
        <dc:creator>Richard Smith &lt;richard-llvm@metafoo.co.uk&gt;</dc:creator>
    </item>
<item>
        <title>8eccb9bb - [Sema] Fix bug in handling of designated initializer.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/SemaCXX/designated-initializers-base-class.cpp#8eccb9bb</link>
        <description>[Sema] Fix bug in handling of designated initializer.CheckDesignatedInitializer wasn&apos;t taking into account the base classeswhen computing the index for the field in the derived class, whichcaused the test case to crash during IRGen because of a malformed AST.rdar://problem/26795040Differential Revision: https://reviews.llvm.org/D28705llvm-svn: 292245

            List of files:
            /llvm-project-15.0.7/clang/test/SemaCXX/designated-initializers-base-class.cpp</description>
        <pubDate>Tue, 17 Jan 2017 19:35:54 +0000</pubDate>
        <dc:creator>Akira Hatanaka &lt;ahatanaka@apple.com&gt;</dc:creator>
    </item>
</channel>
</rss>
