Started 1 mo 0 days ago
Took 1 hr 16 min on green-dragon-22

Failed Build rL:372447 - C:372444 - #702 (Sep 20, 2019 6:46:02 PM)

Revisions
  • http://llvm.org/svn/llvm-project/llvm/trunk : 372447
  • http://llvm.org/svn/llvm-project/cfe/trunk : 372444
  • http://llvm.org/svn/llvm-project/compiler-rt/trunk : 372348
  • http://llvm.org/svn/llvm-project/debuginfo-tests/trunk : 364589
  • http://llvm.org/svn/llvm-project/zorg/trunk : 372433
  • http://llvm.org/svn/llvm-project/libcxx/trunk : 372242
  • http://llvm.org/svn/llvm-project/clang-tools-extra/trunk : 372445
Changes
  1. Support for 64-bit PC-relative relocations for X86_64

    ELF files generated for X86_64 targets may contain 64-bit PC-relative
    relocations. For instance, an exception handler table entry contains the start
    of exception-throwing frame relative to the start of exception handler. As these
    two labels belong to different sections, their difference and so the relocation
    is 64-bit.

    An attempt to parse such file, i.e. in DWARFContext::create, results in "failed
    to compute relocation" error.

    This fix adds support for such relocations to RelocationResolver.cpp.

    Reviewed By: MaskRay

    Differential Revision: https://reviews.llvm.org/D67779

    Patch by Oleg Pliss (Oleg.Pliss@azul.com) (detail/ViewSVN)
    by apilipenko
  2. gn build: Merge r372445 (detail/ViewSVN)
    by gnsyncbot
  3. [clang-tidy] Add check for classes missing -hash ⚠️

    Summary:
    Apple documentation states that:
    "If two objects are equal, they must have the same hash value. This last
    point is particularly important if you define isEqual: in a subclass and
    intend to put instances of that subclass into a collection. Make sure
    you also define hash in your subclass."
    https://developer.apple.com/documentation/objectivec/1418956-nsobject/1418795-isequal?language=objc

    In many or all versions of libobjc, -[NSObject isEqual:] is a pointer
    equality check and -[NSObject hash] returns the messaged object's
    pointer. A relatively common form of developer error is for a developer to
    override -isEqual: in a subclass without overriding -hash to ensure that
    hashes are equal for objects that are equal.

    It is assumed that an override of -isEqual: is a strong signal for
    changing the object's equality operator to something other than pointer
    equality which implies that a missing override of -hash could result in
    distinct objects being equal but having distinct hashes because they are
    independent instances. This added check flags classes that override
    -isEqual: but inherit NSObject's implementation of -hash to warn of the
    potential for unexpected behavior.

    The proper implementation of -hash is the responsibility of the
    developer and the check will only verify that the developer made an
    effort to properly implement -hash. Developers can set up unit tests
    to verify that their implementation of -hash is appropriate.

    Test Notes:
    Ran check-clang-tools.

    Reviewers: aaron.ballman, benhamilton

    Reviewed By: aaron.ballman

    Subscribers: Eugene.Zelenko, mgorny, xazax.hun, cfe-commits

    Tags: #clang

    Differential Revision: https://reviews.llvm.org/D67737 (detail/ViewSVN)
    by stephanemoore

Started by an SCM change (3 times)

This run spent:

  • 19 min waiting;
  • 1 hr 16 min build duration;
  • 1 hr 35 min total from scheduled to completion.
LLVM/Clang Warnings: 2 warnings.
Test Result (1 failure / ±0)

Identified problems

Ninja target failed

Below is a link to the first failed ninja target.
Indication 1

Regression test failed

This build failed because a regression test in the test suite FAILed. See the test report for details.
Indication 2

Compile Error

This build failed because of a compile error. Below is a list of all errors in the build log:
Indication 3