When printing a swiftinterface, represent opaque result types using an attribute that refers to
the mangled name of the defining decl for the opaque type. To turn this back into a reference
to the right decl's implicit OpaqueTypeDecl, use type reconstruction. Since type reconstruction
doesn't normally concern itself with non-type decls, set up a lookup table in SourceFiles and
ModuleFiles to let us handle the mapping from mangled name to opaque type decl in type
reconstruction.
(Since we're invoking type reconstruction during type checking, when the module hasn't yet been
fully validated, we need to plumb a LazyResolver into the ASTBuilder in an unsightly way. Maybe
there's a better way to do this... Longer term, at least, this surface design gives space for
doing things more the right way--a more request-ified decl validator ought to be able to naturally
lazily service this request without the LazyResolver reference, and if type reconstruction in
the future learns how to reconstruct non-type decls, then the lookup tables can go away.)
DeclAttributes::getUnavailable() only cares about attributes which make a declaration definitely unavailable, but you sometimes need a version which will also return a potentially unavailable (i.e. “introduced:”) attribute. This adds that.
<rdar://problem/46548531> Extend @available to support PackageDescription
This introduces a new private availability kind "_PackageDescription" to
allow availability testing by an arbitary version that can be passed
using a new command-line flag "-swiftpm-manifest-version". The semantics
are exactly same as Swift version specific availability. In longer term,
it maybe possible to remove this enhancement once there is
a language-level availability support for 3rd party libraries.
Motivation:
Swift packages are configured using a Package.swift manifest file. The
manifest file uses a library called PackageDescription, which contains
various settings that can be configured for a package. The new additions
in the PackageDescription APIs are gated behind a "tools version" that
every manifest must declare. This means, packages don't automatically
get access to the new APIs. They need to update their declared tools
version in order to use the new API. This is basically similar to the
minimum deployment target version we have for our OSes.
This gating is important for allowing packages to maintain backwards
compatibility. SwiftPM currently checks for API usages at runtime in
order to implement this gating. This works reasonably well but can lead
to a poor experience with features like code-completion and module
interface generation in IDEs and editors (that use sourcekit-lsp) as
SwiftPM has no control over these features.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
A module compiled with `-enable-private-imports` allows other modules to
import private declarations if the importing source file uses an
``@_private(from: "SourceFile.swift") import statement.
rdar://29318654
Dynamic replacements are currently written in extensions as
extension ExtendedType {
@_dynamicReplacement(for: replacedFun())
func replacement() { }
}
The runtime implementation allows an implementation in the future where
dynamic replacements are gather in a scope and can be dynamically
enabled and disabled.
For example:
dynamic_extension_scope CollectionOfReplacements {
extension ExtentedType {
func replacedFun() {}
}
extension ExtentedType2 {
func replacedFun() {}
}
}
CollectionOfReplacements.enable()
CollectionOfReplacements.disable()
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
LLVM r334399 (and related Clang changes) moved clang::VersionTuple to
llvm::VersionTuple. Update Swift to match.
Patch by Jason Molenda.
rdar://problem/41025046
1) Formalize "OnAccessor". A hack used to alias this to "OnFunc".
2) New aggregates: OnNominalType, OnGenericType, OnAbstractFunction.
3) Consistent and self-documented (albeit custom) style to ease code review/audits.
4) Removes a few cases of `OnAccessor` based on pull request #16031 feedback.
* Implement #warning and #error
* Fix #warning/#error in switch statements
* Fix AST printing for #warning/#error
* Add to test case
* Add extra handling to ParseDeclPoundDiagnostic
* fix dumping
* Consume the right paren even in the failure case
* Diagnose extra tokens on the same line after a diagnostic directive
...rather than the ad hoc CustomTypeNameManglingAttr I was using
before. As John pointed out, the AST should be semantic wherever
possible.
We may someday want to get out of this being an attribute altogether,
or duplicating information that's available in the original Clang
node, by actually storing a reference to that node somewhere. This is
tricky and mixed up with deciding what hasClangNode() or
getClangDecl() would mean, though, so for now the attribute just
carries the information we need.
(and 'La'...'Lj')
Use this for the synthesized structs for error enums, as described in
the previous commit, instead of reusing the "private discriminator"
feature. I left some space in the APIs for "related entity kinds" that
are longer than a single character, but I don't actually expect to use
it any time soon. It's mostly just easier to deal with StringRef than
with a bare char.
Note that this doesn't perfectly round-trip to the old mangling; I had
it treat these nodes as private discriminators with a prefixed "$"
instead. We don't depend on that for anything, though.
When importing a C enum with the ns_error_domain attribute, we
synthesize a struct containing an NSError object to represent errors
in that domain. That synthesized struct should have a mangled name
that ties it to the original C enum, if we want it to be stable, and
now it does.
Before: $SSC7MyErrorV (a normal struct, which is a lie)
After: $SSC11MyErrorCode13ns_error_enumLLV
kind=Global
kind=Structure
kind=Module, text="__C_Synthesized"
kind=PrivateDeclName
kind=Identifier, text="ns_error_enum"
kind=Identifier, text="MyErrorCode"
Using the "private discriminator" feature allows us to pack in extra
information about the declaration without changing the mangling
grammar, and without stepping on anything the importer is using.
More rdar://problem/24688918
This has three principal advantages:
- It gives some additional type-safety when working
with known accessors.
- It makes it significantly easier to test whether a declaration
is an accessor and encourages the use of a common idiom.
- It saves a small amount of memory in both FuncDecl and its
serialized form.
For now these are underscored attributes, i.e. compiler internal attributes:
@_optimize(speed)
@_optimize(size)
@_optimize(none)
Those attributes override the command-line specified optimization mode for a specific function.
The @_optimize(none) attribute is equivalent to the already existing @_semantics("optimize.sil.never") attribute
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
Rename AccessibilityAttr to AccessControlAttr and
SetterAccessibilityAttr to SetterAccessAttr, then track down the last
few uses of "accessibility" that don't have to do with
NSAccessibility. (I left the SourceKit XPC API alone because that's
supposed to be more stable.)
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
This commit changes the 'Accessibility' enum to be named 'AccessLevel'.
Inheritance of a protocol from JavaScriptCore's JSExport protocol is
used to indicate that the methods and properties of that protocol
should be exported to JavaScript. The actual check to determine
whether a protocol (directly) inherits JSExport is performed via the
Objective-C runtime. Note that the presence of JSExport in the
protocol hierarchy is not sufficient; the protocol must directly
inherit JSExport.
Swift warns about redundant conformance requirements and eliminates
them from the requirement signature (and, therefore, the Objective-C
metadata). This behavior is incorrect for JSExport, because the
conformance is actually needed for this API to work properly.
Recognize a protocol's inheritance JSExport specifically (by
name) when computing the requirement signature of the protocol. When
we find such a redundancy, suppress the "redundant conformance
constraint" diagnostic and add a new (hidden) attribute
@_restatedObjCConformance(proto). The attribute is used only by Objective-C
protocol metadata emission to ensure that we get the expected metadata
in the Objective-C runtime.
Fixes rdar://problem/32674145.
Using these in declaration position has been deprecated and
removed in Swift 3. These attributes were not being parsed and
contained deadweight diagnostics that should have been moved
when these attributes became type attributes.
This is accomplished by recognizing this specific situation and
replacing the 'objc' attribute with a hidden '_objcRuntimeName'
attribute. This /only/ applies to classes that are themselves
non-generic (including any enclosing generic context) but that have
generic ancestry, and thus cannot be exposed directly to Objective-C.
This commit also eliminates '@NSKeyedArchiverClassName'. It was
decided that the distinction between '@NSKeyedArchiverClassName' and
'@objc' was too subtle to be worth explaining to developers, and that
any case where you'd use '@NSKeyedArchiverClassName' was already a
place where the ObjC name wasn't visible at compile time.
This commit does not update diagnostics to reflect this change; we're
going to change them anyway.
rdar://problem/32414557
As such, we no longer insert two placeholders for initializers that
need two vtable slots; instead we record that in the
MissingMemberDecl. I can see MissingMemberDecl growing to be something
we'd actually show to users, that can be used for other kinds of
declarations that don't have vtable entries, but for now I'm not going
to worry about any of that.
Replace `NameOfType foo = dyn_cast<NameOfType>(bar)` with DRY version `auto foo = dyn_cast<NameOfType>(bar)`.
The DRY auto version is by far the dominant form already used in the repo, so this PR merely brings the exceptional cases (redundant repetition form) in line with the dominant form (auto form).
See the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es11-use-auto-to-avoid-redundant-repetition-of-type-names) for a general discussion on why to use `auto` to avoid redundant repetition of type names.
This attribute allows one to provide the "legacy" name of a class for
the purposes of archival (via NSCoding). At the moment, it is only
useful for suppressing the warnings/errors about classes with unstable
archiving names.
When in Swift 3 compatibility mode without
`-warn-swift3-objc-inference`, warn on the *uses* of declarations that
depend on the Objective-C runtime that became `@objc` due to the
deprecated inference rule. This far more directly captures important
uses of the deprecated Objective-C entrypoints. We diagnose:
* `#selector` expressions that refer to one of these `@objc` members
* `#keyPath` expressions that refer to one of these `@objc` members
* Dynamic lookup (i.e., member access via `AnyObject`) that refers to
one of these `@objc` members.
If this had a default, it should be the effective language version,
not the compiler language version. That is, in the Swift 4 compiler's
Swift 3 mode, we want to be acting like Swift 3, not Swift 4.
Store leading a trailing "trivia" around a token, such as whitespace,
comments, doc comments, and escaping backticks. These are syntactically
important for preserving formatting when printing ASTs but don't
semantically affect the program.
Tokens take all trailing trivia up to, but not including, the next
newline. This is important to maintain checks that statements without
semicolon separators start on a new line, among other things.
Trivia are now data attached to the ends of tokens, not tokens
themselves.
Create a new Syntax sublibrary for upcoming immutable, persistent,
thread-safe ASTs, which will contain only the syntactic information
about source structure, as well as for generating new source code, and
structural editing. Proactively move swift::Token into there.
Since this patch is getting a bit large, a token fuzzer which checks
for round-trip equivlence with the workflow:
fuzzer => token stream => file1
=> Lexer => token stream => file 2 => diff(file1, file2)
Will arrive in a subsequent commit.
This patch does not change the grammar.
