Skip to content
Permalink
Branch: master
Commits on Mar 22, 2019
  1. Merge pull request #23471 from compnerd/shell-is-not-parseable

    compnerd committed Mar 22, 2019
    test: make more of the ParseableInterface tests pass on Windows
  2. Merge pull request #23477 from nkcsgexi/opts-swift-api-checker

    nkcsgexi committed Mar 22, 2019
    swift-api-checker: allow the script to take additional flags to pass down to the executable
  3. Merge pull request #23476 from shajrawi/no_tail

    shajrawi committed Mar 22, 2019
    ARCEntryPointBuilder: Don't mark the call instructions as tail-calls
  4. linting

    nkcsgexi committed Mar 22, 2019
  5. Merge pull request #23474 from jrose-apple/export-au-prince

    jrose-apple committed Mar 22, 2019
    [ParseableInterface] Honor "exported module names"
  6. swift-api-checker: allow the script to take additional flags to pass …

    nkcsgexi committed Mar 22, 2019
    …down to the executable
  7. Merge pull request #23433 from Catfish-Man/measure-a-bridge-and-get-o…

    Catfish-Man committed Mar 22, 2019
    …ver-it
    
    Add new benchmarks for NSString bridging to cover non-tagged cases
Commits on Mar 21, 2019
  1. ARCEntryPointBuilder: Don't mark the call instructions as tail-calls

    shajrawi committed Mar 21, 2019
    rdar://problem/48833545
    
    From the LLVM Manual regarding tail/musttail : "Both markers imply that the callee does not access allocas from the caller”
    
    Swift’s LLVMARCContract just marks all the calls it creates as tail call without any analysis and/or checking if we are allowed to do that. This created an interesting runtime crash that was a pain to debug - story time:
    
    I traced a runtime crash back to Swift’s LLVMARCContract, but could not grok why the transformation there is wrong: we replaced two consecutive _swift_bridgeObjectRelease(x) calls with _swift_bridgeObjectRelease_n(x, 2), which is a perfectly valid thing to do.
    
    I noticed that the new call is marked as a tail call, disabling that portion of the pass “solved” the runtime crash, but I wanted to understand *why*:
    
    This code worked:
    	pushq	$2
    	popq	%rsi
    	movq	-168(%rbp), %rdi
    	callq	_swift_bridgeObjectRelease_n
    	leaq	-40(%rbp), %rsp
    	popq	%rbx
    	popq	%r12
    	popq	%r13
    	popq	%r14
    	popq	%r15
    	popq	%rbp
    	retq
    
    While this version crashed further on during the run:
    	movq	-168(%rbp), %rdi
    	leaq	-40(%rbp), %rsp
    	popq	%rbx
    	popq	%r12
    	popq	%r13
    	popq	%r14
    	popq	%r15
    	popq	%rbp
    	jmp	_swift_bridgeObjectRelease_n
    
    As you can see, the call is the last thing we do before returning, so nothing appeared out of the ordinary at first…
    
    Dumping the heap object at the release basic block looked perfectly fine: the ref count was 2 and all the fields looked valid.
    
    However, when we reached the callee the value was modified / dumping it showed it changed somewhere. Which did not make any sense.
    
    Setting up a memory watchpoint on the heap object and/or its reference count did not get us anywhere: the watchpoint triggered on unrelated code in the entry to the callee..
    
    I then realized what’s going on, here’s a an amusing reproducer that you can checkout in LLDB:
    Experiment 1:
    Setup a breakpoint at leaq	-40(%rbp), %rsp
    Dump the heap object - it looks good
    Experiment 2:
    Rerun the same test with a small modification:
    Setup a breakpoint at popq	%rbx (the instruction after leaq, do not set a breakpoint at leaq)
    Dump the heap object - it looks bad!
    
    So what is going on there? The SIL Optimizer changed an alloc_ref instruction into an alloc_ref [stack], which is a perfectly valid thing to do.
    
    However, this means we allocated the heap object on the stack, and then tail-called into the swift runtime with said object. After having modified the stack pointer in the caller’s epilogue.
    
    So why does experiment 2 show garbage? We’ve updated the stack pointer, and it just so happens that we are after the red zone on the stack. When the breakpoint is hit (the OS passes control back to LLDB), it is perfectly allowed to use the memory where the heap object used to reside.
    
    Note: I then realized something even more concerning, that we were lucky not have hit so far: not only did we not check if we are allowed to mark a call as ’tail’ in this situation, which could have been considered a corner case,  we could have if we have not promoted it from heap to stack, but we marked *ALL* the call instructions created in this pass as tail call even if they are not the last thing that occurred in the calling function! Looking at the LVMPasses/contract.ll test case, which is modified in this PR, we see some scary checks that are just wrong: we are checking if a call is marked as ‘tail’ in the middle of the function, then check the rest of the function in CHECK-NEXT lines. Knowing full well that the new ‘tail call’ is not the last thing that should execute in the caller.
  2. Merge pull request #19503 from drodriguez/android-aarch64-test-script

    compnerd committed Mar 21, 2019
    [android] Modify test scripts for aarch64 and modern NDKs.
  3. Merge pull request #23448 from nathawes/fix-case-var-for-relatedident…

    gottesmm committed Mar 21, 2019
    …s-cursorinfo-and-rename
    
    [sourcekitd] Improve CursorInfo, RelatedIdents, and local rename to better handle VarDecls involved in case fallthroughs
  4. [ParseableInterface] Honor "exported module names"

    jrose-apple committed Mar 21, 2019
    (as described in the previous commit)
    
    When printing an interface that has to be stable, we need to use the
    module name that identifies where declarations should be searched for,
    just like we do with serialization.
    
    rdar://problem/49114811
  5. Push Clang's "exported module name" notion up to Swift's FileUnit

    jrose-apple committed Mar 21, 2019
    It's a pretty obscure feature (and one we wish we didn't need), but
    sometimes API is initially exposed through one module in order to
    build another one, and we want the canonical presented name to be
    something else. Push this concept into Swift's AST properly so that
    other parts of the compiler stop having to know that this is a
    Clang-specific special case.
    
    No functionality change in this commit; will be used in the next
    commit.
  6. [ClangImporter] Avoid unneeded copy for getExportedModuleName

    jrose-apple committed Mar 21, 2019
    std::string -> StringRef of long-lived backing storage.
    
    No functionality change.
  7. Fix a comment in AccessEnforcementOpts.

    atrick committed Mar 21, 2019
    This was supposed to land in the previous commit but was dropped.
  8. test: make more of the ParseableInterface tests pass on Windows

    compnerd committed Mar 21, 2019
    Rewrite the shell to be more clever so it is amenable to porting to
    Windows.  Use env not rather than not env to permit the lit environment
    handling to take over for Windows.
  9. Merge pull request #22208 from linux-on-ibm-z/s390x-storetag-fix

    compnerd committed Mar 21, 2019
    Fix storeEnumTagSinglePayload on big-endian systems
  10. Merge pull request #23464 from dcci/rdar49043621

    dcci committed Mar 21, 2019
    [Reflection] Add an utility to stress test the metadata reader.
  11. [semantic-arc-opts] Teach the guaranteed copy_value peephole how to h…

    gottesmm committed Mar 21, 2019
    …andle instructions that can forward either owned or guaranteed ownership.
    
    This fixes issues exposed by my turning off the Nominal Type RValue peephole. It
    should give us some nice ARC wins as well potentially.
  12. Merge pull request #23455 from apple/build-compile_rt-with-libdispatc…

    yln committed Mar 21, 2019
    …h-support
    
    Build compiler-rt with TSan interception for libdispatch on non-Apple platforms
  13. test: improve test coverage rate for Windows

    compnerd committed Mar 21, 2019
    Strip the use of `env` on Windows which will swallow the error code if
    the GnuWin32 version (which is recommended/used by LLVM) is used.  Since
    SDKROOT should not be set on Windows anyways, this should not matter
    much in practice but will help improve the test coverage on Windows.
    
    Additionally, remove the path lowercasing on Windows as the path is kept
    in the proper case, even on the nightlies.  This should help improve the
    number of Driver tests that pass.
    
    With this change, I now can get all the Driver tests to pass locally.
  14. [test] Fix FixedPointConversion tests (#23220)

    2 people authored and stephentyrone committed Mar 21, 2019
    Fix several problems with FixedPointConversion generation code.
    
    The first problem is that at some point `repr(value)` was being used,
    which turn the number into a string. That was great for printing the
    number, but make the test against the value of the number (like
    `testValue < otherMin` always false. There were a number of tests that
    were never performed, specifically the integer tests.
    
    The second problem was using doubles in the Python code. For Float32 and
    Float64 the tests were generated correctly, but in the case of Float80,
    the test adding or removing a quantity to the maximum/minimum were
    failing because of the lack of precission (Adding 0.1 to a very
    big/small number is the same as not adding anything). Switching to
    Decimal should keep enough precission for the tests.
    
    Finally the last problem was that the bounds of the conversions are not
    actually `selfMin` and `selfMax`, but the values returned by the utility
    function `getFtoIBounds`. For example for unsigned types, the lower
    bound is always -1, not zero (every value between -1 and zero is rounded
    to zero, and doesn't fail).
    
    Instead of using nested gyb templates, use lit.cfg %target-ptrsize,
    which should be faster, cleaner, and provides correct line-directive
    output.
    
    Remove a bunch of warnings in Swift when compiling the generated result
    of FixedPointConversion.swift.gyb.
    
    Co-authored-by: Gwynne Raskind <gwynne@users.noreply.github.com>
  15. [Reflection] Add an utility to stress test the metadata reader.

    dcci committed Mar 21, 2019
    lldb now uses this quite extensively so we want to make sure
    we don't crash on invalid.
    
    <rdar://problem/49043621>
  16. Merge pull request #23400 from drodriguez/remove-incorrect-docs

    compnerd committed Mar 21, 2019
    [stdlib] Remove documentation piece that it is not longer true.
  17. Merge pull request #23442 from linux-on-ibm-z/s390x-enum-fixes

    jckarter committed Mar 21, 2019
    IRGen: simplify getSpareBitsForType
  18. Merge pull request #23458 from slavapestov/tuple-conversions-part-1

    slavapestov committed Mar 21, 2019
    Split off ArgumentShuffleExpr from TupleShuffleExpr
  19. Merge pull request #23429 from aschwaighofer/fix_enable_private_impor…

    aschwaighofer committed Mar 21, 2019
    …t_get_effective_access_level_symbolic_references_property_desc
    
    Property descriptor and symbolic type references need to ignore enable-private-import
  20. AST: Remove argument list-specific parts of TupleShuffleExpr

    slavapestov committed Mar 21, 2019
    Before extending TupleShuffleExpr to represent all tuple
    conversions allowed by the constraint solver, remove the
    parts of TupleShuffleExpr that are no longer needed; this is
    support for default arguments, varargs, and scalar-to-tuple and
    tuple-to-scalar conversions.
  21. AST: Split off ArgumentShuffleExpr from TupleShuffleExpr

    slavapestov committed Mar 21, 2019
    Right now we use TupleShuffleExpr for two completely different things:
    
    - Tuple conversions, where elements can be re-ordered and labels can be
      introduced/eliminated
    - Complex argument lists, involving default arguments or varargs
    
    The first case does not allow default arguments or varargs, and the
    second case does not allow re-ordering or introduction/elimination
    of labels. Furthermore, the first case has a representation limitation
    that prevents us from expressing tuple conversions that change the
    type of tuple elements.
    
    For all these reasons, it is better if we use two separate Expr kinds
    for these purposes. For now, just make an identical copy of
    TupleShuffleExpr and call it ArgumentShuffleExpr. In CSApply, use
    ArgumentShuffleExpr when forming the arguments to a call, and keep
    using TupleShuffleExpr for tuple conversions. Each usage of
    TupleShuffleExpr has been audited to see if it should instead look at
    ArgumentShuffleExpr.
    
    In sequent commits I plan on redesigning TupleShuffleExpr to correctly
    represent all tuple conversions without any unnecessary baggage.
    
    Longer term, we actually want to change the representation of CallExpr
    to directly store an argument list; then instead of a single child
    expression that must be a ParenExpr, TupleExpr or ArgumentShuffleExpr,
    all CallExprs will have a uniform representation and ArgumentShuffleExpr
    will go away altogether. This should reduce memory usage and radically
    simplify parts of SILGen.
  22. Merge pull request #23311 from theblixguy/fix/throw-in-defer

    xedin committed Mar 21, 2019
    [Diag] [Typechecker] Diagnose throw in defer properly
  23. Merge pull request #23450 from harlanhaskins/can-can-you-do-the-import

    harlanhaskins committed Mar 21, 2019
    [ParseableInterface] Add test for #if canImport
  24. Build compile-rt with libdispatch interception to support TSan on Linux

    yln committed Mar 21, 2019
    I recently enabled TSan interceptors for libdispatch on non-Apple
    platforms in upstream. This is on by default on Apple platforms. Let's
    try to switch it on for other platforms too.
Older
You can’t perform that action at this time.