Commit Graph
18 Commits
Author SHA1 Message Date
Richard Smith e8cc089b2b Allow simple uses of Self in impls. (#3824)
Per #3714, some of the details here are not yet settled. In particular,
we might want `Self` to come into scope at the start of the definition,
not at the `as` keyword. However, this change allows us to accept the
uncontroversial examples.
2024-03-27 22:52:45 +00:00
Jon Ross-Perkins 86a7c9ff45 Rename parse_node -> node_id (#3760)
This was previously discussed at
https://discord.com/channels/655572317891461132/655578254970716160/1209975051588210729.
I'm initiating this mainly because we typically use "id" suffixes to
indicate an `IdBase` being passed around and the non-id suffix of
`parse_node` suggests at it carrying more data than it actually does.
There used to be more reason for avoiding `node_id` because
`SemIR::InstId` used to be named `NodeId`, but that's no longer
necessary. As a consequence, I'd like to rename `parse_node` to more
precisely reflect its type.

In full, this is doing:

```
parse_node_kind -> node_kind
parse_node -> node_id
ParseNodeCategory -> NodeCategory
ParseNodeKind -> NodeKind
ParseNode -> NodeId
```

This is primarily in check and sem_ir, but with some `parse_node_kind`
references in parse too.

Pluralization is consistent with name forms on both sides, so that
wasn't part of my replacements.
2024-03-09 00:21:29 +00:00
Jon Ross-Perkins 096daecc57 Add framework for the extern keyword. (#3755)
This doesn't add full support. I'm separating it out to make the effects
of the modifier changes clearer for review. I'm restructuring a little
with the expectation that we'll have some more categories of modifier
keywords in the future (similar to `extern`, these may not be in a "set"
such as access), and thus easily scaling up to a few more would be
useful.
2024-03-08 16:01:12 +00:00
Richard SmithandJon Ross-Perkins abf23ae7fe Initial scaffolding for building a witness table for an impl. (#3743)
Add an instruction to hold the witness table, along with a corresponding
type to keep things simpler. Add `check/impl.{h,cpp}` to house the new
logic. No checking of impls against interfaces is performed yet.

---------

Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
2024-03-07 23:10:14 +00:00
Jon Ross-Perkins abe8ce6653 Add support for importing interfaces. (#3726)
Interface support is pretty skeletal so this may need additions later,
but I think it's still worthwhile to fill in the necessary bits now.
With this change, the expectation is then that everything we have right
now which _can_ be imported, is supported for import (at least for the
"current package, no overlap" case).
2024-02-26 22:55:22 +00:00
Richard Smith 8e8eeb3243 Add diagnostics for extend impl misuse. (#3721)
To make the implementation simpler, make `PopWithParseNodeIf` return
`pair<NodeId, optional<value>>` rather than `optional<pair<NodeId,
value>>`. While wrapping the whole result in `optional` seems more
principled, it's significantly harder to work with.
2024-02-23 22:07:29 +00:00
Richard Smith eed33c3b8c Redeclaration support for impl declarations. (#3717)
Maintain a mapping from (self type, constraint) to `ImplId` on the
`Impl` value store so that we can perform redeclaration lookup.
2024-02-22 20:26:36 +00:00
Richard Smith b1850920e4 Add diagnostic for impl as outside a class. (#3716) 2024-02-22 20:01:10 +00:00
Richard Smith 14388fe081 Remove unnecessary pop and re-push of same value. (#3715)
We don't need to do this any more after #3691, but I forgot to remove
it.
2024-02-22 08:19:26 +00:00
Jon Ross-Perkins 1bf4dc53d9 Add diagnostic support so that we can just pass in TypeId. (#3695)
Note we may also want to do this with NameId, maybe some other things,
but the TypeId use is pretty broad and repetitive -- I thought I'd start
with it first.
2024-02-09 16:25:23 +00:00
Richard Smith 4d0c3811c9 Add a diagnostic for trying to extend an undefined interface. (#3689) 2024-02-06 22:31:49 +00:00
Richard Smith 5ab26072fd Use the DeclNameStack for impl declarations. (#3691)
They don't have names, but using the DeclNameStack anyway keeps our
behavior more consistent, and keeps track of the enclosing name scope
and the prior state of the scope stack for us.

Depends on #3683.
2024-02-06 22:28:31 +00:00
Richard SmithandJon Ross-Perkins 0e053703f8 Build Impl entity to represent an impl declaration. (#3683)
Collect the contents of an `impl` into a scope, and start doing very
basic checking for `impl` declarations and definitions.

This change adds two new `Id` types to the set of type that `NodeStack`
supports -- `ImplId` and `NameScopeId`.

---------

Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
2024-02-06 18:49:21 +00:00
Richard Smith fdfb1fb5ef Factor the scope stack and lexical lookups out of Check::Context. (#3688) 2024-02-06 00:59:52 +00:00
josh11bandJon Ross-Perkins 03bf22e55e Parse tree for impl that is better for check stage (#3678)
Use two different nodes for "<type> followed by `as`" and "<type>
omitted before `as`, use `self`", so it is easier to determine which
case. Later the second case will push the type id for `self` onto the
node stack, making the two paths more similar.

---------

Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
2024-02-01 22:23:21 +00:00
Richard Smith 9e7a17b1a1 Scaffolding for checking impls. (#3672)
Consume the components of the `impl` declaration, and set up scopes for
the child elements. We don't yet build a representation for the impl
itself.

Also, add an interface type value. This is necessary so that we have a
value for the expression on the right-hand side of `as` in an `impl`.
2024-01-31 22:18:29 +00:00
josh11bandChandler Carruth 48c986f52d Start using typed parse node ids in the check stage (#3547)
Goal is to increase type safety, though more work needs to be done (see
added TODOs).

Note that, after this change, check handlers corresponding to deleted
parse node kinds will no longer compile.

---------

Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
2023-12-29 01:28:09 +00:00
josh11bandJon Ross-Perkins 5f439b842b Parsing impl...as (#3473)
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
2023-12-09 04:04:00 +00:00