Web-Projects/blog-static
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Adjust code lines.

Browse Source
This commit is contained in:
Danila Fedorin 2020-09-18 14:42:50 -07:00
parent d153af5212
commit 50a1c33adb
1 changed files with 19 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
content/blog/13_compiler_cleanup/index.md
View File

@ -535,7 +535,7 @@ In general, this change is also rather mechanical, but, to
maintain a balance between exceptions and assertions, here maintain a balance between exceptions and assertions, here
are a couple more assertions from `type_env`: are a couple more assertions from `type_env`:
{{< codelines "C++" "compiler/13/type_env.cpp" 77 78 >}} {{< codelines "C++" "compiler/13/type_env.cpp" 81 82 >}}
Once again, it should not be possible for the compiler Once again, it should not be possible for the compiler
to try generalize the type of a variable that doesn't to try generalize the type of a variable that doesn't
@ -621,7 +621,7 @@ Now that we've started using assertions, I also think it's worth
to put our new invariant -- "only global definitions have mangled to put our new invariant -- "only global definitions have mangled
names" -- into code: names" -- into code:
{{< codelines "C++" "compiler/13/type_env.cpp" 35 44 >}} {{< codelines "C++" "compiler/13/type_env.cpp" 36 45 >}}
Furthermore, we'll _require_ that a global definition Furthermore, we'll _require_ that a global definition
has a mangled name. This way, we can be more confident has a mangled name. This way, we can be more confident
@ -631,11 +631,24 @@ this, we change `get_mangled_name` to stop
returning the input string if a mangled name was not returning the input string if a mangled name was not
found; now that we _must_ have a mangled name, doing found; now that we _must_ have a mangled name, doing
so is effectively obscuring the error. Instead, so is effectively obscuring the error. Instead,
we add another assertion: if an environment scope doesn't we add two assertions. First, if an environment scope doesn't
contain a mangled name for a variable, then it _must_ contain a variable, then it _must_ have a parent.
have a parent. We end up with the following: If it does contain variable, that variable _must_ have
a mangled name. We end up with the following:
{{< codelines "C++" "compiler/13/type_env.cpp" 46 52 >}} {{< codelines "C++" "compiler/13/type_env.cpp" 47 55 >}}
For this to work, we make one more change. Now that we've
enabled C++17, we have access to `std::optional`. We
can thus represent the presence or absence of mangled
names using an optional field, rather than with the empty string `""`.
I hear that C++ compilers have pretty good
[empty string optimizations](https://www.youtube.com/watch?v=kPR8h4-qZdk),
but nonetheless, I think it makes more sense semantically
to use "absent" (`nullopt`) instead of "empty" (`""`).
Here's the definition of `type_env::variable_data` now:
{{< codelines "C++" "compiler/13/type_env.hpp" 16 25 >}}
Since looking up a mangled name for non-global variable Since looking up a mangled name for non-global variable
will now result in an assertion failure, we have to change will now result in an assertion failure, we have to change