The `@derivative` attribute registers a function as a derivative of another
function-like declaration: a `func`, `init`, `subscript`, or `var` computed
property declaration.
The `@derivative` attribute also has an optional `wrt:` clause specifying the
parameters that are differentiated "with respect to", i.e. the differentiation
parameters. The differentiation parameters must conform to the `Differentiable`
protocol.
If the `wrt:` clause is unspecified, the differentiation parameters are inferred
to be all parameters that conform to `Differentiable`.
`@derivative` attribute type-checking verifies that the type of the derivative
function declaration is consistent with the type of the referenced original
declaration and the differentiation parameters.
The `@derivative` attribute is gated by the
`-enable-experimental-differentiable-programming` flag.
Resolves TF-829.
Replaces `ComponentIdentTypeRepr::getIdentifier()` and `getIdLoc()` with `getNameRef()` and `getNameLoc()`, which use `DeclName` and `DeclNameRef` respectively.
Swift classes cannot meaningfully conform to NSObjectProtocol.
Inheriting from NSObject is the appropriate fix, so suggest that.
Fixes rdar://problem/32543753.
In the past, this error was applied inconsistently, so diagnosing it
correctly is now a source-breaking change. Instead, diagnose it correctly,
but as a warning.
It was being used purely to get the name of the type context for a diagnostic
message. SourceKit's syntactic-only requests were hitting an assertion when
this diagnostic was triggered because they don't set up a type checker.
This warning is produced if you annotate an enum with `@frozen` but
build without library evolution enabled. The problem is that if you
only build with library evolution enabled for release builds, this
leaves you with a warning for all debug builds. The downside of this
change is that if you never build with library evolution, you may have
this unnecessary annotation without noticing.
Adds parsing for a type attribute `@differentiable`, which is optionally allowed to have argument `@differentiable(linear)`.
The typechecker currently rejects all uses of `@differentiable` with "error: attribute does not apply to type". Future work (https://bugs.swift.org/browse/TF-871https://bugs.swift.org/browse/TF-873) will update the typechecker to allow this attribute in places where it is allowed.
Resolves https://bugs.swift.org/browse/TF-822.
Diagnose ephemeral conversions that are passed to @_nonEphemeral
parameters. Currently, this defaults to a warning with a frontend flag
to upgrade to an error. Hopefully this will become an error by default
in a future language version.
This non-user-facing attribute is used to denote pointer parameters
which do not accept pointers produced from temporary pointer conversions
such as array-to-pointer, string-to-pointer, and in some cases
inout-to-pointer.
Convenience inits are only allowed on classes and in extensions thereof. And in CFTypes we are not allowed to put convenince inits since swift does not support this feature yet.
This PR solve the bad fix suggestion when a user declare a init method in an extension of CF Type.
Another bug (similar to this one) that i found and became visible when i was doing the test cases for SR-116779 was the fact that if you declare a convenience init that delegates the init function in self, a fix suggestion will appear. The same suggestion that is causing troubles in SR-11679. The fix for this was removing the fix suggestion when the class kind type was CFType since if we leave it as is, it will be the same problem as SR-11679.
SR-11679: PR Feedback
Formatting the new code with clang-format and using `isa` and `cast` instead of `dyn_cast`
SR-11679: PR Feedback
Inlining `cast
SR-11679: PR Feedback
Remove semi-colon
SR-11679: PR Feedback
Remove empty line & add mark to avoid fixit.
SR-11679: PR Feedback
Remove empty line.
SR-11679: PR Feedback
Move Diagnostics Info & Remove empty lines
