This should curtail merge conflicts in the future

…wiftlang#26887)

VBR fields can store up to 64 bits of info in N-bit units, where the
top bit describes whether there are further units to come. See
http://llvm.org/docs/BitCodeFormat.html for more information. In the
cases of the fields changed here, these are all usually-small values
that can /occasionally/ get a lot larger; a VBR field allows us to
pick a reasonable default while still not setting a maximum.

Swiftmodule size micro-optimization. No functionality change; due to
LLVM bitstream being a self-describing container format, this does not
actually break compatibility.

…ip the switch to enable this on the tests/rest of the world.

…s vector views (swiftlang#26890)

[TF-785](https://bugs.swift.org/browse/TF-785)

…_borrow, load_borrow where all users can accept a guaranteed parameter.

I previously implemented this only for functions so I didn't need to use the
linear lifetime checker to determine if all destroys where within the lifetime
of the borrowed value. That was just to be incremental. In this commit, I
unleash the whole optimization.

swiftlang#26893)

Follow-up for 3596df7.

… prefer to loading via interfaces

ABI checker imports Swift frameworks by using Swift interfaces for various
reasons. The existing way of controlling preferred importing mechanism is by
setting an environment variable (SWIFT_FORCE_MODULE_LOADING), which may lead
to performance issues because the stdlib could also be loaded in this way.

This patch adds a new front-end option to specify module names for
which we prefer to importing via Swift interface. The option currently is only
accessible via swift-api-digester.

rdar://54559888

[Request Evaluator] Begin Formalizing Zones

…ac23243588bb03b3f435c62

…nterface-for-module

Frontend: add a front-end option to specify module names for which we prefer loading via interfaces

…d2fc16ee80001e7a767ab77

[ownership] Enable ownership lowering on overlays. I still need to fl…

…s crasher. (swiftlang#26900)

Resolves [TF-783](https://bugs.swift.org/browse/TF-783).

…alue

[ConstraintSystem] Be more principled about recording r-value -> l-value fix

tensorflow/swift-apis@74a9bd2

…` types

If there is an argument-to-parameter conversion which is associated with
`inout` parameter, subtyping is now permitted, types have to be identical.

```swift
protocol P {}
struct S : P  {}

func foo(_: inout P) {}

var s = S()
foo(&s) // `s` has to be defined as `P` e.g. `var s: P = S()`
        // to be used as an argument to `inout P` parameter.
```

… more flexible.

Add the possibility to solve with a custom join operator.

It causes a use-after-free problem with more aggressive destroy hoisting in the compiler.
Also replace tabs with spaces in this file.

DestroyHoisting moves destroys of memory locations up the control flow as far as possible.
Beside destroy_addr, also "store [assign]" is considered a destroy, because is is equivalent to an destroy_addr + a "store [init]".
The main purpose of this optimization is to minimize copy-on-write operations for arrays, etc. Especially if such COW containers  are used as enum payloads and modified in-place. E.g.

switch e {
  case .A(var arr):
    arr.append(x)
    self = .A(arr)
...

In such a case DestroyHoisting can move the destroy of the self-assignment up before the switch and thus let the array buffer only be single-referenced at the time of the append.

When we have ownership SIL throughout the pass pipeline this optimization will replace the current destroy hoisting optimization in CopyForwarding.
For now, this optimization only runs in the mandatory pipeline (but not for -Onone) where we already have ownership SIL.

SR-10605
rdar://problem/50463362

…er OSes.

rdar://problem/54754304

…function-pointer-indirection

[Runtime] Avoid function pointer indirection in refcounting functions.

…kvopaths_tests

Conditionalize KVOKeyPaths tests that only work with Swift 5.1 (2)

…ftlang#26862)

A generic environment is always serialized as a GenericSignature with
a lazily-recreated environment, though sometimes it has to include
extra info specifically for generic environments used by SIL. The code
that was doing this claimed a bit for disambiguating between the two,
shrinking the permitted size of a compiled module from 2^31 bits to
2^30. (The code isn't just needlessly complicated; GenericEnvironments
used to be serialized with more information.)

Rather than have two representations for GenericEnvironmentID, this
commit just drops it altogether in favor of referencing
GenericSignatures directly.  This causes a negligible file size
shrinkage for swiftmodules in addition to eliminating the problematic
disambiguation bit.

For now, the Deserialization logic will continue to cache
GenericEnvironments that are used directly by Deserialization, but
really that should probably be done at the AST level. Then we can
simplify further to ModuleFile tracking a plain list of
GenericSignatures.

…soc-2019-parser-types

Re-apply "[Parser] Decouple the parser from AST creation (part 2)"

rdar://problem/46680213

…inary.swift

Under `-enable-library-evolution`, a slight AST difference is still found when importing
from .swiftinterface and from .swiftmodule. The difference is whether @objc attribute
is inherited by a Swift class subclassing an Objc class.

SILOptimizer: a new optimization to hoist destroys of memory locations

rdar://54797695

We don't want objc_getClass and NSClassFromString to be able to feed arbitrary symbolic reference
pointers into the Swift runtime. Fixes rdar://problem/54724618.

FindStringNaive is a simple benchmark which implements a naive String
finding algorithm that currently shows a lot of ARC traffic, hopefully
to be reduced in the future.

…ddress

test: enable -enable-library-evolution in compare-dump-interface-vs-binary.swift

…2b8310793d1b14fde50ef0a

…ment/parameter

Since there is no subtyping allowed in `inout` positions, let's
produce a tailored error message and a note about that.

…-on-old-oses

This allows shadowing rules to depend on the current SourceFile and
not just the current ModuleDecl. For now, this isn't actually
taken advantage of.

…egyb

…Only()

…duleWithTheGivenName()

…Decls()

This simulates the shadowing done by ModuleNameLookup, which is about to be
removed.

The basic idea is that if a module A imports a module B, and B imports C,
then from A's point of view, top-level declarations from B will shadow
top-level declarations from C.

…hange

ABI/API checker: diagnose ObjC name changes as breakages

The RUN line was redirecting stderr to stdout, but nothing in the test
was checking for the stderr output.

However, the last line of stderr was an empty newline, which was printed
(in my machine) in the middle of the dump from the AST, breaking the
test.

If we ever need to check the stderr, it should be redirected to a file,
and the file should be passed to FileCheck independently, to avoid
concurrent uses of the output buffer.

…ted-demangler

Runtime: Hook the ObjC runtime with an untrusted demangler.

[test] Disable misaligned indices test prior to 5.1

… the decl containing that closure instead

We were losing the CurLocalContext state (set when entering the closure's
BraceStmt) through the delaying process, sometimes causing errors when we
got back to parsing a delayed decl.

Resolves rdar://problem/54219186

[test] Denineninenineninify behavioral tests added for 5.1

… have an disjunction choice

This will only be false if we have an IUO method call wrapped in parens (like '(s.foo)()'), so assert that the type is a function type as well

…n_borrow, load_borrow, and dead end blocks.

TLDR:

The bug occurs since a copy_value does not need to be balanced by destroy_values
along paths that end in dead end blocks. So our check that all "consuming" uses
of the copy_value are within the lifetime of the begin_borrow, load_borrow
trivially succeed since there are no consuming uses of the copy_value to check!
This then results in us creating a use of a borrowed value after the borrowed
values end borrow.

I go through the bug in detail (via an example) and provide a proof that this
bug can only occur if the copy_value if there exists a set of dead end blocks
that jointly post-dominate the copy.

----

Consider the following SIL:

```
  %1 = begin_borrow %0 : $KlassPair                            (1)
  %2 = struct_extract %1 : $KlassPair, #KlassPair.firstKlass
  %3 = copy_value %2 : $Klass
  ...
  end_borrow %1 : $LintCommand                                 (2)
  cond_br ..., bb1, bb2

  ...

  bbN:
    // Never return type implies dead end block.
    apply %f(%3) : $@convention(thin) (@guaranteed Klass) -> Never (3)
    unreachable
```

For simplicity, note that if bbN post-dominates %3, given that when we compute
linear lifetime errors we ignore dead end blocks, we would not register that the
copy_values only use is outside of the begin_borrow region defined by (1), (2)
and thus would eliminate the copy. This would result in %2 being used by %f,
causing the linear lifetime checker to error.

Naively one may assume that the solution to this is to just check if %3 has
/any/ destroy_values at all and if it doesn't have any reachable destroy_values,
then we are in this case. But is this correct in general? We prove this below:

The only paths along which the copy_value can not be destroyed or consumed is
along paths to dead end blocks. Trivially, we know that such a dead end block,
can not be reachable from the end_borrow since by their definition dead end
blocks do not have any successor instructions or blocks.

So we know that we can only run into this bug if we have a dead end block
reachable from the end_borrow, meaning that the bug can not occur if we branch
before the end_borrow since in that case, the borrow scope would last over the
dead end block's no return meaning that we will not use the borrowed value after
its lifetime is ended by the end_borrow.

With that in hand, we note again that if we have exactly one consumed,
destroy_value /after/ the end_borrow we will not optimize here since the
optimization only attempts to eliminate copies that are not consumed by
non-destroy_value instructions. This means that this bug can only occur if the
copy_value is only post-dominated by dead end blocks that use the value in a
non-consuming way.

NOTE: This can only occur if the copy_value is from a "borrow introducer" that
is associated with an end_borrow. This today includes begin_borrow, load_borrow,
but importantly and notably not function arguments.

rdar://54788632

…nction choice exists

Obviously we won't have a disjunction choice for the locator, it's only possible if the locator is extended with ImplicitlyUnwrappedDisjunctionChoice path element

Framework authors usually have different schemes for different deployment
targets. We should exclude platform-unavailable ABIs from the Json file so
developers will only be warned of the breakages that are relevant to the current
scheme.

rdar://54273296

[ConstraintSystem] Introduce a fix to allow conversion between `inout` types

…manticFn, otherwise fall back to paren check

This is because otherwise we would have false positives, like 'Foo(Bar())' where Foo's init accepts a non-optional Bar and Bar's init returns an IUO

…ed-string-code-completion-crash

[code-completion] Don't delay parsing a decl within a closure - delay the decl containing that closure instead

…ecls-from-abi-descriptors

ABI checker: exclude unavailable decls from ABI descriptors

…e-part-1

New shadowing rule, part 1

This simulates the shadowing done by ModuleNameLookup, which is about to be
removed.

The basic idea is that top-level declarations found via scoped imports
take precedence over unscoped imports.

…e and extra imports

Also get rid of the 'accessPath' parameter.

…gsyntax

[SyntaxParse] use parseGenericArgumentClauseSyntax()

Ensure that lazy parsing of the members of nominal type definitions
and extensions is handled through a request. Most of the effort here
is in establishing a new request zone for parser requests.

…587ec3901a47e3af1892192

[semantic-arc-opts] Fix small bug around eliminating copies from begi…

…26928)

Previously, a warning and fixit was generated for differentiable functions
with non-varied results.

```
tf-775.swift:3:3: warning: result does not depend on differentiation
arguments and will always have a zero derivative; do you want to use
'withoutDerivative(at:)'?
  .zero
  ^
  withoutDerivative(at: )
```

However, TF-775 exposes that the fixit does not work and the warning is
unsilenceable.

This patch temporarily disables the warning, as a robust fix requires
non-trivial activity analysis changes. A lack of warning is better
than an unsilenceable false positive.

TF-788 tracks re-enabling the warning.
Add regression test to ensure that unsilenceable warnings will not
happen again.

…e-part-2

New shadowing rule, part 2

The purpose of this test is to check if the compiler optimizes optionsets as expected. There should not be any additional tweaks necessary, like disabling exclusivity checks.
Fortunately, optimizations are good enough in the meantime that this test also works with enabled exclusivity checking.

The one for enum raw value checking isn't serialized anywhere, so we
can use normal in-process hashing. The ones in the Clang importer's
lookup tables are serialized, but the lookup table is already only
valid for a particular compiler build anyway (it goes into a Clang
PCM, which has the full compiler version in its cache key).

Unlike compiled modules, swiftdoc files are considered a stable
format, so we can't change how information is stored in them. If we
add any more string-hashed tables to swiftdoc files, we should
consider using a new hash seed for those.

...fulfilling the promised audit from 0747d9a. No intended
functionality change /other/ than the order of already-unsorted lists.
This affected a number of SIL tests that relied on deserialization
order matching the original source order; I have no idea why the old
hash logic would make that the case. If we think that's a valuable
property, we should serialize a list of functions in addition to the
iterable table. (Maybe just in SIB mode?)

…cess it

rdar://54837190

…" state.

The `DelayedDeclKind` structure that's allocated for each case where
we delay parsing the members of a nominal type definition or extension
contains information that is already available on the
`IterableDeclContext` (or can be reconstructed trivially from it). Use
that AST information rather than this side structure.

…thout-stderr

[test] Remove redirection stderr->out that corrupted output.

Recently, we've given up on swiftlang#26708
which was trying to include Quote in the apple/swift:tensorflow build.

However, we still need a little bit of that PR in order to keep track
of which version of Quote the quoting logic in the compiler depends on.

It is somewhat awkward to clone Quote during the build and then not use
it afterwards, but that's the best that our current infrastructure
allows us.

[SyntaxParse] Fix round-trip issue in function types

…-config

Add Quote to update-checkout-config.json

…s header import module

Now that the normal name lookup shadowing can handle the module-based
shadowing rules implemented by lookupInModule(), we can drastically
simplify the implementation, replacing the graph traversal with an
iteration over the linearized graph.