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>
This PR implements the `returned var` for the explorer.
- Enabled `returned var` and `return var` syntax in lexer and parser.
- Split `Return` statement into `ReturnVar` and `ReturnExpression` to distinguish the two types of returns.
- Added logic in name resolution, type checking and interpretation to process `returned var` definition and `ReturnVar` statement.
This is how I'm interpreting discussion:
- Basic elements are getting set to an ID.
- SetName exists to assign a name (which can then be referred to later with an identifier expression) to an ID.
- Expressions are broken down into a series of operations which operate on IDs.
So with something like the last test:
```
fn Main() { return 12 + 34; }
```
This becomes:
```
Function(%0,
{IntegerLiteral(%3, 12),
IntegerLiteral(%2, 34),
BinaryOperator(%1, +, %3, %2),
Return(%1),
})
SetName(`Main`, %0)
```
Note I'm treating blocks as fairly equal to the top of a file now, and basically eliminating boundaries between things. That's because we have discussed also supporting code like:
```
fn Foo() {
fn Bar() {}
Bar();
}
```
Here a declaration of a function is occurring inside a code block, so it felt like eliminating the difference was the best choice.
I know you'd commented on the separation of nodes to individual files before; I still think we're going to have a lot of different types of nodes, and so separating them out into individual files makes them easier to browse.
This is a proposal to make the Carbon experiment public.
We have not yet hit many of the originally suggested criteria for going
public. However, this proposal suggests that increasingly there is more
value to moving public sooner rather than waiting to hit these criteria.
We are increasingly unable to substantially learn more about the broader
interest in Carbon without it being public and we increasingly see value
in working with the industry to build and shape the language.
Given this, the proposal removes the old plan-of-record and suggests
a concrete set of steps to make the experiment public in the immediate
future.
This is not a change that we can make lightly to the project, and so we
worked to check with as many folks as we could first and all three
leads were unanimous to move forward here.
Note that this proposal was originally discussed in PR #1315.
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Following #875, diagnose any use of a name prior to the point where it is introduced and its type is known.
This works by performing name resolution on a top-level class, interface, or impl twice: the first pass performs name-resolution for everything other than nested function bodies, and the second pass performs name resolution on function bodies. At the moment, the second pass does a superset of the work done by the first pass, and as a consequence, some identifier expressions now have their target set twice to the same thing.
This gets us into 2022-06-29 commits.
Originally @JonMeow was doing this, and we paired to resolve a bug in
our Bazel configs that landed in #1350 so now we can pull it.
Sending this out now so that CI can do the slow run and start caching
build artifacts.
There were compile actions that should use `clang` that we didn't
include because they aren't *technically* C compile actions. For our
toolchain though, we treat them as such, so create a list of actions
that we compile equivalently to C, and use that to set it up.
This will fix a problem with top-of-tree LLVM where we need to handle
preprocessed assembly files.
This proposal establishes a plan for moving away from the embedded copy
of LLVM and instead downloading it with Bazel.
The goal is that after this lands, we will do a history-rewrite to
cleanup the repository. There are instructions on how folks can move any
in-flight work over to the newly tidied repo.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
This was noticed because macos stopped installing the brew llvm, and they don't have clang-format. However, our tests don't actually need clang-format (and even if they did, we should probably match the pre-commit version), so it seems superfluous to check for.
Keeping brew because there's an advantage to consistency on tool versions, just running it on all platforms instead of linux-only.
This follows #1274 , #1325 , and #1328 . It fills in the "Bidirectional interoperability with C and C++" section.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: Geoff Romer <gromer@google.com>
We fundamentally have cyclic references between declarations,
statements, expressions, and patterns, and there's no meaningful
layering between them. Combine them into a single build target.
Components such as paren_contents, static_scope, and library_name that
are defined without reference to specific AST nodes are kept as separate
BUILD targets.
Matt Godbolt
Dan Sarginson
Laurent Le Brun
Jon Ross-Perkins
Chandler CarruthandJon Ross-Perkins
Richard Smith
pk19604014
Céline Dedajandjonmeow
Hana DusíkováandChandler Carruth
SlaterLatiao