> On Nov 13, 2017, at 4:00 PM, Brent Royal-Gordon <br...@architechies.com> > wrote: > >> On Nov 11, 2017, at 2:59 PM, Mohammed Ennabah via swift-dev >> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >> >> I dug into the codebase as stated in the steps you mentioned, and tried to >> change one of the errors to see if it really change when I use Swift REPL, >> but nothing changed. Is it possible that I change something and directly >> affect the Swift compiler? (maybe I need to do a build first? Or maybe >> related to xcode-select?) > > If you just type "swift" at the command line, you'll run the version of Swift > built into Xcode. You will need to build Swift first ("utils/build-script" is > the easiest way, but not the fastest), and you will also need to run the > version of the Swift interpreter you just built. You can do that with a > command like: > > ../build/Ninja-DebugAssert/swift-macosx-x86_64/bin/swift > > (The path will be a little different if you use the "-x" flag to > build-script, which generates an Xcode project, albeit one that's a pain to > use.) > >> Each type of diagnostics has 4 parts, ERROR(ID,Options,Text,Signature). >> Diagnostics use the first 3 parts and pass parentheses to the signature. >> What is meant by the signature and why it’s used? > > Error messages actually use a sort of format string language similar to > printf(); for those messages which take parameters, the signature gives their > types. For example, DiagnosticsParse.def includes this error: > > ERROR(expected_identifier_in_decl,none, > "expected identifier in %0 declaration", (StringRef)) > > So code which emits that error must include a string to put in place of the > "%0" token: > > // When we write "import" followed by a keyword that isn't "class", > "struct", "protocol", etc.: > diagnose(Tok, diag::expected_identifier_in_decl, "import"); > > // When we try to parse an identifier after e.g. "typealias" and don't > find one: > P.diagnose(P.Tok, diag::expected_identifier_in_decl, DeclKindName); > > // When we try to parse an identifier after "case" and find some > punctuation or a literal: > diagnose(CaseLoc, diag::expected_identifier_in_decl, "enum 'case'"); > > Strings are the most common kind of parameter, but you can also pass other > types and choose between different wordings based on them. For instance, > here's a fix-it note I added for multiline string literals which takes a > boolean to indicate singular or plural: > > NOTE(lex_multiline_string_indent_change_line,none, > "change indentation of %select{this line|these lines}0 to match > closing delimiter", (bool)) > > This error, which is shown when there's a non-digit in an integer literal, > takes both a string containing the bad character, and a number (0 to 3) > indicating which literal format it was parsing: > > ERROR(lex_invalid_digit_in_int_literal,none, > "'%0' is not a valid %select{binary digit (0 or 1)|octal digit > (0-7)|" > "digit|hexadecimal digit (0-9, A-F)}1 in integer literal", > (StringRef, unsigned)) > > If you look around that file and the other Diagnostics*.def files, you'll see > some other interesting examples. Have fun poking around! >
Good work. I believe that these are pretty good examples to understand how the Swift diagnosis work in practice. > -- > Brent Royal-Gordon > Architechies >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
