if there's no parameter API name. This is for display purposes only.
Update all relevant tests accordingly.
This addresses <rdar://problem/16768768>.
For example:
class X {
func f(a: Int, b: Int) { }
}
Would previously display like this in code completion in Xcode:
f(<#Int#>, b: <#Int#>)
The local parameter name, while not API, often still conveys meaning
to the user. So it's now included like this:
f(<#a: Int#>, b: <#Int#>)
Swift SVN r18403
A use-after-free could happen in the following scenario:
- code completion caches results from module A;
- code completion returns cached results -- result set 1;
- module is rebuilt;
- another code completion request arrives, cache is invalidated and re-filled.
Old results are freed, even though someone could be still using the result
set.
rdar://16953614
Swift SVN r18329
This will be used to highlight function calls and declarations for
QuickHelp and Jump-to-definition.
Add test for the above.
<rdar://problem/16862981>.
Swift SVN r17824
This commit adds infrastructure for conversion and testing it.
The conversion is still incomplete, pending discussion about which tags should
we use in the XML documents. I copied the RelaxNG schema from Clang, and will
edit it accordingly.
Swift SVN r16451
In order for Xcode to use these completions, we complete "?.member" when the
user has typed "anOptional.", but we also say that in order to apply this
result, N bytes to the left of the cursor should be erased first.
rdar://16579657 rdar://15233283
Swift SVN r16409
Brings back the behavior removed in r15800 under a pair of flags
(-module-print-submodules and -module-print-hidden) that control
whether to print submodules, possibly including submodules that aren't
explicitly visible.
Swift SVN r15872
AttributeId: Any occurence of '@<attribute-name>' anywhere.
AttributeBuiltin: A "resolved/active" attribute. Mis-applied attributes will be AttributeId.
This provides more options for coloring attributes in a way that one can easily spot
attributes that are not applied correctly.
Swift SVN r12194
This completes the FileUnit refactoring. A module consists of multiple
FileUnits, which provide decls from various file-like sources. I say
"file-like" because the Builtin module is implemented with a single
BuiltinUnit, and imported Clang modules are just a single FileUnit source
within a module.
Most modules, therefore, contain a single file unit; only the main module
will contain multiple source files (and eventually partial AST files).
The term "translation unit" has been scrubbed from the project. To refer
to the context of declarations outside of any other declarations, use
"top-level" or "module scope". To refer to a .swift file or its DeclContext,
use "source file". To refer to a single unit of compilation, use "module",
since the model is that an entire module will be compiled with a single
driver call. (It will still be possible to compile a single source file
through the direct-to-frontend interface, but only in the context of the
whole module.)
Swift SVN r10837
Part of the FileUnit restructuring. A Clang module (whether from a framework
or a simple collection of headers) is now imported as a TranslationUnit
containing a single ClangModuleUnit.
One wrinkle in all this is that Swift very much wants to do searches on a
per-module basis, but Clang can only do lookups across the entire
TranslationUnit. Unless and until we get a better way to deal with this,
we're stuck with an inefficiency here. Previously, we used to hack around
this by ignoring the "per-module" bit and only performing one lookup into
all Clang modules, but that's not actually correct with respect to visibility.
Now, we're just taking the filtering hit for looking up a particular name,
and caching the results when we look up everything (for code completion).
This isn't ideal, but it doesn't seem to be costing too much in performance,
at least not right now, and it means we can get visibility correct.
In the future, it might make sense to include a ClangModuleUnit alongside a
SerializedASTFile for adapter modules, rather than having two separate
modules with the same name. I haven't really thought through this yet, though.
Swift SVN r10834
I tried hard find all references to 'func' in documentation, comments and
diagnostics, but I am sure that I missed a few. If you find something, please
let me know.
rdar://15346654
Swift SVN r9886
