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.
This is a variation on #1339 and also fixes#1338.
The important difference from #1339 is that this works to retain the
benefits of #1216 which seem important -- both the clarity of printing
the message last and the correctness of actually showing the correct
line number in the backtrace.
The approach in this patch is to disable LLVM's error handling just
before using `std::abort()`. This should give us roughly the best of
both worlds.
This PR also fixes an issue where we wouldn't run the file-cleanup
actions that the LLVM `std::abort()` handler does. This almost certainly
doesn't yet matter, but likely would in the future.
We should separately consider adding back information about filing bugs
that roughly corresponds to the error message that LLVM itself prints.
I've not tried to replicate that from #1339 here and just focused on
getting to `std::abort()` while preserving the desired order of messages
and stack trace locations.
* test cases for raw string literals
* raw string literal implementation
* match as block string if starting with triple ", and better error message for simple string
except for *#"""#*
* fix broken test case
block string literal cannot be one line
* test cases for raw string literals
* raw string literal implementation
* match as block string if starting with triple ", and better error message for simple string
except for *#"""#*
* fix broken test case
block string literal cannot be one line
* removed unused initial value
* rename flag to indicate multi-line string and remove comment
* use * to get value from std::optional
* clean-ups
* removed skip_scan flag and directly return in case of a single line string starting with #+\'\'\'
* Updated error message: simple string -> single-line string.
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
* Updated test cases according to changes in error message
* Removed counting_hashtag flag.
* Implemented ScanHelper class to handle scanning
* Fixed explanation of ReadHashTags.
* Addressed PR comment.
* Clarify that scan_helper holds the source text.
* Addressed PR comments.
* Updated error messages in test cases.
* Added const keyword to return type of GetCurrentStr().
* addressed PR comments.
1. Moved ScanHelper class to lex_scan_helper.h and lex_scan_helper.cpp.
2. Moved ReadHashTags and Process* functions to lex_scan_helper.cpp. Moved YY_USER_ACTION, SIMPLE_TOKEN and ARG_TOKEN to lex_helper.h. Added a wrapper function YyinputWrapper to call static function yyinput in lexer.lpp.
3. Renamed ScanHelper with StringLexHelper.
4. Modified BUILD accordingly.
5. Renamed data members and functions.
* Addressed PR comments.
1. Adjusted order to keep ret usage close.
2. Used resize to construct the string to avoid creation of temp string.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
* Removed the multi_line flag and skip_read field to improve readability.
* Copied default parameter value to definition of UnescapeStringLiteral.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
* Copied default parameter value to definition of ParseBlockStringLiteral.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
* Prefix CARBON_ to SIMPLE_TOKEN and ARG_TOKEN macros.
* Rollback redefinition of arguments.
* Updated comment on the flex macro.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
* Updated wording.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
* Moved the EOF error out of the loop.
* Removed duplicated declaration.
* Changed type of `hashtag_num` and `leading_quotes` to int.
* Minor fix: string copy.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
* Added comment on YyinputWrapper.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
* Garmmar in comment.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
* Added check of eof before readling next char.
* Minor updates based on PR comments.
* Minor changes to address PR comments.
* Used a clearer way to calculate `hashtag_num` and `leading_quotes`. Switched back to indicate muti-line string with a flag.
* Directly copy StringRef for compilation error message.
* Make str_with_quote const as we don't change it.
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
* Added TODO for unsupported cases.
* Fixed a typo.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
This avoids the need to make copies of potentially large maps when
the same bindings are used in multiple values, such as when forming
a bound method value.
Fixes#1173
There is a long standing crash in the LLVM code generator that we manage
to hit when fuzzing. Disable the fast instruction selector in the
fuzzing config to avoid it. I reduced a test case and filed the LLVM bug
here: https://github.com/llvm/llvm-project/issues/56133
Per the design of member access, evaluate the first operand of `.` if it's a type in order to find which type it is, and perform the lookup there.
This allows us to handle the case where the first operand is of type `Type` rather than a more specific type, but can still be evaluated to some specific type value while type-checking.
Type checking now stores information on a member access identifying the member that was accessed, not only its name. This parallels what we do for other similar constructs whose meaning is resolved by name lookup or type-checking, and will allow us to avoid redoing lookups in some cases during interpretation.
Working on toolchain semantics:
- SemanticsIR is set up as a container for the semantic tree.
- SemanticsIRFactory builds the tree, with separate transformations for each ParseNodeKind.
- ParseSubtreeConsumer is a helper for transforming a ParseTree::Node's children, managing size/nodes to prevent errors.
- The nodes subdirectory contains SemanticIR nodes.
- MetaNode is used to represent nodes which have "sub-classes": Statements, Declarations, and Expressions.
- MetaNodeBlock is used to represent nodes which exist together in a block with name lookup: Statements and Declarations (not Expressions).
This is traversing children first in order to address the RPO format of ParseTree. This means that when lists are formed, they're reversed to be in code-order (`FixReverseOrdering`).
This is still very much incomplete -- the main intent at present is to demonstrate structure.
This works by splitting the constraint up into interfaces and checking
that each of them is implemented in turn.
Also check that the parameters of the impl are deducible from each of
the resulting (type, interface) pairs.
`.Self` is modeled as a new kind of expression, `DotSelfExpression`. Name resolution associates each occurrence of a `DotSelfExpression` with a generic binding, much like for an `IdentifierExpression`.
Both `:!` bindings and `where` expressions bring `.Self` into scope. The tentative intent is that if there are multiple `.Self`s in scope and they refer to different bindings, the result of using a `.Self` expression is an ambiguity error, but that is not implemented in this patch. Instead, like for `IdentifierExpression`s, we find the innermost enclosing definition of `.Self`.
`.Foo` expressions are rewritten to `.Self.Foo`, but this isn't enough to make them do anything useful, because associated constants aren't supported in general yet.
This follows #1274 and #1325 and fills in the "safety" section. It only covers our approach in general terms.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
This causes compile-time evaluation to give the same result as runtime
evaluation wherever possible. In particular, referencing a generic
parameter at compile time will resolve to the actual value if we're
evaluating a call to the enclosing function so a value for the
parameter is available in the call frame.
Clean up recently-added support for `SymbolicWitness`es using this.
This follows #1274 . It mainly fills in the "generics" section, with smaller updates to other section.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
* initial implementation of new and delete
* remove requirement for empty heap from trace.carbon
* more tests
* fixed substitution for generic function types
Prior to this change, the section headings for the 7 main goals are visually indistinguishable (in GitHub's rendering) from the boldfaced paragraph headings in those sections. This makes the doc hard to navigate because the structure is hidden.
This renames `Witness` to `ImplWitness` and adds a new form, `SymbolicWitness`, that holds an expression by which a witness can be computed. A common base class `Witness` is provided.
We form the new kind of witness when evaluation of a witness expression fails because the witness is not in scope, as happens when evaluating a subexpression such as a type expression in isolation, and retry evaluation in the larger context when the interpreter performs type instantiation when running the code.
This allows us to properly handle compile-time evaluation of constructs involving witness table lookups when the witness can be statically determined. The intent is that we will eventually also form symbolic witness table references when impl selection finds a non-final witness, in order to support specialization.
Simplify `NominalClassValue`: it can now always store a witness map rather than either a witness map or a witness-or-witness-expression map.
This change updated a test to use a different example to make sure a
diagnostic was still being exercised, but as a consequence lost test
coverage of the situation the test was originally intended to cover.
Add back the old test and put the new test into a different file.
Reorganizes the sections, and makes a pass filling in and updating the first sections including: types, functions, user-defined types. The following sections are left for part 2, including names, generics, and interop.
Also some smaller updates to, not revisiting the text: `pattern_matching.md`, `control_flow/return.md`, and `lexical_conventions/numeric_literals.md`
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Build constraint types from `where` expressions. This is very bare-bones; there's no support for constraining `.Self` or associated types yet, but degenerate cases not involving self-reference work.
`==` constraints are syntactically supported but not semantically verified yet, and they aren't used for anything.
The syntax permitted in an `interface` is similar to, but different from, that permitted elsewhere. For example, associated constant declarations (`let T:! Type;`) with no initializers are valid in interfaces but nowhere else, and are a different kind of declaration from what a normal `let` declaration would produce both syntactically and semantically.
Because interfaces and impls permit only a very small subset of the complete set of kinds of declaration, it's simpler to list only the kinds that are permitted rather than to allow an arbitrary declaration and semantically disallow the invalid cases, and it's also likely to lead to better error messages as we won't try to parse unintended or meaningless things.
* added documentation for tracing output, changed the printing of scopes to be part of the stack, made other minor changes hoping to enhance readability
* reformat a list in the README
* minor edit
* fix the lists
* updates to the interpreter/README.md
Tiny nit: Line 63 similarly links "modern generics system". Line 250 links 'generics', but doesn't include "modern ... system." So I think this approach is consistent (and subtly, implies the link is about the modern ... system, not just "generics").
Add scaffolding for constraints in general, and support specifically constraints formed by applying a `&` operator.
No support for constraints formed with `where` nor for named constraints at this point.
Chandler Carruth
Céline Dedajandjonmeow
SlaterLatiao
pk19604014
Jeremy G. Siek