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>
Asking people to be “respectful” can be considered “tone policing” and may be weaponized against people seeking help from the CoC team.
So, I replaced instances in which we stated that we'd expect "respect" with the more encompassing and less risky "kindness".
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>
Replaced "Posting, or threatening to post, other people’s personally identifying information ("doxing") without their explicit permission."
by "Posting, or threatening to post, other people’s personally identifying information without their explicit permission ("doxing")."
There are still quite a few parts of the language that need support
here, but I've tried to piece together a decent foundation and address
some of the particular challenges with building a good framework that
handles some of the complex parts of the grammar such as successfully
identifying the declared names in even reasonably complex patterns.
I've included a pretty ad-hoc test file I've been using to make sure it
works. If folks want a particular testing strategy for this, happy to
explore building one although I don't really know what it should look
like.
Also happy to have suggestions about where this should live in the
repository. No strong opinions there. Hoping to eventually add
a `tmLanguage` file and any other syntax highlighting systems that are
useful.
I'll next be finishing off other parts of the language, and then I plan
to use this as a component of our presentation material, which is why
I'm focused on Highlight.js -- that's the system used most widely in
HTML-based presentation infrastructure like Reveal.js.
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
This follows #1274 , #1325 , #1328 , #1336 , and #1347 . This has miscellaneous changes to the design overview without a particular focus.
Also adds some missing keywords to our list of keywords.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Instead of complaining that the name is not completely declared, say it's not
declared at all yet.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>