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.
Céline Dedaj
cui fliter
Thomas Lively
Jon Ross-Perkins
Ryan Russell
Matt Godbolt
Dan Sarginson
Laurent Le Brun
Chandler CarruthandJon Ross-Perkins
Richard Smith
pk19604014
Hana DusíkováandChandler Carruth
SlaterLatiao