…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
Rather than crashing when a generic signature is found to be non-minimal,
report the non-minimal requirement via the normal diagnostics machinery so
we can properly test for it.
Fixes rdar://problem/36912347 by letting us track which cases are
non-minimal in the standard library explicitly, so we can better
decide whether it's worth implementing a complete solution.
This makes it possible to look up the execution count corresponding to
an ASTNode through SILGenFunction. The profile reader itself is stored
in a SILGenModule: this doesn't seem like the best place for it, so
suggestions for improvement are welcome!
Next, we'll actually attach this data to SIL objects and pass it all
down to IRGen.
Adjust the definition of some diagnostics that are already called with
DeclBaseNames so that the implicit conversion from DeclBaseName to
Identifier is no longer needed.
Adjust the call side of diagnostics which don't have to deal with
special names to pass an Identifier to the diagnostic.
Diagnostic categories are entirely unused and arguably useless as
implemented, as they merely denote the sub-component of the
compiler.
As far as categorizing warnings are concerned, I'm abandoning the
effort for now, as the utility is marginal and Swift and the Swift
compiler are probalby not ready for these to be nailed down. For the
sake of cleanliness, the CATEGORY field is also stripped from
WARNINGS.
If there's a need for automatic identifying of compiler sub-components
for diagnstics in the future, there are better ways to do this.
NFC
1. Array type parsing for postfix array types Int[]. We now handle this
in the parser, but remove the AST representation of this old form. We
also stop making vague promises about the future by saying that "fixed
size arrays aren't supported... yet". Removal of this fixes a compiler
crasher too.
2. Remove the special case support for migrating @autoclosure from types
to parameters, which was Swift 1.0/1.1 syntax. The world has moved or
we don't care anymore.
3. Remove upgrade support for # arguments (nee "backtick" arguments), which
was a Swift 1.x'ism abolished in an effort to simplify method naming
rules.
NFC on valid code.
We should also eliminate the isOldSyntax as well, and just do the
error recovery in the parser (there is no need to retain the sugar here
anymore), but I'll do that as a separate change since it could be behavior
changing.
a 'var' modifier on the parameter, e.g.:
x.swift:44:5: error: cannot assign to 'let' value 'a'
a = 1
~ ^
x.swift:43:8: note: change 'let' parameter to 'var' to make it mutable
func f(let a : Int) {
^~~
var
x.swift:48:5: error: cannot assign to 'let' value 'b'
b = 2
~ ^
x.swift:47:8: note: mark parameter with 'var' to make it mutable
func g(b : Int) {
^
var
Also fix a bug where we'd incorrectly suggesting adding 'mutating' to a class
method when assigning to self in some cases.
Swift SVN r28926
- <rdar://problem/16306600> QoI: passing a 'let' value as an inout results in an unfriendly diagnostic
- <rdar://problem/16927246> provide a fixit to change "let" to "var" if needing to mutate a variable
We now refer to an inout argument as such, e.g.:
t.swift:7:9: error: cannot pass 'let' value 'a' as inout argument
swap(&a, &b)
^
we also produce a note with a fixit to rewrite let->var in trivial cases where mutation is
being assed for, e.g.:
t.swift:3:3: note: change 'let' to 'var' to make it mutable
let a = 42
^~~
var
The note is produced by both Sema and DI.
Swift SVN r27774
The previous commit enabled this; now it's just about removing the
restriction in the parser and tightening up code completion.
Using 'super' in a closure where 'self' is captured weak or unowned still
doesn't work; the reference to 'self' within the closure is treated as
strong regardless of how it's declared. Fixing this requires a cascade of
effort, so instead I just cloned rdar://problem/19755221.
rdar://problem/14883824
Swift SVN r25065
rdar://problem/17198298
- Allow 'static' in protocol property and func requirements, but not 'class'.
- Allow 'static' methods in classes - they are 'class final'.
- Only allow 'class' methods in classes (or extensions of classes)
- Remove now unneeded diagnostics related to finding 'static' in previously banned places.
- Update relevant diagnostics to make the new rules clear.
Swift SVN r24260
eliminating the @'s from them when used on func's. This is progress towards
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
This also consolidates rejection of custom operator definitions into one
place and makes it consistent, and adds postfix "?" to the list of rejected
operators.
This also changes the demangler to demangle weak/inout/postfix and related things
without the @.
Swift SVN r19929
