Merge branch 'main' into member-macro-conformances

Author: DougGregor

.github/CODEOWNERS

@@ -68,6 +68,7 @@
 /include/swift/IDE/                                @ahoppen @bnbarham @rintaro @hamishknight
 /include/swift/Index/                              @bnbarham
 /include/swift/Refactoring                         @ahoppen @bnbarham
+/include/swift/Option/*Options*                    @tshortli
 /include/swift/Parse/                              @ahoppen @bnbarham @CodaFi @DougGregor @rintaro
 /include/swift/PrintAsClang                        @zoecarver @hyp @egorzhdan
 # TODO: /include/swift/SIL/

SwiftCompilerSources/Package.swift

@@ -26,14 +26,14 @@ private extension Target {
         path: path ?? "Sources/\(name)",
         exclude: ["CMakeLists.txt"],
         sources: sources,
-        cxxSettings: [
-          .headerSearchPath("../include"),
-          .headerSearchPath("../../llvm-project/llvm/include"),
-          .headerSearchPath("../../llvm-project/clang/include"),
-        ],
         swiftSettings: [
           .interoperabilityMode(.Cxx),
-          .unsafeFlags(["-cross-module-optimization"]),
+          .unsafeFlags([
+            "-Xcc", "-I../include",
+            "-Xcc", "-I../../llvm-project/llvm/include",
+            "-Xcc", "-I../../llvm-project/clang/include",
+            "-cross-module-optimization",
+          ]),
         ] + swiftSettings)
     }
 }

SwiftCompilerSources/Sources/Optimizer/FunctionPasses/ComputeSideEffects.swift

@@ -142,6 +142,24 @@ private struct CollectedEffects {
         handleApply(pa)
         checkedIfDeinitBarrier = true
       }
+      // In addition to the effects of the apply, also consider the
+      // effects of the capture, which reads the captured value in
+      // order to move it into the context. This only applies to
+      // addressible values, because capturing does not dereference
+      // any class objects.
+      //
+      // Ignore captures for on-stack partial applies. They only
+      // bitwise-move or capture by address, so the call to
+      // handleApply above is sufficient. And, if they are not applied
+      // in this function, then they are never applied.
+      if !pa.isOnStack {
+        // the callee and its arguments are all captured...
+        for operand in pa.operands {
+          if operand.value.type.isAddress {
+            addEffects(.read, to: operand.value)
+          }
+        }
+      }
 
     case let fl as FixLifetimeInst:
       // A fix_lifetime instruction acts like a read on the operand to prevent

docs/ABI/Mangling.rst

@@ -150,7 +150,6 @@ Globals
   #endif
   global ::= protocol-conformance 'Hc'   // protocol conformance runtime record
   global ::= global 'HF'                 // accessible function runtime record
-  global ::= global 'Ha'                 // runtime discoverable attribute record
 
   global ::= nominal-type 'Mo'           // class metadata immediate member base offset
 

docs/Generics/chapters/basic-operation.tex

@@ -44,7 +44,7 @@ \chapter{Basic Operation}\label{rqm basic operation}
 \end{enumerate}
 Note that we have all four combinations of domain and ``purpose.'' In case (1) and (2) above, the domain is a list of generic parameters. In case (3)~and~(4), the domain is a list of protocols in a protocol component (which will be introduced shortly). In case (1)~and~(3), our goal is to build a requirement machine and use its rewrite system and property map, so we don't record rewrite loops. In case (2)~and~(4), we're also computing a list of minimal requirements, so we \emph{do} record rewrite loops. Let's now take a closer look at each of these four possibilities.
 
-\paragraph{Generic signature}
+\paragraph{Generic signature.}
 \index{generic signature query}%
 \IndexDefinition{rewrite context}%
 \index{rewrite rule}%
@@ -132,7 +132,7 @@ \chapter{Basic Operation}\label{rqm basic operation}
 \end{center}
 \end{figure}
 
-\paragraph{Generic signature minimization}
+\paragraph{Generic signature minimization.}
 \index{inferred generic signature request}%
 \index{abstract generic signature request}%
 \index{minimal requirement}%
@@ -159,7 +159,7 @@ \chapter{Basic Operation}\label{rqm basic operation}
 \end{itemize}
  The \texttt{-disable-requirement-machine-reuse} frontend flag forces the rewrite context to always just discard the requirement machine after minimization. If you're lucky enough to discover a new scenario not covered by one of the above cases, then this flag might address the problem; it would certainly make for an interesting bug report!
 
-\paragraph{Protocol component}
+\paragraph{Protocol component.}
 \index{protocol component}%
 A requirement machine for a protocol component is built in a similar way to Figure~\ref{rqm flowchart generic signature}. We take with the requirement signature of each protocol in the component, build rewrite rules, run completion, and construct the property map. Protocol component machines are never directly used for queries; we only issue queries against generic signature machines. Instead, protocol component machines only have one purpose in life: to have their rewrite rules imported into other requirement machines.
 \eject
@@ -170,7 +170,7 @@ \chapter{Basic Operation}\label{rqm basic operation}
 \index{main module}%
 Typically, protocol component requirement machines are created for protocols that were deserialized from another module, where the requirement signatures were previously computed and serialized as well. For protocols in the main module (that is, written in source) we use the fourth and final kind of requirement machine to compute their requirement signatures first; this requirement machine is then installed in the rewrite context so that those rules can be imported later. However, just as the generic signature minimization requirement machine cannot be installed under some circumstances, the same edge cases can force us to discard the protocol component minimization requirement machine instead of installing it, in which case we will build a new protocol component requirement machine from the requirement signatures we just built.
 
-\paragraph{Protocol component minimization}
+\paragraph{Protocol component minimization.}
 \index{structural requirements request}%
 \index{type alias requirements request}%
 \index{requirement signature request}%
@@ -186,7 +186,7 @@ \section{Protocol Components}\label{protocol component}
 
 TODO: mention domain
 
-\paragraph{Derived requirements}
+\paragraph{Derived requirements.}
 There is a link between the protocol dependency graph and the \index{derived requirement}derived requirements formalism. Define a relation \index{$\prec$}\index{$\prec$!z@\igobble|seealso{reachability relation}}$\prec$ between protocols, where $\texttt{P}\prec\texttt{Q}$ if $G_\texttt{P}\vDash\ConfReq{T}{Q}$ for some type parameter \texttt{T}; that is, $\texttt{P}\prec\texttt{Q}$ means that we can derive a conformance requirement mentioning \texttt{Q} starting from the requirements of \texttt{P}. Now, this conformance requirement has a conformance path, to which we can apply our graph homomorphism and get a path from \texttt{P} to \texttt{Q}. Thus, $\texttt{P}\prec\texttt{Q}$ can also be understood as the reachability relation in the protocol dependency graph. In Chapter~\ref{rqm basic operation}, we make use of this fact when building the rewrite system for a generic signature, by pulling in the requirements of protocols reachable via the protocol dependency graph.
 
 \index{protocol dependency graph}%

docs/Generics/chapters/building-generic-signatures.tex

@@ -119,7 +119,7 @@ \chapter{Building Generic Signatures}\label{building generic signatures}
 The inferred generic signature request emits diagnostics at the source location of the generic context in the following circumstances:
 \begin{enumerate}
 \item If the compiler is able to prove that no substitution map can ever simultaneously satisfy all of the requirements in the generic signature, the signature is said to contain \emph{conflicting requirements}. These will diagnose an error.
-\item If some requirement can be shown to be a consequence of other requirements, the requirement is called a \emph{redundant requirement}. By default, redundant requirements are silently dropped, but if the \texttt{-Xfrontend -warn-redundant-requirements} flag is passed they are diagnosed as warnings.
+\item If some requirement can be shown to be a consequence of other requirements, the requirement is called a \emph{redundant requirement}. By default, redundant requirements are silently dropped, but if the \texttt{-Xfrontend -warn-redundant-requirements} flag is passed they are diagnosed as \index{warning}warnings.
 \end{enumerate}
 
 \begin{figure}\captionabove{Overview of the abstract generic signature request}\label{abstract generic signature request figure}
@@ -169,7 +169,7 @@ \chapter{Building Generic Signatures}\label{building generic signatures}
 \index{inheritance clause}
 Recall from Section~\ref{protocols} that a constraint type written in a protocol's inheritance clause declares a conformance requirement with a subject type of \texttt{Self}. Qualified name lookup must be aware of protocol inheritance relationships, since a lookup into a protocol can also find members of inherited protocols. However, qualified lookup sits ``below'' generics. Building a protocol's requirement signature performs type resolution, which queries name lookup; those name lookups cannot in turn depend on the requirement signature having already been constructed. Thus, qualified name lookup can only look at syntactic constructs and cannot query the requirement signature.
 
-The practical consequence of this design is that protocol inheritance must be explicitly stated, and cannot be implied as a non-trivial consequence of same-type requirements. After building a protocol's requirement signature, we ensure that any conformance requirements known to be satisfied by \texttt{Self} are actually explicit requirements written in the protocol's inheritance clause, or \texttt{where} clause entires with a subject type of \texttt{Self}. Anything else is diagnosed with a warning.
+The practical consequence of this design is that protocol inheritance must be explicitly stated, and cannot be implied as a non-trivial consequence of same-type requirements. After building a protocol's requirement signature, we ensure that any conformance requirements known to be satisfied by \texttt{Self} are actually explicit requirements written in the protocol's inheritance clause, or \texttt{where} clause entires with a subject type of \texttt{Self}. Anything else is diagnosed with a \index{warning}warning.
 
 \begin{listing}\captionabove{Example showing non-obvious protocol inheritance relationship}\label{badinheritance}
 \begin{Verbatim}
@@ -196,7 +196,7 @@ \chapter{Building Generic Signatures}\label{building generic signatures}
 \begin{example}
 In Listing~\ref{badinheritance}, the \texttt{Self} type of the \texttt{Bad} protocol is equivalent to the type parameter \texttt{Self.Tricky.Other} via a same-type requirement. The \texttt{Tricky} associated type conforms to \texttt{Base}, and the \texttt{Other} associated type of \texttt{Base} also conforms to \texttt{Base}. For this reason, the \texttt{Self} type of \texttt{Bad} actually conforms to \texttt{Base}.
 
-However, this inheritance relationship is invisible to name lookup, so resolution of the underlying type of \texttt{Income} fails to find the declaration of \texttt{Salary}. After building the protocol's requirement signature, the type checker discovers the unexpected conformance requirement on \texttt{Self}, but at this stage, it is too late to attempt the failed name lookup again! The compiler instead emits a warning suggesting the user explicitly states the inheritance relationship in the declaration of \texttt{Bad}.
+However, this inheritance relationship is invisible to name lookup, so resolution of the underlying type of \texttt{Income} fails to find the declaration of \texttt{Salary}. After building the protocol's requirement signature, the type checker discovers the unexpected conformance requirement on \texttt{Self}, but at this stage, it is too late to attempt the failed name lookup again! The compiler instead emits a \index{warning}warning suggesting the user explicitly states the inheritance relationship in the declaration of \texttt{Bad}.
 \end{example}
 
 \section{Requirement Inference}\label{requirementinference}
@@ -217,7 +217,7 @@ \section{Requirement Inference}\label{requirementinference}
 \end{Verbatim}
 The type \verb|Set<S.Element>| only makes sense if \texttt{S.Element} conforms to \texttt{Hashable}. This is checked by type resolution in the interface resolution stage, after the generic signature has been built. However this requirement is not explicitly stated here. Instead, requirement inference \emph{adds} this requirement during the structural resolution stage when the generic signature is being built, ensuring that the type representation \verb|Set<S.Element>| can successfully resolve later.
 
-You can always state an inferred requirement explicitly instead. Since this is useful for documentation purposes, the \verb|-warn-redundant-requirements| flag will not emit a warning if an explicit requirement is made redundant by an inferred requirement.
+You can always state an inferred requirement explicitly instead. Since this is useful for documentation purposes, the \verb|-warn-redundant-requirements| flag will not emit a \index{warning}warning if an explicit requirement is made redundant by an inferred requirement.
 \begin{Verbatim}
 func uniqueElements<S: Sequence>(_ seq: S) -> Set<S.Element>
     where S.Element: Hashable {...}
@@ -678,17 +678,17 @@ \section{Requirement Validity}\label{generic signature validity}
 Having done that, we argue that for all other derivation steps in our given derivation, the formal substitution alone is sufficient and preserves validity. For example, suppose we have the following derivation in a protocol generic signature \verb|<Self where Self: P>|:
 \begin{gather}
 \vdash\ConfReq{Self}{P}\tag{1}\\
-\vdash\FormalReq{Self.A == Self.B}\qquad\mbox{(in \texttt{P})}\tag{2}\\
-\vdash\FormalReq{Self.B == Self.C}\qquad\mbox{(in \texttt{P})}\tag{3}\\
+\vdash\FormalReq{Self.A == Self.B}_\texttt{P}\tag{2}\\
+\vdash\FormalReq{Self.B == Self.C}_\texttt{P}\tag{3}\\
 (1),\,(2)\vdash\FormalReq{Self.A == Self.B}\tag{4}\\
 (1),\,(3)\vdash\FormalReq{Self.B == Self.C}\tag{5}\\
 (1),\,(5)\vdash\FormalReq{Self.A == Self.C}\tag{6}
 \end{gather}
 After replacing the initial derivation step with a derivation of \texttt{T} and substituting \texttt{T} for \texttt{Self} in all other derivation steps, we get a derivation in $G$:
 \begin{gather}
 \ldots \vdash\ConfReq{T}{P}\tag{1}\\
-\vdash\FormalReq{Self.A == Self.B}\qquad\mbox{(in \texttt{P})}\tag{2}\\
-\vdash\FormalReq{Self.B == Self.C}\qquad\mbox{(in \texttt{P})}\tag{3}\\
+\vdash\FormalReq{Self.A == Self.B}_\texttt{P}\tag{2}\\
+\vdash\FormalReq{Self.B == Self.C}_\texttt{P}\tag{3}\\
 (1),\,(2)\vdash\FormalReq{T.A == T.B}\tag{4}\\
 (1),\,(3)\vdash\FormalReq{T.B == T.C}\tag{5}\\
 (1),\,(5)\vdash\FormalReq{T.A == T.C}\tag{6}

docs/Generics/chapters/compilation-model.tex

@@ -56,7 +56,7 @@ \chapter{Compilation Model}\label{compilation model}
 \begin{itemize}
 \item \IndexDefinition{parser}\textbf{Parse:} First, all source files are parsed to form the \IndexDefinition{abstract syntax tree}\index{AST|see{abstract syntax tree}}\index{syntax tree|see{abstract syntax tree}}abstract syntax \index{tree}tree.
 \item \IndexDefinition{Sema}\textbf{Sema:} Semantic analysis type-checks and validates the abstract syntax tree.
-\item \IndexDefinition{SILGen}\textbf{SILGen:} The type-checked syntax tree is lowered to \IndexDefinition{raw SIL}``raw SIL.'' SIL is the Swift Intermediate Language, described in \cite{sil}.
+\item \IndexDefinition{SILGen}\textbf{SILGen:} The type-checked syntax tree is lowered to \IndexDefinition{raw SIL}``raw SIL.'' SIL is the Swift Intermediate Language, described in \cite{sil} and \cite{siltalk}.
 \item \IndexDefinition{SIL optimizer}\textbf{SILOptimizer:} The raw SIL is transformed into \IndexDefinition{canonical SIL}``canonical SIL'' by a series of \IndexDefinition{SIL mandatory pass}\emph{mandatory passes}, which analyze the control flow graph and emit diagnostics; for example, \IndexDefinition{definite initialization}\emph{definite initialization} ensures that all storage locations are initialized.
 
 When the \IndexFlag{O}\texttt{-O} command line flag is specified, the canonical SIL is further optimized by a series of \IndexDefinition{SIL performance pass}\emph{performance passes} with the goal of improving run-time performance and reducing code size.
@@ -500,7 +500,7 @@ \section{Module System}\label{module system}
 \IndexFlag{import-objc-header}
 Invoking the compiler with the \texttt{-import-objc-header} flag followed by a header file name specifies a \emph{bridging header}. This is a shortcut for making C declarations in the bridging header visible to all other source files in the main module, without having to define a separate Clang module first. This is implemented by adding a Clang file unit corresponding to the bridging header to the main module. For this reason, compiler code should not assume that all file units in the main module are necessarily source files.
 
-\paragraph{Textual interfaces} \IndexFlag{emit-module-interface}The Swift serialized module format depends on compiler internals and no attempt is made to preserve compatibility across compiler releases. When building a shared library for distribution, it is better to generate a \IndexDefinition{textual interface}\emph{textual interface}:
+\paragraph{Textual interfaces} \IndexFlag{emit-module-interface}The Swift serialized module format depends on compiler internals and no attempt is made to preserve compatibility across compiler releases. When building a shared library for distribution, it is better to generate a \IndexDefinition{textual interface}\emph{textual interface}:\index{horse}
 \begin{Verbatim}
 $ swiftc Horse.swift -enable-library-evolution -emit-module-interface
 \end{Verbatim}
@@ -723,4 +723,4 @@ \subsection*{Module System}
 \item \SourceFile{lib/AST/ASTPrinter.cpp}
 \end{itemize}
 
-\end{document}
+\end{document}