- Produce more specific diagnostics relating to different kinds of invalid
- add a testcase, nfc
- Reimplement FailureDiagnosis::diagnoseGeneralMemberFailure in terms of
Not including r30787 means that we still generate bogus diagnostics like:
[1, 2, 3].doesntExist(0) // expected-error {{type 'Int2048' does not conform to protocol 'IntegerLiteralConvertible'}}
But it is an existing and separable problem from the issues addressed here.
Swift SVN r30819
member references:
- Use of instance members from types
- Use of type members from instances
- Use of mutating getters.
This surely resolves some radars, but I'll have to dig them out later.
Swift SVN r30796
version of the new CTP_ReturnStmt conversion, used to generate return-specific
diagnostics. Now that we have a general solution, we can just use that.
This improves diagnostics in returns for accessors, since they were apparently
not getting the bit set.
Swift SVN r30665
e.g.:
/Users/sabre/Projects/swiftsource/swift/test/Constraints/existential_metatypes.swift:17:28: error: incorrect message found
pp = pt // expected-error{{cannot assign a value of type 'P.Type' to a value of type 'P.Protocol'}}
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
'P.Type' is not convertible to 'P.Protocol'
Swift SVN r30626
/Users/sabre/Projects/swiftsource/swift/test/Constraints/errortype_bridging.swift:37:7: error: unexpected error produced: 'protocol<HairyErrorType, Runcible>' is not convertible to 'NSError'
ns4 = compo // expected-error{{cannot assign a value of type 'protocol<HairyErrorType, Runcible>' to a value of type 'NSError'}}
^
/Users/sabre/Projects/swiftsource/swift/test/Constraints/errortype_bridging.swift:37:16: error: expected error not produced
ns4 = compo // expected-error{{cannot assign a value of type 'protocol<HairyErrorType, Runcible>' to a value of type 'NSError'}}
^
produce a single message like:
/Users/sabre/Projects/swiftsource/swift/test/Constraints/errortype_bridging.swift:37:16: error: error had incorrect message: 'protocol<HairyErrorType, Runcible>' is not convertible to 'NSError'
ns4 = compo // expected-error{{cannot assign a value of type 'protocol<HairyErrorType, Runcible>' to a value of type 'NSError'}}
^
Swift SVN r30623
Allow API providers to use escaped characters in the messages of @available()
attributes. For example, for a reference to a declaration annotated with:
@available(*, unavailable, message="use print(\"\")")
public func println() {
...
}
the message displayed to the user will be:
'println() is unavailable: use print("")'.
This also supports unicode escapes (e.g. \u{1F43C}).
A complication is that AvailableAttrs imported from clang already have their
messages unescaped, so this patch keeps track of whether an availability
attribute came from clang and, if so, does not unescape the message again when
emitting the diagnostic. We could avoid this extra book-keeping by immediately
unescaping Swift messages during parsing, keeping them in an unescaped
canonical form, and then escaping them in ASTPrinter when we print the
attributes. rdar://problem/20985357 tracks keeping AvailableAttrs messages in
a canonical form.
rdar://problem/20789407
Swift SVN r28658
expectations. Instead of saying "unexpected diagnostic not produced" and
"expected diagnostic not produced", instead say "unexpected *warning* not produced".
This helps in particular when you have an expectation for a warning but got an
error with the same wording (for example).
Swift SVN r26149
When a subclass is missing a required initializer, produce an error
within the subclass that mentions the required initializer along with
a Fix-It that provides an initializer stub, e.g.,
required init(coder aDecoder: NSCoder!) {
fatalError("init(coder:) has not been implemented")
}
We take care to insert this stub in the main class, after all of the
initializers (if there are any) or near the beginning of the class (if
there aren't any initializers), and try to match the existing
indentation. If this works out, we should handle unsatisfied protocol
requirements the same way. <rdar://problem/17923210>
Swift SVN r21055
This is a hack to work around two issues:
- <iso646.h>, which defines macros for "and", "or", and "not" (among other
things) is an implicit submodule of Darwin.
- Macros even in explicit submodules are leaking out when the parent module
is imported <rdar://problem/14870036>.
There's no actual reason to require <iso646.h> in SDK header files -- it
should be a user-level choice whether or not to use those names. And
selectors with "and", "or", and "not" in them should not be mangled by this.
So, as a hack, we define the header guards that <iso646.h> uses ahead of
time, so that the file will be ignored. We do this for /both/ variants of
<iso646.h> on our system (Clang's and /usr/include's) just to be safe.
<rdar://problem/17110619>
Swift SVN r19822
...in preparation for non-source locations, i.e. locations that don't come
frome source buffers.
No functionality change, but a fair bit of SourceManager API and idioms have
changed.
Swift SVN r18942
integration
Motivation: libIDE clients should be simple, and they should not have to
translate token-based SourceRanges to character locations.
This also allows us to remove the dependency of DiagnosticConsumer on the
Lexer. Now the DiagnosticEngine translates the diagnostics to CharSourceRanges
and passes character-based ranges to the DiagnosticConsumer.
Swift SVN r7173
