Stop suggesting Fix-Its to add @available() to stored properties. We don't allow this
yet, so the "fixed" code would still emit an error when compiled.
rdar://problem/20939804
Swift SVN r28604
This came out of today's language review meeting.
The intent is to match #available with the attribute
that describes availability.
This is a divergence from Objective-C.
Swift SVN r28484
In source files that are in script mode, global variable initialization
expressions are eagerly executed. For this reason, disallow @availability
attributes having 'introduced=' on script-mode globals.
I had to rejigger a fair number of potential unavailability tests because they
weren't written with this distinction in mind.
Swift SVN r27137
Provide compiler-synthesized implementations of ErrorType that use the type name as domain and a per-case integer as code. (TBD would be some mapping of the associated data to userInfo in Cocoa.)
Swift SVN r26780
Change availability Fix-It notes to use a DescriptiveDeclKind so that the notes are
more precise in their description of where an availability attribute will be added.
So, for example, the note will now say "add @availability attribute to enclosing class"
instead of "add @availability attribute to enclosing type".
In these Fix-Its, I have special-cased the descriptive kind for PatternBindingDecls to
instead use the description for an associated VarDecl to avoid describing property
declarations as "pattern bindings" to the user.
Swift SVN r26420
Minor tweaks to availability diagnostic text based on feedback from Chris, Ted, and Doug.
This changees "'foo' is only available on OS X version 10.10 or greater" to
"'foo' is only available on OS X 10.10 or newer".
This change also updates the deprecation and obsoleted diagnostics to be consistent with
the new text.
Swift SVN r26344
We now suggest up to three Fix-Its for each reference to a potentially
unavailable symbol: one to wrap the reference in an if #os(...) { ... }
guard (if possible), one to add an @availability attribute to an enclosing
property or method (if possible), and one to add an @availability attribute
to an enclosing class/struct/extension, etc. or global function.
The goal here is not to infer the "best" Fix-It but rather to ensure
discoverability of #os() and @availability attributes. We want the user, when
faced with an availability diagnostic, to be aware of the tools in her toolbox
to deal with it.
This is still missing QoI improvements, including Fix-Its to update
existing @availability attributes and more precise wording in diagnostics
(e.g, "initializer" instead of function, "class" instead of "type"). These
improvements will come in later commits.
Swift SVN r26073
Resolving signatures of declarations from files other than the primary source
file causes first-pass type checking, including diagnostics for potential
unavailability, to be performed on those declarations. Prior to this commit, the
type refinement context hierarchy was only constructed for the primary file, so
spurious errors were emitted when checking declarations in other files. With
this commit, the availability checker builds the hierarchy for a source file the
first time its hierarchy is queried. We will eventually want to build the
hierarchy more lazily, but that will come later.
Swift SVN r25746
This condition is already checked from defineDefaultConstructor's only caller,
addImplicitConstructors, and the two conditions had drifted. This was causing
issues in the multi-file case, where the optionals hadn't been given an
explicit initial value yet.
rdar://problem/18716572
Swift SVN r23017
Redefine the RawRepresentable protocol to use an 'init?' method instead of 'fromRaw(Raw)', and a 'raw' get-only property instead of 'toRaw()'. Update the compiler to support deriving conformances for enums and option sets with the new protocol. rdar://problem/18216832
Swift SVN r21762
If either parameter to == has a known concrete type at constraint generation
time, see if that type is a nominal that can derive its conformance to
Equatable. If so, do so, and then add that == to the overload set.
(It may already be there, but that's okay -- it will get uniqued later.)
This isn't perfect because it relies on one of the parameters to == having
a concrete type /before/ constraint solving. There are plenty of reasons
why that wouldn't happen. But this at least fixes the common case, and
breaking the expression up into multiple lines is a less distasteful
workaround than replacing (x == .Value) with !(x != .Value). I've added a
test case that should work but doesn't that we can revisit later.
rdar://problem/18073705
Swift SVN r21557
In most cases this means adding @public to things that get serialized;
in a few cases it means using a modern public stdlib API instead of
a legacy thing I was trying to keep @internal.
Swift SVN r19350
These types are often useless and confusing to users who expect to be able to use Sequence or Generator as types in their own right like in C# or Java. While we're here, relax the rules for self-conformance to admit methods returning 'Self'. Covariant return types should not actually prevent a protocol type from conforming to itself, and the stdlib makes particular use of protocols with 'init' requirements which implicitly return Self.
Swift SVN r18989
Normally, protocol conformances are only checked for types and extensions
declared in the current file. However, for protocols that can derive their
conformances (like RawRepresentable), other files in the target might
expect to be able to use the protocol members (like toRaw), which aren't
written in the source. Force the derivation if this is the case.
Also, move the /other/ set of RawRepresentable tests from test/Parse to
test/Sema.
<rdar://problem/15936403>
Swift SVN r14162
