The properties of a context indicate those things that are considered
"contained within" the context (among other things). This helps us
avoid producing overly-generic names when we identify a redundancy in
the base name. For example, NSView contains the following:
var gestureRecognizers: [NSGestureRecognizer]
func addGestureRecognizer(gestureRecognizer: NSGestureRecognizer)
func removeGestureRecognizer(gestureRecognizer: NSGestureRecognizer)
Normally, omit-needless-words would prune the two method names down to
"add" and "remove", respectively, because they restate type
information. However, this pruning is not ideal, because a view isn't
primarily a collection of gesture recognizers.
Use the presence of the property "gestureRecognizers" to indicate that
we should not strip "gestureRecognizer" or "gestureRecognizers" from
the base names of methods within that class (or its subclasses).
Note that there is more work to do here to properly deal with API
evolution: a newly-added property shouldn't have any effect on
existing APIs. We should use availability information here, and only
consider properties introduced no later than the entity under
consideration.
When the first parameter of a function has Boolean type, try to create
an argument label for it. We start with the (normally non-API)
parameter name as the argument label, then try to match that against
the end of the base name of the method to eliminate redundancy. Add a
little magic, and here are some diffs:
- func openUntitledDocumentAndDisplay(_: Bool) throws -> NSDocument
+ func openUntitledDocument(display _: Bool) throws -> NSDocument
- func fontMenu(_: Bool) -> NSMenu?
- func fontPanel(_: Bool) -> NSFontPanel?
+ func fontMenu(create _: Bool) -> NSMenu?
+ func fontPanel(create _: Bool) -> NSFontPanel?
- func lockFocusFlipped(_: Bool)
+ func lockFocus(flipped _: Bool)
- func rectForSearchTextWhenCentered(_: Bool) -> NSRect
+ func rectForSearchText(whenCentered _: Bool) -> NSRect
- func dismissPreviewAnimated(_: Bool)
- func dismissMenuAnimated(_: Bool)
+ func dismissPreview(animated _: Bool)
+ func dismissMenu(animated _: Bool)
Swift SVN r32392
Extend GenericSignature to be able to answer queries about the
requirements placed on dependent types, e.g, are the class-bound, to
what protocols must they conform, etc. Implement this using a
lazily-created ArchetypeBuilder on the canonical generic signature.
NFC and as-yet-untested; this is staging for reducing our dependence
on the "all archetypes" list.
Swift SVN r32340
When completing at the sequence position of for each statment (for i in <HRER> {}),
values of sequence type should have higher priority than the rest.
Swift SVN r32202
Allow untyped placeholder to take arbitrary type, but default to Void.
Add _undefined<T>() function, which is like fatalError() but has
arbitrary return type. In playground mode, merely warn about outstanding
placeholders instead of erroring out, and transform placeholders into
calls to _undefined(). This way, code with outstanding placeholders will
only crash when it attempts to evaluate such placeholders.
<rdar://problem/21167372> transform EditorPlaceholderExpr into fatalError()
Swift SVN r31481
the regressions that r31105 introduced in the validation tests, as well as fixing a number
of other validation tests as well.
Introduce a new UnresolvedType to the type system, and have CSDiags start to use it
as a way to get more type information out of incorrect subexpressions. UnresolvedType
generally just propagates around the type system like a type variable:
- it magically conforms to all protocols
- it CSGens as an unconstrained type variable.
- it ASTPrints as _, just like a type variable.
The major difference is that UnresolvedType can be used outside the context of a
ConstraintSystem, which is useful for CSGen since it sets up several of them to
diagnose subexpressions w.r.t. their types.
For now, our use of this is extremely limited: when a closureexpr has no contextual
type available and its parameters are invalid, we wipe them out with UnresolvedType
(instead of the previous nulltype dance) to get ambiguities later on.
We also introduce a new FreeTypeVariableBinding::UnresolvedType approach for
constraint solving (and use this only in one place in CSDiags so far, to resolve
the callee of a CallExpr) which solves a system and rewrites any leftover type
variables as UnresolvedTypes. This allows us to get more precise information out,
for example, diagnosing:
func r22162441(lines: [String]) {
lines.map { line in line.fooBar() }
}
with: value of type 'String' has no member 'fooBar'
instead of: type of expression is ambiguous without more context
This improves a number of other diagnostics as well, but is just the infrastructural
stepping stone for greater things.
Swift SVN r31130
as a way to get more type information out of incorrect subexpressions. UnresolvedType
generally just propagates around the type system like a type variable:
- it magically conforms to all protocols
- it CSGens as an unconstrained type variable.
- it ASTPrints as _, just like a type variable.
The major difference is that UnresolvedType can be used outside the context of a
ConstraintSystem, which is useful for CSGen since it sets up several of them to
diagnose subexpressions w.r.t. their types.
For now, our use of this is extremely limited: when a closureexpr has no contextual
type available and its parameters are invalid, we wipe them out with UnresolvedType
(instead of the previous nulltype dance) to get ambiguities later on.
We also introduce a new FreeTypeVariableBinding::UnresolvedType approach for
constraint solving (and use this only in one place in CSDiags so far, to resolve
the callee of a CallExpr) which solves a system and rewrites any leftover type
variables as UnresolvedTypes. This allows us to get more precise information out,
for example, diagnosing:
func r22162441(lines: [String]) {
lines.map { line in line.fooBar() }
}
with: value of type 'String' has no member 'fooBar'
instead of: type of expression is ambiguous without more context
This improves a number of other diagnostics as well, but is just the infrastructural
stepping stone for greater things.
Swift SVN r31105
When a user invoke code completion after import keywords, the names of
visible top level clang modules were recommended for finishing the import decl.
(Undoing revert r30961 of r30957, which just required lockstep commit to
SourceKit -- cwillmore)
Swift SVN r30962
This reverts r30957 because it broke the following tests on Jenkins:
SourceKit :: CodeComplete/complete_open.swift
SourceKit :: CodeComplete/complete_test.swift
<rdar://problem/22120345> swift-incremental-RA #8289 failed to build
Swift SVN r30961
When a user invoke code completion after import keywords, the names of
visible top level clang modules were recommended for finishing the import decl.
Swift SVN r30957
Add getUIntDecl(), getFloatDecl() and getDoubleDecl(), change
getIntDecl() and getBoolDecl() to cache the result, and clean up
duplication. NFC
Progress on <rdar://problem/21215099>.
Swift SVN r29969
While the archetype builder is constructing archetypes, it eagerly
produces the set of nested archetypes for each archetype. If the
construction of any of those nested archetypes refers to another
archetype, we would fail unceremonerously with an assertion. Fill in
the nested type names (but not their actual types) eagerly, allowing
the actual types to be determined lazily.
This is plumbing for rdar://problem/21620908, which still trips an
unrelated assertion, preventing a useful testcase at this step.
Swift SVN r29841
This prevents us from seeing a less useful error message from SILGen
further down the line.
Also fix a bug where @objc without importing Foundation was not diagnosed
after the first top-level form. Some tests were relying on this behavior,
so fix those tests, either by splitting off the objc parts of the test, or
just by passing the -disable-objc-attr-requires-foundation-module flag.
Fixes <rdar://problem/20660270>.
Swift SVN r29359
I didn't add anything to the table, just made use of what was already there.
We have plenty of additional calls to getIdentifier that could probably benefit
from this kind of easy access as well.
This commit also removes FOUNDATION_MODULE_NAME and OBJC_MODULE_NAME from
Strings.h. Neither of these is likely to change in the future, and both
already have KnownIdentifiers equivalents in use.
No intended functionality change.
Swift SVN r29292
- Remove unused names.
- Define IDENTIFIER in terms of IDENTIFIER_WITH_NAME.
- Adjust each name to always match the corresponding value in case.
- Add an IDENTIFIER_ macro for the common case of defining an underscored name.
- Avoid creating names with double underscores, which are technically reserved
by the C++ standard.
There are two special cases I left in here for the identifiers '_code' and
'_domain'. I didn't want to call these simply 'Id_code' and 'Id_domain' for
fear someone would try to use them as 'code' and 'domain', so I made them into
'Id_code_' and 'Id_domain_' for now.
No intended functionality change.
Swift SVN r29291
This fixes a non-determinism during deserialization:
The constructor of SerializedSILLoader iterates over ASTContext::LoadedModules.
If a function is contained in multiple loaded modules, it was non deterministic which version was deserialized.
Fixes rdar://problem/20992687.
Swift SVN r28704
When a derived class specializes its base class, e.g. 'class Derived: Base<Int>', the natural abstraction levels of its methods may differ from the original base class's more abstract methods. Handle this by using the reabstraction machinery to thunk values when necessary. Merge the existing optionality thunking support into the reabstraction code, where witness thunking and similar convention adjustments may also be able to use it, if we desire. Fixes rdar://problem/19760292.
Swift SVN r28505
Reverts r28087. We're going back to the C++ interface for SIMD, and the changes in this patch are needless complication for that design.
Swift SVN r28384
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
Currently GenericSignature::getCanonicalSignature isn't able to canonicalize the set of requirements due to fragile dependencies on generic signatures matching AllArchetypes order of their originating GenericParamLists. However, we shouldn't let that stop us from getting the mangling right, so implement a "getCanonicalManglingSignature" that builds the true canonical signature by feeding it into an ArchetypeBuilder and shedding unnecessary constraints. For now, just handle conformance and base class constraints; still to do are same-type constraints.
Swift SVN r28191
The design we landed on for SIMD is to define the vector types as nested types of their element, e.g. Float.Vector4, Int32.Vector2, etc. Update the Clang importer and other mapping facilities to match.
Swift SVN r28087
Replace ReST-flavored documentation comments with Markdown.
rdar://problem/20180412
In addition to full Markdown support, the following extensions are
supported. These appear as lists at the top level of the comment's
"document". All of these extensions are matched without regard to
case.
Parameter Outlines
------------------
- Parameters:
- x: ...
- y: ...
Separate Parameters
-------------------
- parameter x: ...
- parameter y: ...
- Note:
Parameter documentation may be broken up across the entire comment,
with a mix of parameter documentation kinds - they'll be consolidated
in the end.
Returns
-------
- returns: ...
The following extensions are also list items at the top level, which
will also appear in Xcode QuickHelp as first-class citizens:
- Attention: ...
- Author: ...
- Authors: ...
- Bug: ...
- Complexity: ...
- Copyright: ...
- Date: ...
- Experiment: ...
- Important: ...
- Invariant: ...
- Note: ...
- Postcondition: ...
- Precondition: ...
- Remark: ...
- Remarks: ...
- See: ...
- Since: ...
- Todo: ...
- Version: ...
- Warning: ...
These match most of the extra fields in Doxygen, plus a few more per request.
Other changes
-------------
- Remove use of rawHTML for all markup AST nodes except for those
not representable by the Xcode QuickHelp XSLT - <h>, <hr/>, and of
course inline/block HTML itself.
- Update the doc comment RNG schema to more accurately reflect Xcode
QuickHelp.
- Clean up cmark CMake configuration.
- Rename "FullComment" to "DocComment"
- Update the Swift Standard Documentation (in a follow-up commit)
- Update SourceKit for minor changes and link against cmark
(in a follow-up commit).
Swift SVN r27727
When we're checking for a particular witness in a protocol conformance
because the result is needed elsewhere, capture the diagnostic we
would emit and then store it in the ASTContext. We will emit these
diagnostics when doing the full check of the conformance. Addresses
the rest of rdar://problem/20564378.
Swift SVN r27449
Move the map that keeps track of conforming decl -> requirement from ASTContext
to a nominal type's ConformanceLookupTable, and populate it lazily.
This allows getSatisfiedProtocolRequirements() to work with declarations from module files.
Test on the SourceKit side.
Part of rdar://20526240.
Swift SVN r27353
Now that we can pick up search paths from frameworks (necessary to debug
them properly), we can end up with exponential explosions leading to the
same search path coming up thousands of times, which destroys compilation
time /and/ debugger responsiveness. This is already hitting people with
frameworks compiled for app extensions (due to a mistaken approximation
of whether or not something is a framework), but we're turning this on for
all frameworks in the immediate future.
rdar://problem/20291720
Swift SVN r27087
Have TypeChecker's constructor register itself as the lazy resolver,
and its destructor unregister itself. This introduces the
completely-sensible restriction that there can only be one type
checker active for an ASTContext at a time, which is the case already.
Use ASTContext's lazy resolver in a single place that's been causing
trouble (rdar://problem/20363958, rdar://problem/19773096), where
deserializing a protocol conformance can cause us to pass a null lazy
resolver into the protocol conformance table, which doesn't handle it
well. This commit fixes those issues, which I'm unable to reduce down
to a sane-enough test case to commit.
This commit implies a ton of cleanup work to eliminate LazyResolver
parameters from *everywhere*, deriving them from the ASTContext in the
few places they're needed as well. It's a good direction, but that
cleanup can be evolutionary.
Swift SVN r26824
This tool takes the input of two versions of the same sdk and outputs
their diff to facilicate the auto-migration of sdk clients.
In this initial commit, we take the path of one sdk and generate
a tree describing its API content. Next, we will diff trees generated
from different versions of the sdk.
In addition, this commit also refactored out part of swift-sdk-analyzer
to the common utils shared with swift-sdk-digester.
Swift SVN r26656
Stop storing a conformances array on ExtensionDecls. Instead, always use the conformance lookup table to retrieve conformances (which is lazy and supports multi-file, among other benefits).
As part of this, space-optimize ExtensionDecl's handling of conformance loaders. When one registers a conformance loader, it goes into a DenseMap on ASTContext and gets erased once we've loaded that data, so we get two words worth of space back in each ExtensionDecl.
Swift SVN r26353
Previously, we would require the type checker to be able to build a
conformance, which meant we would actually have to lie in the AST
about having a conformance (or crash; we did the form). Now, we can
form the conformance in the AST and it will be checked in the type
checker when needed. The intent here is to push conformance creation
into the conformance lookup table.
To get here, we had to stop relying on the broken, awful,
ASTContext-wide conformance "cache". A proper cache can come back once
the model is sorted out.
Swift SVN r26250
Previously, a multi-pattern var/let decl like:
var x = 4, y = 17
would produce two pattern binding decls (one for x=4 one for y=17). This is convenient
in some ways, but is bad for source reproducibility from the ASTs (see, e.g. the improvements
in test/IDE/structure.swift and test/decl/inherit/initializer.swift).
The hardest part of this change was to get parseDeclVar to set up the AST in a way
compatible with our existing assumptions. I ended up with an approach that forms PBDs in
more erroneous cases than before. One downside of this is that we now produce a spurious
"type annotation missing in pattern"
diagnostic in some cases. I'll take care of that in a follow-on patch.
Swift SVN r26224
