When performing a binding/assignment to a weak or unowned variable/property from an initialiser call, emit a warning that the instance will be immediately deallocated.
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
Rename AccessibilityAttr to AccessControlAttr and
SetterAccessibilityAttr to SetterAccessAttr, then track down the last
few uses of "accessibility" that don't have to do with
NSAccessibility. (I left the SourceKit XPC API alone because that's
supposed to be more stable.)
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
This commit changes the 'Accessibility' enum to be named 'AccessLevel'.
The protocol conformance checker tries to delay the emission of
diagnostics related to the failure of a type to conform to a protocol
until the source file that contains the conformance is encountered, to
provide redundant diagnostics. However, if a file produced only such
delayed diagnostics, such that all diagnostics were suppressed,
invalid ASTs could slip through to later stages in the pipeline where
they would cause verification errors and crashes. This happens
generally with whole-module-optimization builds, where we are re-using
an ASTContext when typing multiple source files.
This is a narrow-ish fix to stop dropping diagnostics from one source
file to the next in whole-module-optimization builds. Part of
rdar://problem/29689007.
1. Add new AccessScope type that just wraps a plain DeclContext.
2. Propagate it into all uses of "ValueDecl::getFormalAccessScope".
3. Turn all operations that combine access scopes into methods on AccessScope.
4. Add the "private" flag to distinguish "private" from "fileprivate"
scope for top-level DeclContext.
This time, propagate the decl marked deprecated or unavailable through
to the fix-it, so we can be sure it's a var.
https://bugs.swift.org/browse/SR-1649
...rather than relying on the access-as-spelled, which may be greater
than the effective access due to parent scopes.
(Some of this will get cleaned up with SR-2209.)
rdar://problem/27663492
This is the protocol version of 7bfdd4a2: if a protocol requirement
has a newly-bridged type (say, 'URL' instead of 'NSURL'), then any
conforming types will need to update their implementations of the
requirement. Reuse the override-checking mechanism to do so when
we're reasonably confident about it.
This slots the checking into the existing protocol diagnostics, which
doesn't result in the best user experience.
note: protocol requires property 'prop' with type 'Refrigerator?'
var prop: Refrigerator? { get }
^
note: candidate has non-matching type 'APPRefrigerator?'
var prop: APPRefrigerator? {
^ ~~~~~~~~~~~~~~~~
Refrigerator?
But we can come back and improve that later; right now this is better
than nothing.
rdar://problem/26237030
...or renaming to operators, unless we're sure the original thing was
an operator expression. There are just a lot of ways this can be
screwed up.
(Some cases of this can certainly be implemented. I may file a
StarterBug later.)
This reorganization allows adding attributes that refer to types.
I need this for a @_specialize attribute with a type list.
PrintOptions.h and other headers depend on these enums. But Attr.h
defines a lot of classes that almost never need to be included.
avoid emitting this diagnostics. They are always irritating to it because they
are duplicative with whatever the actual type constraint problem is. It also
interferes with there recursive structure of the problem.
Disabling them also allows us to shorten the black list of expr nodes that cannot
be handled in typeCheckIndependentSubExpression.
Swift SVN r30122
<rdar://problem/15975935> warning that you can use 'let' not 'var'
<rdar://problem/18876585> Compiler should warn me if I set a parameter as 'var' but never modify it
<rdar://problem/17224539> QoI: warn about unused variables
This uses a simple pass in MiscDiagnostics that walks the body of an
AbstractFunctionDecl. This means that it doesn't warn about unused properties (etc),
but it captures a vast majority of the cases.
It also does not warn about unused parameters (as a policy decision) because it is too noisy,
there are a variety of other refinements that could be done as well, thoughts welcome.
Swift SVN r28412
There's no meaningful way in which these methods are public, since they
can't be accessed through any value of the type
<rdar://problem/17647878>
Swift SVN r20224
We still want to allow line wrapping, so only issue the warning when the indentation of the expression and the return keyword is the same.
radar://11945406
Swift SVN r9984
rdar://14151649 suggests that it should be a warning, but I don’t see a reason
why it should not be an error. We have no legacy code that relies on this.
Swift SVN r9976
