The locations stored in .swiftsourceinfo included the presumed file,
line, and column. When a location is requested it would read these, open
the external file, create a line map, and find the offset corresponding
to that line/column.
The offset is known during serialization though, so output it as well to
avoid having to read the file and generate the line map.
Since the serialized location is returned from `Decl::getLoc()`, it
should not be the presumed location. Instead, also output the line
directives so that the presumed location can be built as per normal
locations.
Finally, move the cache out of `Decl` and into `ASTContext`, since very
few declarations will actually have their locations deserialized. Make
sure to actually write to that cache so it's used - the old cache was
never written to.
Add a feature for this new attribute, and make sure we use the feature
guard for functions that use it, e.g., the new `async`.
Finishes rdar://76927008.
For various reasons, it can be useful/interesting to create builds of
Swift that minimize dependencies. Let's try to keep that working as long
as we can.
- stop storing the parent task in the TaskGroup at the .swift level
- make sure that swift_taskGroup_isCancelled is implied by the parent
task being cancelled
- make the TaskGroup structs frozen
- make the withTaskGroup functions inlinable
- remove swift_taskGroup_create
- teach IRGen to allocate memory for the task group
- don't deallocate the task group in swift_taskGroup_destroy
To achieve the allocation change, introduce paired create/destroy builtins.
Furthermore, remove the _swiftRetain and _swiftRelease functions and
several calls to them. Replace them with uses of the appropriate builtins.
I should probably change the builtins to return retained, since they're
working with a managed type, but I'll do that in a separate commit.
Clang deduces its installation directory from the `argv[0]` parameter (see clang/lib/Frontend/CreateInvocationFromCommandLine.cpp), and the default include search paths are computed based on the installation directory.
This change allows compiling Swift code that imports the C++ stdlib without having to manually specify the include search path of `std` headers.
For example, now we get the following diagnostic on globals:
public func getGlobal() -> Klass {
return global // expected-remark @:5 {{retain of type 'Klass'}}
// expected-note @-5:12 {{of 'global'}}
+ // expected-remark @-2:12 {{begin exclusive access to value of type 'Klass'}}
+ // expected-note @-7:12 {{of 'global'}}
+ // expected-remark @-4 {{end exclusive access to value of type 'Klass'}}
+ // expected-note @-9:12 {{of 'global'}}
+
}
and for classes when we can't eliminate the access:
+func simpleInOut() -> Klass {
+ let x = Klass() // expected-remark @:13 {{heap allocated ref of type 'Klass'}}
+ // expected-note @-1:9 {{of 'x'}}
+ simpleInOutUser(&x.next) // expected-remark @:5 {{begin exclusive access to value of type 'Optional<Klass>'}}
+ // expected-note @-3:9 {{of 'x.next'}}
+ // expected-remark @-2:28 {{end exclusive access to value of type 'Optional<Klass>'}}
+ // expected-note @-5:9 {{of 'x.next'}}
+ return x
+}
Intro the concept of library access or distribution level to identify
layers of libraries and report public imports of private libraries from
public ones.
rdar://62934005
This commit fixes two weird bugs in -verify mode:
1. SourceLocs from the wrong SourceManager could be passed through a ForwardingDiagnosticConsumer into the DiagnosticVerifier.
2. -verify-additional-file did not error out correctly when the file couldn’t be opened.
No tests, as we only have basic tests for the diagnostic verifier.
The frontend supports this via new options -index-unit-output-path and
-index-unit-output-path-filelist that mirror -o and -output-filelist. These are
intended to allow sharing index data across builds in separate directories (so
different -o values) that are otherwise equivalent as far as the index data is
concerned (e.g. an ASAN build and a non-ASAN build) by supplying the same
-index-unit-output-path for both.
This change updates the driver to add these new options to the frontend
invocation 1) when a new "index-unit-output-path" entry is specified for one
or more input files in the -output-file-map json or 2) if -index-file is
specified, when a new -index-unit-output-path driver option is passed.
Resolves rdar://problem/74816412
To help support incremental adoption of the concurrency model, a number
of concurrency-related diagnostics are enabled only in "new" code that
takes advantage of concurrency features---async, @concurrent functions,
actors, etc. This warning flag opts into additional warnings that better
approximate the eventual concurrency model, and which will become
errors a future Swift version, allowing one to both experiment with
the full concurrency model and also properly prepare for it.
These new options mirror -o and -output-filelist and are used instead
of those options to supply the output file path(s) to record in the
index store. This is intended to allow sharing index data across
builds in separate directories that are otherwise equivalent as far
as the index data is concered (e.g. an ASAN build and a non-ASAN build)
by supplying the same -index-unit-output-path for both.
Resolves rdar://problem/74816412
* [Sema]: Add Codable synthesis for enums with associated values
* Incorporate review feedback for enum Codable synthesis
* Implement enum specific versions of existing Codable tests
* Encode parameterless enum cases as
* Add test for overloaded case identifiers
* Align code generation with latest proposal revision
* Put enum codable derivation behind flag
* clang-format sources
* Address review feedback and fix tests
* Add diagnostic for conflicting parameter identifiers
* Restructure code after rebase
This patch removes the feature flag for @hasAsyncAlternative since it's
already protected by the experimental concurrency flag and will go in
with the concurrency features.
This fixes one of Doug's comments on
https://github.com/apple/swift/pull/36027.
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.
We're not quite ready to commit to the flow-sensitive check that would
allow a concurrent function to read from a mutable local capture so
long as the captured variable wasn't changed after the point of
capture. Put it behind a flag and implement the more restrictive rule
(no access to mutable local captures in concurrent code). We can relax
it later.
