Commit Graph
12 Commits
Author SHA1 Message Date
Richard Smith 064123d93f If a SemIR instruction has a braced block and a constant value, print the constant value first. (#3734) 2024-02-29 23:51:32 +00:00
Richard Smith a6f4752a7b Collapse empty braces onto a single line. (#3733)
Don't write out `.members` section at all if it's empty.
2024-02-28 23:21:43 +00:00
Richard Smith 5543602a50 Make namespace formatting more consistent with other declaration block instructions. (#3732)
List names vertically rather than horizontally.
2024-02-28 22:20:37 +00:00
Jon Ross-Perkins 91f0c23124 Provide diagnostic locations for imported namespaces. (#3640)
Building on #3636 which handles the general import case, add special
casing for namespaces. Namespaces can be combined cross-IR, so it's a
little more complex.

The implementation adds import_id to the Namespace instruction as a
reference to find the original using the normal structure. This is
achieved by moving the name_id to NameScope to free up space.

---

I considered a few alternatives...

I considered adding import_id to NameScope, but:

1. It's more consistent with things such as Function or Class that
provide name_id on the info object rather than the instruction.
2. I thought it more likely that there would be more NameScope cases
that might want a name_id rather than the import_id, since ImportRef
will typically be used.

I considered putting the import source (cross-ref IR id + inst id) on
the NameScope versus a separate ImportRef, which seems like the
strongest argument towards the NameScope approach because it removes an
instruction. That just felt inconsistent though, and the overhead of
instruction-per-imported-namespace should be low (theoretically few
namespaces should be used). Plus I feel a bit odd adding two
generally-unused ids to NameScope.

A specialized Namespace structure could also have been created to store
the import_id, but that would add an indirection to the NameScope.
2024-01-24 18:00:32 +00:00
Richard Smith afd194de9d Runtime : name bindings are not constants. (#3639)
Do not create runtime name bindings for `FieldDecl`s even though they're
declared with `:`, so that we can still constant-evaluate references to
fields.
2024-01-23 17:02:08 +00:00
Richard Smith b7c21a7fa7 Add constant evaluation for namespace expressions. (#3612) 2024-01-17 21:12:25 +00:00
Richard Smith 906346cf35 Ensure we evaluate instructions created in uncommon ways. (#3598)
Instructions created by splices during conversion are now evaluated, as
are instructions created in cases where we first create a placeholder
instruction and later replace it by a different instruction.

This also removes the ability to set a parse node and instruction
independently after creating an `InstId`, which could lead to them
accidentally not matching.
2024-01-16 21:28:14 +00:00
Richard Smith d712bf12a6 Remove parse nodes from constants. (#3599)
These instructions are intended to be shared across all uses and so
don't have a meaningful location. So far, only type constants are
shared.
2024-01-13 04:52:25 +00:00
Richard SmithandChandler Carruth a3154356f0 Distinguish between template constants and symbolic constants. (#3595)
This is accomplished by tracking an extra bit on the ID we store in the
constant values table, and propagating that from subexpressions to the
enclosing expression. This extra bit is not yet computed correctly for
types; that will be addressed in later PRs.

---------

Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
2024-01-12 02:56:22 +00:00
Richard Smith 7553d864e1 Very basic support for constant evaluation of expressions. (#3581)
Form a side table with constant values for each instruction. Evaluation
is only supported for a few very simple kinds of instruction for now.
This is not observable outside of the SemIR output, because nothing
depends on expressions having a constant value phase yet.
2024-01-11 23:12:58 +00:00
Jon Ross-PerkinsandRichard Smith cad4605dad Add imports of enclosing scopes. (#3575)
Namespaces are copied, which means also adding their name to the
underlying instruction. It happened not to be done previously; the name
was only in name lookup.

Since the only import supported right now is the default import,
functionality is limited; in the future I'll need to deal with namespace
vs package conflicts.

Tests of namespace imports are under "namespace" -- I figured this would
be best for scaling as more instructions get support.

This also improves some debugging-related output that I was trying to
use while trying to build the support.

---------

Co-authored-by: Richard Smith <richard@metafoo.co.uk>
2024-01-10 17:36:50 +00:00
josh11bandJon Ross-Perkins fada410559 Support declaration modifier keywords (#3412)
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
2023-12-05 22:45:57 +00:00