Commit Graph

59 Commits

Author SHA1 Message Date
Chris Lattner
1a0a0315fe wordsmith a diagnostic, NFC otherwise.
Swift SVN r30731
2015-07-28 23:35:25 +00:00
Chris Lattner
ede0c50856 Revamp how value & type member constraint failures are diagnosed, eliminating the
"unavoidable failure" path, along with Failure::DoesNotHaveNonMutatingMember and
just doing some basic disambiguation in CSDiags.

This provides some benefits:
 - Allows us to plug in much more specific diagnostics for the existing "only has 
   mutating members" diagnostic, including producing notes for why the base expr
   isn't mutable (see e.g. test/Sema/immutability.swift diffs).
 - Corrects issues where we'd drop full decl name info for selector references.
 - Wordsmiths diagnostics to not complain about "values of type Foo.Type" instead 
   complaining about "type Foo"
 - Where before we would diagnose all failures with "has no member named", we now
   distinguish between when there is no member, and when you can't use it.  When you
   can't use it, you get a vauge "cannot use it" diagnostic, but...
 - This provides an infrastructure for diagnosing other kinds of problems (e.g. 
   trying to use a private member or a static member from an instance).
 - Improves a number of cases where failed type member constraints would produce uglier
   diagnostics than a different constraint failure would.
 - Resolves a number of rdars, e.g. (and probably others):
   <rdar://problem/20294245> QoI: Error message mentions value rather than key for subscript



Swift SVN r30715
2015-07-28 07:04:22 +00:00
Chris Lattner
922a7f53b3 consolidate the diagnostics produced by the "Failure" case and the expr walker in CSDiags to
get the same wording, fixing <rdar://problem/21964599> Different diagnostics for the same issue

While I'm in the area, remove some dead code.



Swift SVN r30713
2015-07-28 04:43:37 +00:00
Chris Lattner
06cc05daa9 reword a diagnostic, as suggested by Jordan
Swift SVN r30712
2015-07-28 04:03:25 +00:00
Slava Pestov
5cc4f2b93d Sema: Use isTypeChecking() to avoid recursively validating EnumElementDecls
Validating the argument type might validate the enum decl in malformed (or
maybe even some valid?) code. We would call computeTwice() in this case,
leading to a crash.

Also clean up some test cases.

Swift SVN r30673
2015-07-27 00:40:37 +00:00
Dmitri Hrybenko
6b00e2a0fd objc_enum_errortype.swift test requires ObjC runtime
Swift SVN r28819
2015-05-20 03:20:06 +00:00
Doug Gregor
74050648de Make @objc enums that conform to ErrorType also conform to _ObjectiveCBridgeableErrorType.
This allows @objc enum error types produced in Objective-C (e.g., via
+[NSError errorWithDomain:code:userInfo:]) to be bridged back to their
original enum types in Swift via pattern matching/catch blocks.

This finishes rdar://problem/20577517.

Swift SVN r28803
2015-05-20 00:16:39 +00:00
Dmitri Hrybenko
f46f16ae82 stdlib: implement new print() API
rdar://20775683

Swift SVN r28309
2015-05-08 01:37:59 +00:00
Jordan Rose
12c80f4a3a Check the raw values of an @objc enum eagerly during decl validation.
For @objc enums, raw values determine the representation values, so we have
to compute them eagerly in order for switch statements to work. Similarly,
if the enum is broken, we have to /fail/ eagerly so that we don't fall down
later on in IRGen.

rdar://problem/19775284

Swift SVN r25282
2015-02-13 20:31:43 +00:00