Cursor info for a constructor would previously give the cursor info for
the containing type only. It now also adds cursor info for the
constructor itself in a "secondary_symbols" field.
Refactor `passCursorInfoForDecl` to use a single allocator rather than
keeping track of positions in a buffer and assigning everything at the
end of the function.
Refactor the various available refactoring gathering functions to take a
SmallVectorImpl and to not copy strings where they don't need to.
Resolves rdar://75385556
This will enable users to try out the '-enable-ossa-modules' flag if their
compiler supports it and get OSSA code on all inlinable code that they use. The
idea is that this is a nice way to stage this in and get more testing.
The specific implementation is that the module interface loader:
1. Knows if enable ossa modules is enabled not to search for any compiled
modules. We always rebuild from the interface file on the system.
2. Knows that if enable ossa modules is enabled to mixin a bit into the module
interface loader cache hash to ensure that we consider the specialized ossa
compiled modules to be different than the modules in that cache from the system.
This ensures that when said flag is enabled, the user transparently gets all
their code in OSSA form from transparent libraries.
Previous output:
```
could not deserialize type for ‘foo(_:)': top-level value not found
Cross-reference to module ‘Bar_Private'
... Baz
```
New output:
```
Could not deserialize type for ‘foo(_:)'
Caused by: top-level value not found
Cross-reference to ‘Baz' in module 'Bar_Private'
```
Introduce the notion of global actor-qualified function types, e.g.,
@MainActor () -> Void
to describe synchronous functions that must execute on a particular
global actor.
Assuming that we don't typecheck a deserialized module, we don't
actually need the ExplicitCompletionHandlerIndex. We used this flag to
determine whether we could trust the number stored in the handler index
or just take the last parameter of the function we're attached to.
Since we only typecheck it before serialization, we can safely check
that the completion handler location is valid before choosing whether we
should trust it or not.
We can get the DeclName of the async function from the resolved function
decl itself, so we don't actually need to serialize it. This patch pulls
the declNameRef from the serialization.
This patch replaces the @hasAsyncAlternative attribute with
@completionHandlerAsync. The @completionHandlerAsync attribute takes the
function decl name of the async function and optionally the index of the
completion hander parameter in the function that it's attached to.
If the completion handler index is not provided, it's assumed to be the
last parameter in the parameter list.
We resolve the async function while typechecking the attribute. Before
resolving, we verify that the function the attribute is attached to
isn't async, that it has enough parameters to at least have the
indicated completion handler referenced by the index, that the
completion handler is an escaping non-auto-closure function that returns
Void.
The async function declaration resolution isn't perfect yet, but I want
to get this patch up and we can refine it later. It pulls all of the
delcs with the specified declname in the same context as the
function that the attribute is attached to. Going through that list, it
keeps any that are async functions. If there are none, we emit an error
saying that there are no viable functions, if there are multiple we emit
an error saying that the decl name is ambiguous, and if there is one
function, we keep that as the resolve async function declaration.
This does not take into account the data types of the completion handler
or the async function. There are some complexities to making this
mapping. Here are the pieces:
- If the completion handler takes a single data type, the async
function should return that type. (easy case)
- If the completion handler takes a `Result<T, Error>`, the async
function is a throwing function that returns a T. (Medium difficulty)
- If the completion handler looks like `(T?, Error?) -> Void`, we have
an ambiguous situation between the following async functions:
- func foo() async throws -> T
- func foo() async throws -> T?
That is, we cannot tell whether the `T?` in the completion handler is
optional because it will be nil on an error, or if it is intended to
be optional.
This can be done later if it becomes a problem.
Introduce a new compiler flag `-module-abi-name <name>` that uses the
given name as the ABI name for the module (rather than the module's
name in source code). The ABI name impacts name mangling and metadata.
When the user spells an invalid precedence group, the Relation for that
group will fail to resolve the decl. We need to handle this in
checkPrecedenceGroup. Also add some asserts while I'm here.
rdar://75248642
Refactor SILGen's ApplyOptions into an OptionSet, add a
DoesNotAwait flag to go with DoesNotThrow, and sink it
all down into SILInstruction.h.
Then, replace the isNonThrowing() flag in ApplyInst and
BeginApplyInst with getApplyOptions(), and plumb it
through to TryApplyInst as well.
Set the flag when SILGen emits a sync call to a reasync
function.
When set, this disables the SIL verifier check against
calling async functions from sync functions.
Finally, this allows us to add end-to-end tests for
rdar://problem/71098795.
47b068d445 output a diagnostic if a
deserialized decl was invalid (checking `Decl::isInvalid`). It had two
major issues:
1. It incorrectly output diagnostics for valid modules
2. It did not catch call invalid declarations
(1) is caused by `isInvalid` falling back to checking the storage for
accessors when the interface type hasn't already been computed (a
fallback to prevent a cycle due to `SimpleDidSetRequest` typechecking
the body). Since the `VarDecl` hasn't finished deserializing, it returns
`true` for its `isInvalid` check (even though it would later return
`false`).
For (2), only `ValueDecl`s would ever be invalid, since other
declarations use a bit in `Decl` to check for validity. As that's not
serialized, those would always be valid in deserialization.
To avoid both these issues, instead output a flag for each declaration
representing whether it is invalid (or not). Read that during
deserialization and output a diagnostic if it is invalid. To be extra
sure that a diagnostic is always output on an error, also output one
when deserializing any `ErrorType`. This ensures that SILGen does not
run when allowing errors (and an error is present), as it is likely to
crash when presented with an invalid AST.
Resolves rdar://74541834
In the legacy driver, these flags will merely be propagated to the
frontends to indicate that they should disable serialization of
incremental information in swift module files.
In the new driver, these flags control whether the Swift driver performs
an incremental build that is aware of metadata embedded in the module.
Kudos to David for coming up with our new marketing name: Incremental
Imports.
rdar://74363450
Allow us to tag declarations that are meant to be in a global actor, but
for which we don't yet want to enforce everything. This will be used for
better staging-in of global actor annotations, but for now it's a fancy
way to document @actorIndependent(unsafe).
Stages in the syntax for rdar://74241687 without really implementing it.
If allowing modules to be output with compile errors
(-experimental-allow-module-with-errors), import targets regardless of
whether they are compatible or not, and still output the module. The
error diagnostic will still be output (preventing SILGen), but the AST
will be available for various editor functionality.
This attribute marks a function has having an async alternative,
optionally providing the name of that function as a string. Intended to
be used to allow warnings when using a function with an async
alternative in an asynchronous context, to make the async refactorings
more accurate, and for documentation.
When running in the allow errors mode
(-experimental-allow-module-with-compiler-errors), modules may contain
invalid declarations. The rest of the compiler pipeline, however,
expects to have valid declarations unless diagnostics have emitted an
error. Emit an error while deserializing to maintain this assumption.
Note that these errors will not have a useful location, unless there's a
corresponding `.swiftsourceinfo`. This isn't a problem for the intended
use case in IDEs, where diagnostics outside the current file would be
ignored anyway.
Since reading declarations is lazy, SILGen (and thus SIL diagnostics)
can still run as long as any invalid declarations weren't referenced in
the compiling module.
Resolves rdar://74325388
Otherwise, one runs into memory corruption. I ran into this while enabling ossa
on the stdlib for non-Darwin platforms.
Hopefully we do not regress on this again when someone adds more optzns that
eliminate these since I added a big NOTE to warn people to do it and implemented
support even for the entities we do not support deleting at the SIL
level... yet.
