We have to work with selectors quite often, so provide an efficient
representation for them. Switch ObjCAttr over to this representation,
which has the nice property that it efficiently represents implicit
@objc attributes with names and allows us to overwrite the Objective-C
name without losing all source information. Addresses
<rdar://problem/16478678>, and sets us up for dealing with selectors
better.
Swift SVN r16327
Provide a fine-grained classification of declarations that can be used
in diagnostics instead of ad hoc %select operations. For now, only cut
over the "overriding a final <whatever>" diagnostic.
Swift SVN r15932
Thanks to the way we've set up our diagnostics engine, there's not actually
a reason for /everything/ to get rebuilt when /one/ diagnostic changes.
I've split them up into five categories for now: Parse, Sema, SIL, IRGen,
and Frontend, plus a set of "Common" diagnostics that are used in multiple
areas of the compiler. We can massage this later.
No functionality change, but should speed up compile times!
Swift SVN r12438
Part of the FileUnit restructuring. A serialized module is now represented as
a TranslationUnit containing a single SerializedASTFile.
As part of this change, the FileUnit interface has been made virtual, rather
than switching on the Kind in every accessor. We think the operations
performed on files are sufficiently high-level that this shouldn't affect us.
A nice side effect of all this is that we now properly model the visibility
of modules imported into source files. Previously, we would always consider
the top-level imports of all files within a target, whether re-exported or
not.
We may still end up wanting to distinguish properties of a complete Swift
module file from a partial AST file, but we can do that within
SerializedModuleLoader.
Swift SVN r10832
The goal of this series of commits is to allow the main module to consist
of both source files and AST files, where the AST files represent files
that were already built and don't need to be rebuilt, or of Swift source
files and imported Clang headers that share a module (because they are in
the same target).
Currently modules are divided into different kinds, and that defines how
decls are looked up, how imports are managed, etc. In order to achieve the
goal above, that polymorphism should be pushed down to the individual units
within a module, so that instead of TranslationUnit, BuiltinModule,
SerializedModule, and ClangModule, we have SourceFile, BuiltinUnit,
SerializedFile, and ClangUnit. (Better names welcome.) At that point we can
hopefully collapse TranslationUnit into Module and make Module non-polymorphic.
This commit makes SourceFile the subclass of an abstract FileUnit, and
makes TranslationUnit hold an array of FileUnits instead of SourceFiles.
To demonstrate that this is actually working, the Builtin module has also
been converted to FileUnit: it is now a TranslationUnit containing a single
BuiltinUnit.
Swift SVN r10830
Also remove the SourceLoc parameter from addNewSourceBuffer(). In llvm::SourceMgr
it is used to indicate textual inclusion, which we don't have in swift.
Swift SVN r10014
and remove DeclContext base class from FuncDecl, ConstructorDecl and
DestructorDecl
This decreases the number of DeclContexts to 7 and allows us to apply
alignas(8) to DeclContext.
Swift SVN r8186
Diagnostics that point to the first bad token are marked with this option in
Diagnostics.def. Parser::diagnose treats the source location of such
diagnostics in a special way: if source location points to a token at the
beginning of the line, then it moves the diagnostic to the end of the previous
token.
This behaviour improves experience for "expected token X" diagnostics.
Swift SVN r7965
integration
Motivation: libIDE clients should be simple, and they should not have to
translate token-based SourceRanges to character locations.
This also allows us to remove the dependency of DiagnosticConsumer on the
Lexer. Now the DiagnosticEngine translates the diagnostics to CharSourceRanges
and passes character-based ranges to the DiagnosticConsumer.
Swift SVN r7173
When we're diagnosing an error during the initialization of a
parameter from an argument, point at the actual parameter (if we can
find it) or at least the function (if we can't) where the call
failed. Baby steps:
t2.swift:3:4: error: '(x : Int, y : Int)' is not a subtype of 'Int'
f3(f3b)
^
t2.swift:1:9: note: in initialization of parameter 'x'
func f3(x : (x : Int, y : Int) -> ()) {}
^
Swift SVN r6924
Since we only print a single line, there's no point in including the
open-brace at the end. Moreover, modules are /supposed/ to be opaque.
The user shouldn't be thinking about how any adapter functions work,
either.
On the other hand, if we're looking at a non-top-level decl, we want to
see it as if it were in context, so in that case we can be more "source-y".
Swift SVN r6919
Eventually TypeLocs coming from the Parser will contain only a TypeRepr and the TypeChecker will resolve and add the type.
Passing a TypeLoc to a diagnostic means "print as user written" (even before typechecking)
and if there is no TypeRepr (e.g. due to a TypeLoc coming from a module without location info) print the type.
Swift SVN r6280
Because of '~=' lookahead and precedence parsing, we need to be able to parse pattern productions in expression position and validate them after name binding. Add an unresolved Expr node that can hold a subpattern for this purpose.
Swift SVN r5825
Fix-its are now working!
Feedback on the API is welcome. I mostly took what was in Clang as a model,
so the usual way to use a FixIt is to pipe it into an active diagnostic:
<< Diagnostic::FixIt::makeInsertion(Tok.getLoc(), "&")
<< Diagnostic::FixIt::makeDeletion(E->getRange())
<< Diagnostic::FixIt::makeReplacement(E->getRange(), "This")
(Yes, of course you can specify the first two in terms of makeReplacement,
but that's not as convenient or as communicative.)
I plan to extend the expected-* notation to include a notation for fix-its
before converting any other diagnostics over, but this is a start.
Swift SVN r4751
Note: this is an experiment.
When we're asked to render a diagnostic for a declaration that does
not have source information, pretty-print the declaration into a
buffer and synthesize a location pointing into that buffer. This gives
the illusion of Clang-style diagnostics where we have all of the
source headers, but without actually requiring that source location
information. It may prove useful or infuriating, but at the very least
it might help us understand how the importer works. Example:
cfuncs_diags.swift:14:7: error: no candidates found for call
exit(5)
~~~~^~~
cfuncs_diags.swift:6:6: note: found this candidate
func exit(_ : Float) {}
^
cfuncs.exit:1:6: note: found this candidate
func exit(_ : CInt)
^
Swift SVN r3434
Swift's diagnostic system is built on the quaint notion that every
declaration known to the front end has a valid source location to
which diagnostics mentioning that declaration (say, in a "here is a
candidate" note) can point. However, with a real module system, the
source corresponding to a declaration in a module does not need to be
present, so we can't rely on source locations.
Instead of source locations, allow diagnostics to be anchored at a
declaration. If that declaration has source-location information, it
is used. Otherwise, we just drop source-location information for
now. In the future, we'll find a better way to render this information
so it feels natural for the programmer.
Swift SVN r3413
types. Use this simple overload resolution scheme in both type
checking and type coercion, simplifying both code paths a bit.
There is one significant semantic change here: we allow overload
resolution to operate on (structured) dependent arguments, which
allows for more overload filtering before we come in with the type
coercion hammer. For example, we can now properly type-check
var x : int32;
x + 0;
Swift SVN r1310
aren't needed for the lexer proper (which just needs a buffer to dig
through). Also, make it possible to suppress lexer diagnostics merely
by not giving it a diagnostic engine to work with.
Swift SVN r852
actually render emitted diagnostics. This is both a useful
generalization (we expect to have a number of other
DiagnosticConsumers down the road, as Clang does) and is also
important now to avoid a layering violation when adjusting the source
location at the end of a SourceRange to the end of the token.
Swift SVN r850
Note that I had to re-implement llvm::Optional, since it lamely requires a default constructor. At some point, I'll push a proper implementation back to LLVM.
Swift SVN r845
