Allows unformed state for local variables. Reports a run-time error when an unformed local variable is used.
- Added declaration without initialization for local variables in the parser.
- Made the init expression of VariableDefinition optional.
- Expanded (alive, dead) to (uninitialized, alive, dead) in the Heap.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Following a short discussion on Discord about where to locate developer tools, I suggest we collect developer utils inside a `/utils` directory at the repository root.
The idea behind this directory is taken from LLVM's utils directories in the various LLVM subprojects which host tooling such as Vim and VSCode extensions, utility scripts, and other useful bits for developers developing or using LLVM.
This patch moves the highlightjs code into said utils directory.
Let me know if there's anything else that's missing 😄
cc @jonmeow
One is a really basic version of the weapons policy used by many
conferences and events in the tech space.
The other is trying to expand on a sentence to make the nature of how we
will handle these difficult cases.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
We don't have overload resolution, so I've simply added PrintInt for now. But it's really tempting to turn __intrinsic_print into a total kludge function.
I accidentally put in one I'd considered, instead of the one I'd decided was probably the best fit, and the names are so similar I didn't notice.
NOTE: This still isn't totally working, but I think it will when we go public.
Basic support for declaring, specifying the values of, and using associated constants.
This is incomplete in various ways. For example, when checking whether a type satisfies a constraint, there is no check that its associated constants match those in the constraint, and name lookup into a value whose type is an associated constant is not supported yet.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Some discomfort is required for us to grow as people as well as a community. Requesting to not make people feel "discomfort" may be weaponized against people seeking help from the CoC team.
So, I deleted "uncomfortable and" from "uncomfortable and threatened". Not making people "threatened" suffices.
Please see this document for more background information: [CLP CoC review July 2022](https://docs.google.com/document/d/1XzHMymzn3hxdlnaI44iukT24fy1MdwTXdebhzT45bCI/edit?usp=sharing)
Co-authored-by: jonmeow <jperkins@google.com>
This is especially tricky, as there doesn't seem to be support for
indirect recursion, only direct recursion. As a consequence, its
important to have a single recursive pattern that handles all the
balanced delimiters in an expression context.
I've tried to add some comments to help explain this.
I also tried to add something to check that the balanced delimiters
*matched* and re-synchronize if they don't, but that didn't end up
working. I also tried various things to force re-synchronizing more
rapidly in the face of unbalanced delimiters but they all produced
strictly worse highlighting than what I have here. I will try again in
a follow-up commit, but for now this will work well enough for slides.
This required reworking how `=` and `;` were handled as well as more
general surgery on patterns.
This looks for initializers at the top level of parameters and at the
end of `var` or `let` declarations. It supports fancy nested `var`
patterns within `let` declarations, etc.
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Asking people to “assume good intent” may be weaponized against people seeking help from the CoC team.
So, I replaced instances in which we mentioned we'd expect "positivity" with the more accurate and less risky "constructivity".
Please see this document for more background information: CLP CoC review July 2022
Co-authored-by: jonmeow <jperkins@google.com>
Asking people to be “positive” is preventing us from creating psychological safety in our community. It may be weaponized against people seeking help from the CoC team.
So, I replaced instances in which we mentioned we'd expect "positivity" with the more accurate and less risky "constructivity".
Please see this document for more background information: https://docs.google.com/document/d/1XzHMymzn3hxdlnaI44iukT24fy1MdwTXdebhzT45bCI/edit?usp=sharing
Co-authored-by: jonmeow <jperkins@google.com>