> On Nov 7, 2017, at 4:18 AM, Mohammed Ennabah via swift-dev
> <swift-dev@swift.org> wrote:
>
> Hi all,
>
> This is the first time I work on that deep of the compiler (in SR-3423 Enum
> with tuple raw value not allowed) and I’m not sure where to start and what do
> I need to do and what files this issue is related to. It would be great if
> anyone guided me. Thanks.
This is *just* the very first step, but here's what I do when I want to debug
something that involves a compiler error message:
1. Write some code that triggers the bug and compile it.
For instance, that bug includes a Stack Overflow link—copy that code
and paste it into the Swift REPL.
2. Pick some chunk of the error message that doesn't include any
identifiers and search the Swift source code for it.
For instance, one of the errors is "raw value for enum case must be a
literal", so search for that.
3. Most of the hits will be tests, but one will be in a .def file;
that's where the error is defined. Open the file, go to that line, and get the
error identifier from it.
In this case, include/swift/AST/DiagnosticsParse.swift has this line in
it:
ERROR(nonliteral_enum_case_raw_value,PointsToFirstBadToken,
"raw value for enum case must be a literal", ())
The identifier I'm talking about is the first argument to the ERROR
macro—here, it's "nonliteral_enum_case_raw_value".
(Before you move on to the next step, look around in this file a little
bit and try to get a sense for how error message strings are formatted. It may
help you with future error searches.)
4. Search the Swift source code for that error identifier. Each hit
(besides the one in the .def file) is one of the places in the compiler that
can generate that error message. Read the code around each of those hits
(including the name of the functions, types, files, and folders it's in) and
try to figure out if it handles the specific case you want to solve, and if so,
how you might be able to modify it to suit your needs.
In this example, there is only one hit—in a .cpp file in the
parser—and, a couple lines above it, you can see a dyn_cast call that checks if
the expression is a literal. (`dyn_cast` is equivalent to an `as?` cast in
Swift—it returns `null` if the value doesn't belong to the indicated type.)
This is where the compiler is testing whether the raw value assigned to a case
is a literal. You'll need to modify the code here so that it also accepts
tuples of literals (and presumably, tuples of tuples of literals, and so on).
There will be more to do, but that's the first step.
When you're reading code, don't be discouraged if you don't understand it
immediately. The Swift compiler is a large, complicated system, and there's
lots of complicated stuff going on. Be patient, don't be afraid to jump over to
another function to see what it does, and if you get stuck trying to figure out
one part, move on to something else.
I'm still very much a beginner, but this has helped me get started on a few
different bugs. I hope it can help you too.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
