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
one that performs the coercion on the AST and produces diagnostics for
any problems, and one that simply determines whether the coercion
would succeed. The former already existed (as
TypeChecker::convertToType), while an approximation of the latter was
already implemented as Expr::getRankOfConversionTo(). Unifying these
code paths addresses several issues:
- Lots of redundancy in the code for computing these two properties,
which causes bugs. For example, Expr::getRankOfConversionTo()
wasn't able to handle literals (!).
- Determining whether a conversion is possible will need the full
power of the type checker, e.g., to deal with closures in cases
like:
func f(g : (int, int) -> int);
func h() { f({$1 + 0}); }
Although this is not handled correctly now.
I have opted not to adopt Clang's ImplicitConversionSequence (or
InitializationSequence) design, which computes a record of the steps
needed to perform the conversion/coercion and later applies those
steps, because we don't need that complexity yet. If we start
introducing more implicit conversions into the language, we'll revisit
this decision.
Swift SVN r1308
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
