Restores StoredDiagnosticInfo, which is useful to help distinguish
when the user explicitly modifies the behavior of a diagnostic vs
we're just picking up the default kind.
Adds some clarifying comments, and lays out the suppression workflow,
whereby different types of suppression (per-diagnostic, per-category,
etc) have different precedence levels.
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
Per Chris's feedback and suggestions on the verbose fix-it API, convert
diagnostics over to using the builder pattern instead of Clang's streaming
pattern (<<) for fix-its and ranges. Ranges are included because
otherwise it's syntactically difficult to add a fix-it after a range.
New syntax:
diagnose(Loc, diag::warn_problem)
.highlight(E->getRange())
.fixItRemove(E->getLHS()->getRange())
.fixItInsert(E->getRHS()->getLoc(), "&")
.fixItReplace(E->getOp()->getRange(), "++");
These builder functions only exist on InFlightDiagnostic; while you can
still modify a plain Diagnostic, you have to do it with plain accessors
and a raw DiagnosticInfo::FixIt.
Swift SVN r4894
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
This will be necessary for things like typo-correction, but currently
serves no purpose because all of our diagnostics are token-based. It's
going to be the base range type for Swift fix-its, though, so I thought I'd
get it in place now.
Swift SVN r4750
If the completion prefix has a '.' behind it, guesstimate a context expression by lexing backward through an identifier(.identifier)* dotted path, then attempt to parse and typecheck that expression to decide on a base type in which to find completions.
Swift SVN r4063
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
