Checked what it would look like to verify fix-its in every case, and
currently the tests are missing expected fix-its in 435 diagnoses in 60
test files.
So as an alternative, added support for a no fix-its marker “{{none}}”, and
added that marker to the c-style for deprecation tests where it applies.
This includes a few changes:
- Enhance diagnoseGeneralConversionFailure to not ignore constraints that are fully solved by
CSDiags' heuristics.
- Enhance dictionary/array literals diagnostics to handle non-compliance to their literal
protocols with a specific and custom error message.
- Add specific QoI for turning accidental use of array literals in dictionary context into
the right dictionary syntax (with a fixit).
Swift SVN r31696
ConstraintSystem::applySolution into its own helper function to reduce
indentation and make ConstraintSystem::applySolution much more simple
and obvious. NFC.
Swift SVN r31290
allowing these failures to hook into other diagnostic goodies (e.g. the
"did you mean to use '!' or '?'?" cases showing in the testsuite). That said,
by itself this doesn't have a huge impact, but avoids regressions with other
pending changes.
Swift SVN r31289
produce specific diagnostics about individual elements being incorrect instead of
complaining about the whole thing in aggregate.
This improves diagnostics immediately, but is also important to unblock future progress.
Swift SVN r31264
could lead to an "overlapping diagnostics" assertion because
two fixits were zapping whitespace. NFC, since noone except me
uses this.
Swift SVN r30929
other constraints intentionally ripped off, tell the recursive solution that
we can tolerate an ambiguous result. The point of this walk is not to
produce a concrete type for the subexpression, it is to expose any structural
errors within that subsystem that don't depend on the contextual constraints.
Swift SVN r30917
- 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
