It is apparently a common mistake for beginners to start the names of functions
etc. with numbers, and before this patch the diagnostic wasn't specific about
the problem. It seems likely that most instances of `func 1(...` will be
mistakes in this vein, so this patch specifically diagnoses that case, and also
parses the number as the identifier to avoid follow on errors about top-level
closures (from the {}) and other invalid syntax.
Fixes rdar://problem/32316666 .
- A mutating method or accessor always has 'inout self'.
- A nonmutating method or accessor never has 'inout self'.
- Only instance members can be mutating.
- Addressors are still addressors even when on static members.
Came up after reviewing another patch that confused the two as
possibly distinct concepts.
Push the getName method from ValueDecl down to only those types that are
guaranteed to have a name that is backed by an identifier and that will
not be special.
Maintain inner most string literal mode to determine whether we allow
newline character or not.
* Disallow newline after multiline string in string interpolation. (SR-5171)
* Allow unbalanced `"` in multiline string in string interpolation.
This time, the warnings only fire when the class in question directly
conforms to NSCoding. This avoids warning on cases where the user has
subclassed something like, oh, UIViewController, and has no intention
of writing it to a persistent file.
This also removes the warning for generic classes that conform to
NSCoding, for simplicity's sake. That means
'@NSKeyedArchiverEncodeNonGenericSubclassesOnly' is also being
removed.
Actually archiving a class with an unstable mangled name is still
considered problematic, but the compiler shouldn't emit diagnostics
unless it can be sure they are relevant.
rdar://problem/32314195
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
* [Parse] Refactored internal structure of Tokens.def and documented usage.
Added a level of structure to the macro definitions to allow Swift
keywords to be cleanly accessed separately from SIL and Swift keywords
together. Documented structure and usage.
* [Parse] Made use of new guarantees and abstractions in Tokens.def
Used guarantees about undefining macros after import and new
SWIFT_KEYWORD abstraction to simplify usage of the Token.def
imports.
* Gardening
With the introduction of special decl names, `Identifier getName()` on
`ValueDecl` will be removed and pushed down to nominal declarations
whose name is guaranteed not to be special. Prepare for this by calling
to `DeclBaseName getBaseName()` instead where appropriate.
This changes `getBaseName()` on `DeclName` to return a `DeclBaseName`
instead of an `Identifier`. All places that will continue to be
expecting an `Identifier` are changed to call `getBaseIdentifier` which
will later assert that the `DeclName` is actually backed by an
identifier and not a special name.
For transitional purposes, a conversion operator from `DeclBaseName` to
`Identifier` has been added that will be removed again once migration
to DeclBaseName has been completed in other parts of the compiler.
Unify approach to printing declaration names
Printing a declaration's name using `<<` and `getBaseName()` is be
independent of the return type of `getBaseName()` which will change in
the future from `Identifier` to `DeclBaseName`
Now that preCheckExpression() can handle more cases, we can
eliminate a special case where sometimes we would make
DeclRefExprs instead of TypeExprs for references to generic
types.
Generic type specialization is ambiguous with < and > operators.
Extend the disambiguation hack to also consider parsing a generic
parameter list if the > is followed by &.
This fixes parsing types such as 'Base<Int> & P' in expression
context.
Resolves: https://bugs.swift.org/browse/SR-4426
* Make IfConfigDecl be able to hold ASTNodes
* Parse #if as IfConfigDecl
* Stop enclosing toplevel #if into TopLevelCodeDecl.
* Eliminate IfConfigStmt
This is a bit more robust and user-friendly than hoping more brittle recovery in SILGen or IRGen for unsupported components kicks in. rdar://problem/32200714
This fixes a syntax coloring issue when only the innermost " character were highlighted as part of the string, e.g:
""<str>"
This is a string
"</str>""
This doesn't give particularly useful information yet (i.e. Self isn't
listed, see rdar://problem/31981641 ), but it does stop the completion
code from just directly crashing.
Fixes rdar://problem/31981486.
Till now createApply, createTryApply, createPartialApply were taking some arguments like SubstCalleeType or ResultType. But these arguments are redundant and can be easily derived from other arguments of these functions. There is no need to put the burden of their computation on the clients of these APIs.
The removal of these redundant parameters simplifies the APIs and reduces the possibility of providing mismatched types by clients, which often happened in the past.
All we need to store is whether the SILDeclRef directly
references the declaration, or if it references a curry
thunk, and we already have an isCurried bit for that.
Swift 3 supported limited argument destructuring when it comes to
declaring (trailing) closures. Such behavior has been changed by
SE-0110. This patch aims to provide better error message as well
as fix-it (if structure of the expected and actual arguments matches)
to make the migration easier and disambiguate some of the common
mistakes.
Resolves: SR-4738, SR-4745, rdar://problem/31892961.
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.
