Use the attached atttribute's location as the location of the macro,
rather than the location of the declaration it's attached to. Also add
the kind and name of that declaration to the note itself.
Using a virutal output backend to capture all the outputs from
swift-frontend invocation. This allows redirecting and/or mirroring
compiler outputs to multiple location using different OutputBackend.
As an example usage for the virtual outputs, teach swift compiler to
check its output determinism by running the compiler invocation
twice and compare the hash of all its outputs.
Virtual output will be used to enable caching in the future.
Introduce appropriate name lookup for custom attributes to find macros
at module scope, and prefer those to types of the same name. We don't
do anything with the macros we found other than ignore them, for the
moment.
Always parse macro expansions, regardless of language mode, and
eliminate the fallback path for very, very, very old object literals
like `#Color`. Instead, check for the feature flag for macro
declaration and at macro expansion time, since this is a semantic
restriction.
While here, refactor things so the vast majority of the macro-handling
logic still applies even if the Swift Swift parser is disabled. Only
attempts to expand the macro will fail. This allows us to enable the
macro-diagnostics test everywhere.
Implement an ASTGen operation to bridge swift-syntax diagnostics, as
produced by the parser, operator folding, and macros, over to the C++
diagnostic engine infrastructure. Use this to wire up macro expansion
diagnostics.
Now that directReferencesForTypeRepr() no longer returns
ambiguous results, move the special ambiguity diagnostic out
of CustomAttrNominalRequest::evaluate(), and instead
diagnose these situations in TypeCheckAttr.cpp.
Special-case the 'unknown type' diagnostic though, to report
'unknown attribute' in the common case where the name lookup
failed.
Using the serialization format added in https://github.com/apple/swift/pull/37585.
- Add load/save code for the `-scan-dependencies` code-path.
- Add `libSwiftDriver` entry-points to load/store the cache of a given scanner instance.
of adding a property.
This better matches what the actual implementation expects,
and it avoids some possibilities of weird mismatches. However,
it also requires special-case initialization, destruction, and
dynamic-layout support, none of which I've added yet.
In order to get NSObject default actor subclasses to use Swift
refcounting (and thus avoid the need for the default actor runtime
to generally use ObjC refcounting), I've had to introduce a
SwiftNativeNSObject which we substitute as the superclass when
inheriting directly from NSObject. This is something we could
do in all NSObject subclasses; for now, I'm just doing it in
actors, although it's all actors and not just default actors.
We are not yet taking advantage of our special knowledge of this
class anywhere except the reference-counting code.
I went around in circles exploring a number of alternatives for
doing this; at one point I basically had a completely parallel
"ForImplementation" superclass query. That proved to be a lot
of added complexity and created more problems than it solved.
We also don't *really* get any benefit from this subclassing
because there still wouldn't be a consistent superclass for all
actors. So instead it's very ad-hoc.
To help solving rdar://67079780, this change allows swift-driver to configure scanner using additional
arguments passed down via the batch input JSON file for each module under scanning.
…and modify resolveFileIDConflicts() to diagnose any such violations instead of asserting.
Swift does not allow any two files in the same module to have the same filename, even if they are in different directories. However, this is enforced in the driver, so tests that invoke the frontend directly can violate it. Turns out that a couple of those snuck into the test suite at various points.
This commit updates those tests. It also causes the frontend to diagnose the duplicate filename error just as the driver would have, which should help us understand what happened more easily if this crops up again in the future.
NFC, since invoking the frontend directly is unsupported.
Add ModuleImplicitImportsRequest, which computes
the modules that should be implicitly imported by
each file of a given module. Use this request in
import resolution to add all the necessary
implicit imports.
The request computes the implicit imports by
consulting the ImplicitImportInfo, which ModuleDecl
can now be created with. This allows us to remove
uses of `SourceFile::addImports` in favor of
adding modules needed to be implicitly imported to
the ImplicitImportInfo.
These were duplicated in 11 different files, and as they've gotten more
complex a few inconsistencies have snuck in. Sharing them should make future
changes easier and less bug-prone.
These are mostly harmless, except that they make the two module names synonymous in qualified lookup. A hard error seems too aggressive for something that could easily be caused by uncoordinated changes to two modules, so warn instead.
Swift 5.1's lookup for custom attributes skipped associated type
members, which allowed code like the given example to compile. To
maintain source compatibility, identify the narrow case that happens
in practice---the property wrapper is at module scope but is now
shadowed by an associated type---warn about it, and accept it.
Fixes rdar://problem/56213175.
These are defined with macros like errors/warnings/notes, and
make use of format strings and diagnostic arguments. The intent
is to leverage diagnostic arguments in the future to disambiguate
ambiguously spelled types.
Ported a few miscellaneous fix-its to the new system
Add the request `ProtocolRequiresClassRequest` to lazily determine if a
`ProtocolDecl` requires conforming types to be a class.
Note that using the request evaluator to compute `requiresClass` introduces
cycle errors for protocol declarations, where this computation didn't
previously emit diagnostics. For now, we'll allow duplicate diagnostics in this
case, with the eventual goal of removing explicitly checking for cycles
via `checkCircularity` (instead letting the request evaluator handle cycle
diagnostics).
Removing accessors other than getter and setter can be ABI breaking. This
patch starts to formally include all accessor decls in the tree and diagnose
their removal. This change only applies to the ABI checker since we still
exclude accessors other than getter and setter when diagnosing source
compatibility.
Including accessors formally can also allow us to check the missing
of availability attributes for newly added accessors.
rdar://52063421
-verify-generic-signatures didn't catch the bad case from
<https://bugs.swift.org/browse/SR-10752>. Add a new check and
make sure it now catches this kind of failure.
* Emit a warning diagnostic if an extension contains a redundant requirement
* Updates diagnostic message and checks if the extension type is a protocol
* Updates indentation and extracts self type
* [ast] Updates diagnostic message
* [ast] fix indentation
* [ast] Change ':' to 'to' in 'protocol_extension_redundant_requirement'
* [sema] Adds protocol extension redundant requirement check
Moved from TypeCheckRequests to TypeCheckGeneric
* [ast] fix some crashes related to null ptrs, check self type before emitting a diagnostic, update tests
* [ast] renames 'owner' to 'ext'
* [sema] fix style
* [test] Add another test case for redundant requirement
Co-Authored-By: theblixguy <suyashsrijan@outlook.com>
* [test] fix failing test
The test was failing because A has already been declared as a typealias.
Sink the type checker request classes into the AST library, so that
various functions in the AST library can form type-checking requests.
The actual evaluator functions for these requests continue to live
in the Sema library, called via indirection through the function
pointer tables registered with the request-evaluator.
Validation of the input side of FunctionTypeRepr was previously being done in Sema because of expression folding. If we instead push the invariant that the input TypeRepr should always be a TupleTypeRepr into the AST a number of nice cleanups fall out:
- The SIL Parser no longer accepts Swift 2-style type declarations
- Parse is more cleanly able to reject invalid FunctionTypeReprs
- Clients of the AST can be assured the input type is always a TupleType so we can flush Swift 2 hacks
