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
