<?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 TestBitfieldIvars.py</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>4cc8f2a0 - [lldb][tests] Automatically call compute_mydir (NFC)</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py#4cc8f2a0</link>
        <description>[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://reviews.llvm.org/D128077

            List of files:
            /llvm-project-15.0.7/lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py</description>
        <pubDate>Fri, 17 Jun 2022 00:38:47 +0000</pubDate>
        <dc:creator>Dave Lee &lt;davelee.com@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>dc057e87 - [LLDB] Fix how ObjCBOOLSummaryProvider deals with BOOL</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py#dc057e87</link>
        <description>[LLDB] Fix how ObjCBOOLSummaryProvider deals with BOOLObjCBOOLSummaryProvider was incorrectly treating BOOL as unsigned and this is now fixed.Also adding tests for one bit bit-fields of BOOL and unsigned char.

            List of files:
            /llvm-project-15.0.7/lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py</description>
        <pubDate>Fri, 22 Jan 2021 18:04:04 +0000</pubDate>
        <dc:creator>Shafik Yaghmour &lt;syaghmour@apple.com&gt;</dc:creator>
    </item>
<item>
        <title>a852cf66 - [lldb] [test] Skip ObjC-based tests via &apos;objc&apos; category</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py#a852cf66</link>
        <description>[lldb] [test] Skip ObjC-based tests via &apos;objc&apos; categoryReplace the plethora of ObjC-implied &apos;skipUnlessDarwin&apos; decoratorswith marking tests as &apos;objc&apos; category (whenever missing), and skip allObjC tests on non-Darwin platforms.  I have used &apos;.categories&apos; filewherever it was present already or all (&gt;1) tests were relying on ObjC,and explicit add_test_categories() where there was only one test.Differential Revision: https://reviews.llvm.org/D91056

            List of files:
            /llvm-project-15.0.7/lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py</description>
        <pubDate>Mon, 09 Nov 2020 09:47:22 +0000</pubDate>
        <dc:creator>Micha&#322; G&#243;rny &lt;mgorny@moritz.systems&gt;</dc:creator>
    </item>
<item>
        <title>0db2934b - [ASTImporter] Modify ImportDefiniton for ObjCInterfaceDecl so that we always the ImportDeclContext one we start the definition</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py#0db2934b</link>
        <description>[ASTImporter] Modify ImportDefiniton for ObjCInterfaceDecl so that we always the ImportDeclContext one we start the definitionOnce we start the definition of an ObjCInterfaceDecl we won&apos;t attempt to ImportDeclContextlater on. Unlike RecordDecl case which uses DefinitionCompleter to force completeDefinitionwe don&apos;t seem to have a similar mechanism for ObjCInterfaceDecl.This fix was needed due to a bug we see in LLDB expression parsing where an initial expressioncause an ObjCInterfaceDecl to be defined and subsequent expressions during import do not callImportDeclContext and we can end up in a situation where ivars are imported out of order and not all ivars are imported.Differential Revision: https://reviews.llvm.org/D83972

            List of files:
            /llvm-project-15.0.7/lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py</description>
        <pubDate>Fri, 24 Jul 2020 20:11:59 +0000</pubDate>
        <dc:creator>shafik &lt;syaghmour@apple.com&gt;</dc:creator>
    </item>
<item>
        <title>46334dfc - [lldb/test] Skip test in TestBitfieldIvars.py instead of xfailing it</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py#46334dfc</link>
        <description>[lldb/test] Skip test in TestBitfieldIvars.py instead of xfailing itThe test triggers an ASan exception, causing job failures on thesanitizer bot.As suggested by Shafik.

            List of files:
            /llvm-project-15.0.7/lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py</description>
        <pubDate>Tue, 21 Jul 2020 18:09:33 +0000</pubDate>
        <dc:creator>Vedant Kumar &lt;vsk@apple.com&gt;</dc:creator>
    </item>
<item>
        <title>a54c42df - Fix how we handle bit-fields for Objective-C when creating an AST</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py#a54c42df</link>
        <description>Fix how we handle bit-fields for Objective-C when creating an ASTCurrently expressions dealing with bit-fields in Objective-C objects is pretty broken. When generating debug-info for Objective-C bit-fields DW_AT_data_bit_offset has a different meaning than it does to C and C++.When we parse the DWARF we validate bit offsets for C and C++ correctly but not for ObjC. For ObjC in some cases we end up incorrectly flagging an error and we don&apos;t generate further bit-fields in the AST.Later on when we do a name lookup we don&apos;t find the ObjCIvarDecl in the ObjCInterfaceDecl in some cases since we never added it and then we don&apos;t go to the runtime to obtain the offset.This will fix how we handle bit-fields for the Objective-C case and add tests to verify this fix but also to documents areas that still don&apos;t work and will be addressed in follow-up PRs.Note: we can never correctly calculate offsets statically because of how Objective-C deals with the fragile base class issue. Which means the runtime may need to shift fields over.Differential Revision: https://reviews.llvm.org/D83433

            List of files:
            /llvm-project-15.0.7/lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py</description>
        <pubDate>Mon, 20 Jul 2020 23:09:18 +0000</pubDate>
        <dc:creator>shafik &lt;syaghmour@apple.com&gt;</dc:creator>
    </item>
<item>
        <title>99451b44 - [lldb][test] Remove symlink for API tests.</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py#99451b44</link>
        <description>[lldb][test] Remove symlink for API tests.Summary: Moves lldbsuite tests to lldb/test/API.This is a largely mechanical change, moved with the following steps:```rm lldb/test/API/testcasesmkdir -p lldb/test/API/{test_runner/test,tools/lldb-{server,vscode}}mv lldb/packages/Python/lldbsuite/test/test_runner/test lldb/test/API/test_runnerfor d in $(find lldb/packages/Python/lldbsuite/test/* -maxdepth 0 -type d | egrep -v &quot;make|plugins|test_runner|tools&quot;); do mv $d lldb/test/API; donefor d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-vscode -maxdepth 1 -mindepth 1 | grep -v &quot;.py&quot;); do mv $d lldb/test/API/tools/lldb-vscode; donefor d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-server -maxdepth 1 -mindepth 1 | egrep -v &quot;gdbremote_testcase.py|lldbgdbserverutils.py|socket_packet_pump.py&quot;); do mv $d lldb/test/API/tools/lldb-server; done```lldb/packages/Python/lldbsuite/__init__.py and lldb/test/API/lit.cfg.py were also updated with the new directory structure.Reviewers: labath, JDevlieghereTags: #lldbDifferential Revision: https://reviews.llvm.org/D71151

            List of files:
            /llvm-project-15.0.7/lldb/test/API/lang/objc/bitfield_ivars/TestBitfieldIvars.py</description>
        <pubDate>Tue, 11 Feb 2020 18:01:16 +0000</pubDate>
        <dc:creator>Jordan Rupprecht &lt;rupprecht@google.com&gt;</dc:creator>
    </item>
</channel>
</rss>
