2020-01-12 22:59:16 -05:00
|
|
|
|
// ASG identifiers
|
|
|
|
|
//
|
2023-01-17 23:09:25 -05:00
|
|
|
|
// Copyright (C) 2014-2023 Ryan Specialty, LLC.
|
2020-03-06 11:05:18 -05:00
|
|
|
|
//
|
|
|
|
|
// This file is part of TAME.
|
2020-01-12 22:59:16 -05:00
|
|
|
|
//
|
|
|
|
|
// This program is free software: you can redistribute it and/or modify
|
|
|
|
|
// it under the terms of the GNU General Public License as published by
|
|
|
|
|
// the Free Software Foundation, either version 3 of the License, or
|
|
|
|
|
// (at your option) any later version.
|
|
|
|
|
//
|
|
|
|
|
// This program is distributed in the hope that it will be useful,
|
|
|
|
|
// but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
// GNU General Public License for more details.
|
|
|
|
|
//
|
|
|
|
|
// You should have received a copy of the GNU General Public License
|
|
|
|
|
// along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
|
2023-01-17 22:58:41 -05:00
|
|
|
|
//! Identifiers (a type of [object](super)).
|
2020-01-12 22:59:16 -05:00
|
|
|
|
|
tamer: asg::air: Root AirIdent operations using AirAggregateCtx
This is the culmination of a great deal of work over the past few
weeks. Indeed, this change has been prototyped a number of different ways
and has lived in a stash of mine, in one form or another, for a few weeks.
This is not done just yet---I have to finish moving the index out of Asg,
and then clean up a little bit more---but this is a significant
simplification of the system. It was very difficult to reason about prior
approaches, and this finally moves toward doing something that I wasn't sure
if I'd be able to do successfully: formalize scope using AirAggregate's
stack and encapsulate indexing as something that is _supplemental_ to the
graph, rather than an integral component of it.
This _does not yet_ index the AirIdent operation on the package itself
because the active state is not part of the stack; that is one of the
remaining changes I still have stashed. It will be needed shortly for
package imports.
This rationale will have to appear in docs, which I intend to write soon,
but: this means that `Asg` contains _resolved_ data and itself has no
concept of scope. The state of the ASG immediately after parsing _can_ be
used to derive what the scope _must_ be (and indeed that's what
`asg::air::test::scope::derive_scopes_from_asg` does), but once we start
performing optimizations, that will no longer be true in all cases.
This means that lexical scope is a property of parsing, which, well, seems
kind of obvious from its name. But the awkwardness was that, if we consider
scope to be purely a parse-time thing---used only to construct the
relationships on the graph and then be discarded---then how do we query for
information on the graph? We'd have to walk the graph in search of an
identifier, which is slow.
But when do we need to do such a thing? For tests, it doesn't matter if
it's a little bit slow, and the graphs aren't all that large. And for
operations like template expansion and optimizations, if they need access to
a particular index, then we'll be sure to generate or provide the
appropriate one. If we need a central database of identifiers for tooling
in the future, we'll create one then. No general-purpose identifier lookup
_is_ actually needed.
And with that, `Asg::lookup_or_missing` is removed. It has been around
since the beginning of the ASG, when the linker was just a prototype, so
it's the end of TAMER's early era as I was trying to discover exactly what I
wanted the ASG to represent.
DEV-13162
2023-05-17 11:57:46 -04:00
|
|
|
|
use super::{prelude::*, Expr, Meta, Pkg, Tpl};
|
2022-05-19 10:09:49 -04:00
|
|
|
|
use crate::{
|
2022-12-15 12:07:58 -05:00
|
|
|
|
diagnose::{Annotate, Diagnostic},
|
2023-01-18 22:52:48 -05:00
|
|
|
|
diagnostic_todo,
|
tamer: f::Functor: New trait
This commit is purposefully coupled with changes that utilize it to
demonstrate that the need for this abstraction has been _derived_, not
forced; TAMER doesn't aim to be functional for the sake of it, since
idiomatic Rust achieves many of its benefits without the formalisms.
But, the formalisms do occasionally help, and this is one such
example. There is other existing code that can be refactored to take
advantage of this style as well.
I do _not_ wish to pull an existing functional dependency into TAMER; I want
to keep these abstractions light, and eliminate them as necessary, as Rust
continues to integrate new features into its core. I also want to be able
to modify the abstractions to suit our particular needs. (This is _not_ a
general recommendation; it's particular to TAMER and to my experience.)
This implementation of `Functor` is one such example. While it is modeled
after Haskell in that it provides `fmap`, the primitive here is instead
`map`, with `fmap` derived from it, since `map` allows for better use of
Rust idioms. Furthermore, it's polymorphic over _trait_ type parameters,
not method, allowing for separate trait impls for different container types,
which can in turn be inferred by Rust and allow for some very concise
mapping; this is particularly important for TAMER because of the disciplined
use of newtypes.
For example, `foo.overwrite(span)` and `foo.overwrite(name)` are both
self-documenting, and better alternatives than, say, `foo.map_span(|_|
span)` and `foo.map_symbol(|_| name)`; the latter are perfectly clear in
what they do, but lack a layer of abstraction, and are verbose. But the
clarity of the _new_ form does rely on either good naming conventions of
arguments, or explicit type annotations using turbofish notation if
necessary.
This will be implemented on core Rust types as appropriate and as
possible. At the time of writing, we do not yet have trait specialization,
and there's too many soundness issues for me to be comfortable enabling it,
so that limits that we can do with something like, say, a generic `Result`,
while also allowing for specialized implementations based on newtypes.
DEV-13160
2023-01-04 12:30:18 -05:00
|
|
|
|
f::Functor,
|
2022-12-15 12:07:58 -05:00
|
|
|
|
fmt::{DisplayWrapper, TtQuote},
|
2022-05-19 10:09:49 -04:00
|
|
|
|
num::{Dim, Dtype},
|
2022-12-15 12:07:58 -05:00
|
|
|
|
parse::{util::SPair, Token},
|
|
|
|
|
span::Span,
|
2022-05-19 10:09:49 -04:00
|
|
|
|
sym::{st, GlobalSymbolResolve, SymbolId},
|
|
|
|
|
};
|
2023-01-17 16:31:13 -05:00
|
|
|
|
use std::fmt::Display;
|
2020-01-12 22:59:16 -05:00
|
|
|
|
|
2023-01-13 15:01:53 -05:00
|
|
|
|
use Ident::*;
|
|
|
|
|
|
2022-05-19 11:05:20 -04:00
|
|
|
|
pub type TransitionResult<T> = Result<T, (T, TransitionError)>;
|
|
|
|
|
|
2023-01-17 16:31:13 -05:00
|
|
|
|
/// An identifier for some object on the [`Asg`].
|
|
|
|
|
///
|
|
|
|
|
/// An identifier can be either _opaque_ declaration,
|
|
|
|
|
/// meaning that it stands in _place_ of a definition,
|
|
|
|
|
/// or _transparent_,
|
|
|
|
|
/// meaning that references to the identifier should "see through" it
|
|
|
|
|
/// and directly reference the object to which it is bound.
|
2022-05-19 11:05:20 -04:00
|
|
|
|
///
|
2023-01-17 16:31:13 -05:00
|
|
|
|
/// Invariants
|
|
|
|
|
/// ==========
|
|
|
|
|
/// The [`Ident`] variants represent object states:
|
2022-05-19 11:05:20 -04:00
|
|
|
|
///
|
|
|
|
|
/// ```text
|
2023-01-13 15:01:53 -05:00
|
|
|
|
/// ,--> ((Transparent))
|
|
|
|
|
/// /
|
|
|
|
|
/// (Missing) -> (Extern) -> ((Opaque)) -> ((IdentFragment)).
|
|
|
|
|
/// \ ^ /
|
|
|
|
|
/// \ / \ /
|
|
|
|
|
/// `--------------------` `------------'
|
2022-05-19 11:05:20 -04:00
|
|
|
|
/// ```
|
2023-01-17 16:31:13 -05:00
|
|
|
|
///
|
|
|
|
|
/// The following invariants must hold with respect to [`Asg`]:
|
|
|
|
|
/// 1. A [`Transparent`] identifier must have _one_ edge to the object
|
|
|
|
|
/// that it describes
|
|
|
|
|
/// (upheld by [`ObjectIndex::<Ident>::bind_definition`]).
|
|
|
|
|
/// 2. All other identifiers must have _zero_ outgoing edges,
|
|
|
|
|
/// since they describe nothing available on the graph.
|
|
|
|
|
/// Since edges can only be added by
|
|
|
|
|
/// [`ObjectIndex::<Ident>::bind_definition`],
|
|
|
|
|
/// and since an [`Ident`] cannot transition away from
|
|
|
|
|
/// [`Transparent`],
|
|
|
|
|
/// this invariant is upheld.
|
2022-05-19 11:05:20 -04:00
|
|
|
|
#[derive(Debug, PartialEq, Clone)]
|
2022-05-19 11:17:04 -04:00
|
|
|
|
pub enum Ident {
|
2023-01-13 15:01:53 -05:00
|
|
|
|
/// An identifier is expected to be declared or defined but is not yet
|
|
|
|
|
/// available.
|
2022-05-19 11:05:20 -04:00
|
|
|
|
///
|
|
|
|
|
/// This variant contains the symbol representing the name of the
|
|
|
|
|
/// expected identifier.
|
2022-12-15 12:07:58 -05:00
|
|
|
|
/// This is important,
|
|
|
|
|
/// since identifiers in TAME may be referenced before they are
|
|
|
|
|
/// defined.
|
|
|
|
|
///
|
|
|
|
|
/// The [`Span`] associated with this missing identifier represents one
|
|
|
|
|
/// of the references to the identifier,
|
|
|
|
|
/// ensuring that there is always some useful information to help
|
|
|
|
|
/// debug missing identifiers.
|
|
|
|
|
/// A reference to this missing identifier ought to have its own span so
|
|
|
|
|
/// that diagnostic messages can direct the user to other instances
|
|
|
|
|
/// where unknown identifiers were referenced.
|
|
|
|
|
Missing(SPair),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
2023-01-13 15:01:53 -05:00
|
|
|
|
/// A resolved opaque identifier without a corresponding definition.
|
2022-05-19 11:05:20 -04:00
|
|
|
|
///
|
|
|
|
|
/// This represents an identifier that has been declared with certain
|
|
|
|
|
/// type information.
|
2022-12-15 12:07:58 -05:00
|
|
|
|
/// An identifier has a single canonical location represented by the
|
|
|
|
|
/// [`SPair`]'s [`Span`].
|
2022-05-19 11:05:20 -04:00
|
|
|
|
///
|
2023-01-13 15:01:53 -05:00
|
|
|
|
/// Opaque identifiers are used when a definition is either not known,
|
|
|
|
|
/// or when the definition is not important.
|
|
|
|
|
/// These identifiers take the _place_ of an object definition on the
|
|
|
|
|
/// graph,
|
|
|
|
|
/// much like a declaration in a header file.
|
|
|
|
|
Opaque(SPair, IdentKind, Source),
|
|
|
|
|
|
|
|
|
|
/// An identifier that has not yet been declared or defined.
|
|
|
|
|
///
|
|
|
|
|
/// Externs are upgraded to [`Ident::Opaque`] once an identifier of
|
2022-05-19 11:05:20 -04:00
|
|
|
|
/// the same name is loaded.
|
|
|
|
|
/// It is an error if the loaded identifier does not have a compatible
|
|
|
|
|
/// [`IdentKind`].
|
|
|
|
|
///
|
2022-12-15 12:07:58 -05:00
|
|
|
|
/// The [`Span`] and [`Source`] of an extern represents the location of
|
|
|
|
|
/// the extern declaration.
|
2022-05-19 11:05:20 -04:00
|
|
|
|
/// Once resolved, however,
|
2022-12-15 12:07:58 -05:00
|
|
|
|
/// both will instead represent the location of the concrete
|
2022-05-19 11:05:20 -04:00
|
|
|
|
/// identifier.
|
2022-12-15 12:07:58 -05:00
|
|
|
|
Extern(SPair, IdentKind, Source),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
2023-01-13 15:01:53 -05:00
|
|
|
|
/// Opaque identifier with associated text.
|
2022-05-19 11:05:20 -04:00
|
|
|
|
///
|
|
|
|
|
/// Code fragments are portions of the target language associated with
|
|
|
|
|
/// an identifier.
|
|
|
|
|
/// They are produced by the compiler and it is the job of the
|
|
|
|
|
/// [linker][crate::ld] to put them into the correct order for the
|
|
|
|
|
/// final executable.
|
2022-12-15 12:07:58 -05:00
|
|
|
|
IdentFragment(SPair, IdentKind, Source, FragmentText),
|
2023-01-13 15:01:53 -05:00
|
|
|
|
|
|
|
|
|
/// A resolved transparent identifier that has a corresponding
|
|
|
|
|
/// definition on the graph.
|
|
|
|
|
///
|
|
|
|
|
/// An identifier is transparent when the system is expected to use the
|
|
|
|
|
/// identifier only as a key for locating its associated object,
|
|
|
|
|
/// "seeing through" the identifier to reference directly the
|
|
|
|
|
/// underlying [`Object`](super::Object).
|
|
|
|
|
/// This is in contrast to [`Ident::Opaque`],
|
|
|
|
|
/// which is only _declared_,
|
|
|
|
|
/// and serves _in place of_ its corresponding definition.
|
|
|
|
|
///
|
|
|
|
|
/// Consequently,
|
|
|
|
|
/// this representation of an identifier is very light,
|
|
|
|
|
/// since dependents are expected to create edges to the
|
|
|
|
|
/// [`Object`](super::Object) it references rather than the identifier
|
|
|
|
|
/// itself;
|
|
|
|
|
/// this is safe since identifiers in TAME are immutable.
|
|
|
|
|
Transparent(SPair),
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
|
|
|
|
|
/// The name of the identifier is not yet known and will be determined
|
|
|
|
|
/// by the lexical value of a metavariable.
|
|
|
|
|
///
|
|
|
|
|
/// This is intended for use by identifiers that will be generated as a
|
|
|
|
|
/// result of template expansion---
|
|
|
|
|
/// it represents the abstract _idea_ of an identifier,
|
|
|
|
|
/// to be made concrete at a later time,
|
|
|
|
|
/// and is not valid outside of a metasyntactic context.
|
|
|
|
|
///
|
|
|
|
|
/// The associated span represents the location that the identifier
|
|
|
|
|
/// was defined,
|
|
|
|
|
/// e.g. within a template body.
|
|
|
|
|
Abstract(Span),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
|
tamer: Initial concept for AIR/ASG Expr
This begins to place expressions on the graph---something that I've been
thinking about for a couple of years now, so it's interesting to finally be
doing it.
This is going to evolve; I want to get some things committed so that it's
clear how I'm moving forward. The ASG makes things a bit awkward for a
number of reasons:
1. I'm dealing with older code where I had a different model of doing
things;
2. It's mutable, rather than the mostly-functional lowering pipeline;
3. We're dealing with an aggregate ever-evolving blob of data (the graph)
rather than a stream of tokens; and
4. We don't have as many type guarantees.
I've shown with the lowering pipeline that I'm able to take a mutable
reference and convert it into something that's both functional and
performant, where I remove it from its container (an `Option`), create a new
version of it, and place it back. Rust is able to optimize away the memcpys
and such and just directly manipulate the underlying value, which is often a
register with all of the inlining.
_But_ this is a different scenario now. The lowering pipeline has a narrow
context. The graph has to keep hitting memory. So we'll see how this
goes. But it's most important to get this working and measure how it
performs; I'm not trying to prematurely optimize. My attempts right now are
for the way that I wish to develop.
Speaking to #4 above, it also sucks that I'm not able to type the
relationships between nodes on the graph. Rather, it's not that I _can't_,
but a project to created a typed graph library is beyond the scope of this
work and would take far too much time. I'll leave that to a personal,
non-work project. Instead, I'm going to have to narrow the type any time
the graph is accessed. And while that sucks, I'm going to do my best to
encapsulate those details to make it as seamless as possible API-wise. The
performance hit of performing the narrowing I'm hoping will be very small
relative to all the business logic going on (a single cache miss is bound to
be far more expensive than many narrowings which are just integer
comparisons and branching)...but we'll see. Introducing branching sucks,
but branch prediction is pretty damn good in modern CPUs.
DEV-13160
2022-12-21 16:47:04 -05:00
|
|
|
|
impl Display for Ident {
|
|
|
|
|
fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
|
|
|
|
|
match self {
|
2023-01-13 15:01:53 -05:00
|
|
|
|
Missing(id) => {
|
tamer: Initial concept for AIR/ASG Expr
This begins to place expressions on the graph---something that I've been
thinking about for a couple of years now, so it's interesting to finally be
doing it.
This is going to evolve; I want to get some things committed so that it's
clear how I'm moving forward. The ASG makes things a bit awkward for a
number of reasons:
1. I'm dealing with older code where I had a different model of doing
things;
2. It's mutable, rather than the mostly-functional lowering pipeline;
3. We're dealing with an aggregate ever-evolving blob of data (the graph)
rather than a stream of tokens; and
4. We don't have as many type guarantees.
I've shown with the lowering pipeline that I'm able to take a mutable
reference and convert it into something that's both functional and
performant, where I remove it from its container (an `Option`), create a new
version of it, and place it back. Rust is able to optimize away the memcpys
and such and just directly manipulate the underlying value, which is often a
register with all of the inlining.
_But_ this is a different scenario now. The lowering pipeline has a narrow
context. The graph has to keep hitting memory. So we'll see how this
goes. But it's most important to get this working and measure how it
performs; I'm not trying to prematurely optimize. My attempts right now are
for the way that I wish to develop.
Speaking to #4 above, it also sucks that I'm not able to type the
relationships between nodes on the graph. Rather, it's not that I _can't_,
but a project to created a typed graph library is beyond the scope of this
work and would take far too much time. I'll leave that to a personal,
non-work project. Instead, I'm going to have to narrow the type any time
the graph is accessed. And while that sucks, I'm going to do my best to
encapsulate those details to make it as seamless as possible API-wise. The
performance hit of performing the narrowing I'm hoping will be very small
relative to all the business logic going on (a single cache miss is bound to
be far more expensive than many narrowings which are just integer
comparisons and branching)...but we'll see. Introducing branching sucks,
but branch prediction is pretty damn good in modern CPUs.
DEV-13160
2022-12-21 16:47:04 -05:00
|
|
|
|
write!(f, "missing identifier {}", TtQuote::wrap(id))
|
|
|
|
|
}
|
2023-01-13 15:01:53 -05:00
|
|
|
|
Opaque(id, kind, _) => {
|
tamer: Initial concept for AIR/ASG Expr
This begins to place expressions on the graph---something that I've been
thinking about for a couple of years now, so it's interesting to finally be
doing it.
This is going to evolve; I want to get some things committed so that it's
clear how I'm moving forward. The ASG makes things a bit awkward for a
number of reasons:
1. I'm dealing with older code where I had a different model of doing
things;
2. It's mutable, rather than the mostly-functional lowering pipeline;
3. We're dealing with an aggregate ever-evolving blob of data (the graph)
rather than a stream of tokens; and
4. We don't have as many type guarantees.
I've shown with the lowering pipeline that I'm able to take a mutable
reference and convert it into something that's both functional and
performant, where I remove it from its container (an `Option`), create a new
version of it, and place it back. Rust is able to optimize away the memcpys
and such and just directly manipulate the underlying value, which is often a
register with all of the inlining.
_But_ this is a different scenario now. The lowering pipeline has a narrow
context. The graph has to keep hitting memory. So we'll see how this
goes. But it's most important to get this working and measure how it
performs; I'm not trying to prematurely optimize. My attempts right now are
for the way that I wish to develop.
Speaking to #4 above, it also sucks that I'm not able to type the
relationships between nodes on the graph. Rather, it's not that I _can't_,
but a project to created a typed graph library is beyond the scope of this
work and would take far too much time. I'll leave that to a personal,
non-work project. Instead, I'm going to have to narrow the type any time
the graph is accessed. And while that sucks, I'm going to do my best to
encapsulate those details to make it as seamless as possible API-wise. The
performance hit of performing the narrowing I'm hoping will be very small
relative to all the business logic going on (a single cache miss is bound to
be far more expensive than many narrowings which are just integer
comparisons and branching)...but we'll see. Introducing branching sucks,
but branch prediction is pretty damn good in modern CPUs.
DEV-13160
2022-12-21 16:47:04 -05:00
|
|
|
|
write!(f, "{kind} identifier {}", TtQuote::wrap(id))
|
|
|
|
|
}
|
2023-01-13 15:01:53 -05:00
|
|
|
|
Extern(id, kind, _) => {
|
tamer: Initial concept for AIR/ASG Expr
This begins to place expressions on the graph---something that I've been
thinking about for a couple of years now, so it's interesting to finally be
doing it.
This is going to evolve; I want to get some things committed so that it's
clear how I'm moving forward. The ASG makes things a bit awkward for a
number of reasons:
1. I'm dealing with older code where I had a different model of doing
things;
2. It's mutable, rather than the mostly-functional lowering pipeline;
3. We're dealing with an aggregate ever-evolving blob of data (the graph)
rather than a stream of tokens; and
4. We don't have as many type guarantees.
I've shown with the lowering pipeline that I'm able to take a mutable
reference and convert it into something that's both functional and
performant, where I remove it from its container (an `Option`), create a new
version of it, and place it back. Rust is able to optimize away the memcpys
and such and just directly manipulate the underlying value, which is often a
register with all of the inlining.
_But_ this is a different scenario now. The lowering pipeline has a narrow
context. The graph has to keep hitting memory. So we'll see how this
goes. But it's most important to get this working and measure how it
performs; I'm not trying to prematurely optimize. My attempts right now are
for the way that I wish to develop.
Speaking to #4 above, it also sucks that I'm not able to type the
relationships between nodes on the graph. Rather, it's not that I _can't_,
but a project to created a typed graph library is beyond the scope of this
work and would take far too much time. I'll leave that to a personal,
non-work project. Instead, I'm going to have to narrow the type any time
the graph is accessed. And while that sucks, I'm going to do my best to
encapsulate those details to make it as seamless as possible API-wise. The
performance hit of performing the narrowing I'm hoping will be very small
relative to all the business logic going on (a single cache miss is bound to
be far more expensive than many narrowings which are just integer
comparisons and branching)...but we'll see. Introducing branching sucks,
but branch prediction is pretty damn good in modern CPUs.
DEV-13160
2022-12-21 16:47:04 -05:00
|
|
|
|
write!(f, "{kind} extern identifier {}", TtQuote::wrap(id))
|
|
|
|
|
}
|
2023-01-13 15:01:53 -05:00
|
|
|
|
IdentFragment(id, kind, _, _) => write!(
|
tamer: Initial concept for AIR/ASG Expr
This begins to place expressions on the graph---something that I've been
thinking about for a couple of years now, so it's interesting to finally be
doing it.
This is going to evolve; I want to get some things committed so that it's
clear how I'm moving forward. The ASG makes things a bit awkward for a
number of reasons:
1. I'm dealing with older code where I had a different model of doing
things;
2. It's mutable, rather than the mostly-functional lowering pipeline;
3. We're dealing with an aggregate ever-evolving blob of data (the graph)
rather than a stream of tokens; and
4. We don't have as many type guarantees.
I've shown with the lowering pipeline that I'm able to take a mutable
reference and convert it into something that's both functional and
performant, where I remove it from its container (an `Option`), create a new
version of it, and place it back. Rust is able to optimize away the memcpys
and such and just directly manipulate the underlying value, which is often a
register with all of the inlining.
_But_ this is a different scenario now. The lowering pipeline has a narrow
context. The graph has to keep hitting memory. So we'll see how this
goes. But it's most important to get this working and measure how it
performs; I'm not trying to prematurely optimize. My attempts right now are
for the way that I wish to develop.
Speaking to #4 above, it also sucks that I'm not able to type the
relationships between nodes on the graph. Rather, it's not that I _can't_,
but a project to created a typed graph library is beyond the scope of this
work and would take far too much time. I'll leave that to a personal,
non-work project. Instead, I'm going to have to narrow the type any time
the graph is accessed. And while that sucks, I'm going to do my best to
encapsulate those details to make it as seamless as possible API-wise. The
performance hit of performing the narrowing I'm hoping will be very small
relative to all the business logic going on (a single cache miss is bound to
be far more expensive than many narrowings which are just integer
comparisons and branching)...but we'll see. Introducing branching sucks,
but branch prediction is pretty damn good in modern CPUs.
DEV-13160
2022-12-21 16:47:04 -05:00
|
|
|
|
f,
|
|
|
|
|
"{kind} identifier {} with compiled fragment",
|
|
|
|
|
TtQuote::wrap(id)
|
|
|
|
|
),
|
2023-01-13 15:01:53 -05:00
|
|
|
|
Transparent(id) => {
|
|
|
|
|
write!(f, "transparent identifier {}", TtQuote::wrap(id))
|
|
|
|
|
}
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
Abstract(_) => {
|
|
|
|
|
write!(f, "pending identifier (to be named during expansion)")
|
|
|
|
|
}
|
tamer: Initial concept for AIR/ASG Expr
This begins to place expressions on the graph---something that I've been
thinking about for a couple of years now, so it's interesting to finally be
doing it.
This is going to evolve; I want to get some things committed so that it's
clear how I'm moving forward. The ASG makes things a bit awkward for a
number of reasons:
1. I'm dealing with older code where I had a different model of doing
things;
2. It's mutable, rather than the mostly-functional lowering pipeline;
3. We're dealing with an aggregate ever-evolving blob of data (the graph)
rather than a stream of tokens; and
4. We don't have as many type guarantees.
I've shown with the lowering pipeline that I'm able to take a mutable
reference and convert it into something that's both functional and
performant, where I remove it from its container (an `Option`), create a new
version of it, and place it back. Rust is able to optimize away the memcpys
and such and just directly manipulate the underlying value, which is often a
register with all of the inlining.
_But_ this is a different scenario now. The lowering pipeline has a narrow
context. The graph has to keep hitting memory. So we'll see how this
goes. But it's most important to get this working and measure how it
performs; I'm not trying to prematurely optimize. My attempts right now are
for the way that I wish to develop.
Speaking to #4 above, it also sucks that I'm not able to type the
relationships between nodes on the graph. Rather, it's not that I _can't_,
but a project to created a typed graph library is beyond the scope of this
work and would take far too much time. I'll leave that to a personal,
non-work project. Instead, I'm going to have to narrow the type any time
the graph is accessed. And while that sucks, I'm going to do my best to
encapsulate those details to make it as seamless as possible API-wise. The
performance hit of performing the narrowing I'm hoping will be very small
relative to all the business logic going on (a single cache miss is bound to
be far more expensive than many narrowings which are just integer
comparisons and branching)...but we'll see. Introducing branching sucks,
but branch prediction is pretty damn good in modern CPUs.
DEV-13160
2022-12-21 16:47:04 -05:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-19 11:17:04 -04:00
|
|
|
|
impl Ident {
|
2023-06-26 15:00:51 -04:00
|
|
|
|
/// Concrete identifier name.
|
|
|
|
|
///
|
|
|
|
|
/// Note: This [`Option`] is in preparation for identifiers that may not
|
|
|
|
|
/// yet have names,
|
|
|
|
|
/// awaiting expansion of a metavariable.
|
|
|
|
|
pub fn name(&self) -> Option<SPair> {
|
2022-05-19 11:05:20 -04:00
|
|
|
|
match self {
|
2023-01-13 15:01:53 -05:00
|
|
|
|
Missing(name)
|
|
|
|
|
| Opaque(name, ..)
|
|
|
|
|
| Extern(name, ..)
|
|
|
|
|
| IdentFragment(name, ..)
|
2023-06-26 15:00:51 -04:00
|
|
|
|
| Transparent(name) => Some(*name),
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
|
|
|
|
|
Abstract(_) => None,
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-12-15 12:07:58 -05:00
|
|
|
|
pub fn span(&self) -> Span {
|
|
|
|
|
match self {
|
2023-01-13 15:01:53 -05:00
|
|
|
|
Missing(name)
|
|
|
|
|
| Opaque(name, ..)
|
|
|
|
|
| Extern(name, ..)
|
|
|
|
|
| IdentFragment(name, ..)
|
|
|
|
|
| Transparent(name) => name.span(),
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
|
|
|
|
|
Abstract(span) => *span,
|
2022-12-15 12:07:58 -05:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-19 11:05:20 -04:00
|
|
|
|
/// Identifier [`IdentKind`].
|
|
|
|
|
///
|
|
|
|
|
/// If the object does not have a kind
|
2022-05-19 11:17:04 -04:00
|
|
|
|
/// (as is the case with [`Ident::Missing`]),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
/// [`None`] is returned.
|
|
|
|
|
pub fn kind(&self) -> Option<&IdentKind> {
|
|
|
|
|
match self {
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
Missing(_) | Transparent(_) | Abstract(_) => None,
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
2023-01-13 15:01:53 -05:00
|
|
|
|
Opaque(_, kind, _)
|
|
|
|
|
| Extern(_, kind, _)
|
|
|
|
|
| IdentFragment(_, kind, _, _) => Some(kind),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Identifier [`Source`].
|
|
|
|
|
///
|
|
|
|
|
/// If the object does not have source information
|
2022-05-19 11:17:04 -04:00
|
|
|
|
/// (as is the case with [`Ident::Extern`]),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
/// [`None`] is returned.
|
|
|
|
|
pub fn src(&self) -> Option<&Source> {
|
|
|
|
|
match self {
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
Missing(_) | Extern(_, _, _) | Transparent(_) | Abstract(_) => None,
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
2023-01-13 15:01:53 -05:00
|
|
|
|
Opaque(_, _, src) | IdentFragment(_, _, src, _) => Some(src),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Identifier [`FragmentText`].
|
|
|
|
|
///
|
|
|
|
|
/// If the object does not have an associated code fragment,
|
|
|
|
|
/// [`None`] is returned.
|
|
|
|
|
pub fn fragment(&self) -> Option<FragmentText> {
|
|
|
|
|
match self {
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
Missing(_)
|
|
|
|
|
| Opaque(_, _, _)
|
|
|
|
|
| Extern(_, _, _)
|
|
|
|
|
| Transparent(_)
|
|
|
|
|
| Abstract(_) => None,
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
2023-01-13 15:01:53 -05:00
|
|
|
|
IdentFragment(_, _, _, text) => Some(*text),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Produce an object representing a missing identifier.
|
|
|
|
|
///
|
|
|
|
|
/// This is the base state for all identifiers.
|
2022-12-15 12:07:58 -05:00
|
|
|
|
/// The [`Span`] associated with the pair should be the span of whatever
|
|
|
|
|
/// reference triggered this declaration;
|
|
|
|
|
/// it will be later replaced with the span of the identifier once
|
|
|
|
|
/// its definition is found.
|
|
|
|
|
pub fn declare(ident: SPair) -> Self {
|
2023-01-13 15:01:53 -05:00
|
|
|
|
Missing(ident)
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Attempt to redeclare an identifier with additional information.
|
|
|
|
|
///
|
2022-05-19 11:17:04 -04:00
|
|
|
|
/// If an existing identifier is an [`Ident::Extern`],
|
2022-05-19 11:05:20 -04:00
|
|
|
|
/// then the declaration will be compared just the same,
|
|
|
|
|
/// but the identifier will be converted from an extern into an
|
|
|
|
|
/// identifier.
|
|
|
|
|
/// When this happens,
|
|
|
|
|
/// the extern is said to be _resolved_.
|
|
|
|
|
///
|
2022-05-19 11:17:04 -04:00
|
|
|
|
/// If a virtual identifier of type [`Ident::IdentFragment`] is
|
2022-05-19 11:05:20 -04:00
|
|
|
|
/// overridden,
|
|
|
|
|
/// then its fragment is cleared
|
2023-01-13 15:01:53 -05:00
|
|
|
|
/// (it returns to a [`Ident::Opaque`])
|
2022-05-19 11:05:20 -04:00
|
|
|
|
/// to make way for the fragment of the override.
|
|
|
|
|
///
|
|
|
|
|
/// Overrides will always have their virtual flag cleared,
|
|
|
|
|
/// even if set.
|
|
|
|
|
/// The compiler will hopefully have done this for us,
|
|
|
|
|
/// since the user may be confused with subsequent
|
|
|
|
|
/// [`TransitionError::NonVirtualOverride`] errors if they try to
|
|
|
|
|
/// override an override.
|
|
|
|
|
///
|
|
|
|
|
/// The kind of identifier cannot change,
|
|
|
|
|
/// but the argument is provided here for convenience so that the
|
|
|
|
|
/// caller does not need to perform such a check itself.
|
|
|
|
|
///
|
|
|
|
|
/// If no extern or virtual override is possible,
|
|
|
|
|
/// an identifier cannot be redeclared and this operation will fail.
|
|
|
|
|
pub fn resolve(
|
|
|
|
|
self,
|
2022-12-15 12:07:58 -05:00
|
|
|
|
span: Span,
|
2022-05-19 11:05:20 -04:00
|
|
|
|
kind: IdentKind,
|
|
|
|
|
mut src: Source,
|
2022-05-19 11:17:04 -04:00
|
|
|
|
) -> TransitionResult<Ident> {
|
2022-05-19 11:05:20 -04:00
|
|
|
|
match self {
|
2023-01-13 15:01:53 -05:00
|
|
|
|
Opaque(name, ref orig_kind, ref orig_src)
|
|
|
|
|
| IdentFragment(name, ref orig_kind, ref orig_src, _)
|
2022-05-19 11:17:04 -04:00
|
|
|
|
if src.override_ =>
|
|
|
|
|
{
|
2022-05-19 11:05:20 -04:00
|
|
|
|
if !orig_src.virtual_ {
|
2022-12-15 12:07:58 -05:00
|
|
|
|
let err = TransitionError::NonVirtualOverride(name, span);
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
|
|
|
|
return Err((self, err));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if orig_kind != &kind {
|
2022-12-15 12:07:58 -05:00
|
|
|
|
let err = TransitionError::VirtualOverrideKind(
|
|
|
|
|
name,
|
|
|
|
|
orig_kind.clone(),
|
tamer: Integrate clippy
This invokes clippy as part of `make check` now, which I had previously
avoided doing (I'll elaborate on that below).
This commit represents the changes needed to resolve all the warnings
presented by clippy. Many changes have been made where I find the lints to
be useful and agreeable, but there are a number of lints, rationalized in
`src/lib.rs`, where I found the lints to be disagreeable. I have provided
rationale, primarily for those wondering why I desire to deviate from the
default lints, though it does feel backward to rationalize why certain lints
ought to be applied (the reverse should be true).
With that said, this did catch some legitimage issues, and it was also
helpful in getting some older code up-to-date with new language additions
that perhaps I used in new code but hadn't gone back and updated old code
for. My goal was to get clippy working without errors so that, in the
future, when others get into TAMER and are still getting used to Rust,
clippy is able to help guide them in the right direction.
One of the reasons I went without clippy for so long (though I admittedly
forgot I wasn't using it for a period of time) was because there were a
number of suggestions that I found disagreeable, and I didn't take the time
to go through them and determine what I wanted to follow. Furthermore, it
was hard to make that judgment when I was new to the language and lacked
the necessary experience to do so.
One thing I would like to comment further on is the use of `format!` with
`expect`, which is also what the diagnostic system convenience methods
do (which clippy does not cover). Because of all the work I've done trying
to understand Rust and looking at disassemblies and seeing what it
optimizes, I falsely assumed that Rust would convert such things into
conditionals in my otherwise-pure code...but apparently that's not the case,
when `format!` is involved.
I noticed that, after making the suggested fix with `get_ident`, Rust
proceeded to then inline it into each call site and then apply further
optimizations. It was also previously invoking the thread lock (for the
interner) unconditionally and invoking the `Display` implementation. That
is not at all what I intended for, despite knowing the eager semantics of
function calls in Rust.
Anyway, possibly more to come on that, I'm just tired of typing and need to
move on. I'll be returning to investigate further diagnostic messages soon.
2023-01-12 10:46:48 -05:00
|
|
|
|
(kind, span),
|
2022-12-15 12:07:58 -05:00
|
|
|
|
);
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
|
|
|
|
return Err((self, err));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Ensure that virtual flags are cleared to prohibit
|
2022-12-15 12:07:58 -05:00
|
|
|
|
// override-overrides.
|
|
|
|
|
// The compiler should do this;
|
|
|
|
|
// this is just an extra layer of defense.
|
2022-05-19 11:05:20 -04:00
|
|
|
|
src.virtual_ = false;
|
|
|
|
|
|
|
|
|
|
// Note that this has the effect of clearing fragments if we
|
2022-12-15 12:07:58 -05:00
|
|
|
|
// originally were in state `Ident::IdentFragment`.
|
2023-01-13 15:01:53 -05:00
|
|
|
|
Ok(Opaque(name.overwrite(span), kind, src))
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
|
2022-12-15 12:07:58 -05:00
|
|
|
|
// If we encountered the override _first_,
|
|
|
|
|
// flip the context by declaring a new identifier and trying
|
|
|
|
|
// to override that.
|
2023-01-13 15:01:53 -05:00
|
|
|
|
Opaque(name, orig_kind, orig_src) if orig_src.override_ => {
|
2022-05-19 11:05:20 -04:00
|
|
|
|
Self::declare(name)
|
2022-12-15 12:07:58 -05:00
|
|
|
|
.resolve(name.span(), kind, src)?
|
|
|
|
|
.resolve(span, orig_kind, orig_src)
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
|
2022-12-15 12:07:58 -05:00
|
|
|
|
// Same as above,
|
|
|
|
|
// but for fragments,
|
|
|
|
|
// we want to keep the _original override_ fragment.
|
2023-01-13 15:01:53 -05:00
|
|
|
|
IdentFragment(name, orig_kind, orig_src, orig_text)
|
2022-05-19 11:17:04 -04:00
|
|
|
|
if orig_src.override_ =>
|
|
|
|
|
{
|
|
|
|
|
Self::declare(name)
|
2022-12-15 12:07:58 -05:00
|
|
|
|
.resolve(name.span(), kind, src)?
|
|
|
|
|
.resolve(span, orig_kind, orig_src)?
|
2022-05-19 11:17:04 -04:00
|
|
|
|
.set_fragment(orig_text)
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-13 15:01:53 -05:00
|
|
|
|
Extern(name, ref orig_kind, _) => {
|
2022-05-19 11:05:20 -04:00
|
|
|
|
if orig_kind != &kind {
|
2022-12-15 12:07:58 -05:00
|
|
|
|
let err = TransitionError::ExternResolution(
|
|
|
|
|
name,
|
|
|
|
|
orig_kind.clone(),
|
|
|
|
|
(kind, span),
|
|
|
|
|
);
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
|
|
|
|
return Err((self, err));
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-13 15:01:53 -05:00
|
|
|
|
Ok(Opaque(name.overwrite(span), kind, src))
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
|
2022-06-23 09:17:57 -04:00
|
|
|
|
// These represent the prologue and epilogue of maps.
|
2023-01-13 15:01:53 -05:00
|
|
|
|
IdentFragment(
|
2022-05-19 11:05:20 -04:00
|
|
|
|
_,
|
|
|
|
|
IdentKind::MapHead
|
|
|
|
|
| IdentKind::MapTail
|
|
|
|
|
| IdentKind::RetMapHead
|
|
|
|
|
| IdentKind::RetMapTail,
|
|
|
|
|
..,
|
|
|
|
|
) => Ok(self),
|
|
|
|
|
|
2023-01-13 15:01:53 -05:00
|
|
|
|
Missing(name) => Ok(Opaque(name.overwrite(span), kind, src)),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
2023-06-26 15:00:51 -04:00
|
|
|
|
// TODO: Remove guards for better exhaustiveness check
|
|
|
|
|
Opaque(name, _, _)
|
|
|
|
|
| IdentFragment(name, _, _, _)
|
|
|
|
|
| Transparent(name) => {
|
|
|
|
|
let err = TransitionError::Redeclare(name, span);
|
2022-05-19 11:05:20 -04:00
|
|
|
|
Err((self, err))
|
|
|
|
|
}
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
|
|
|
|
|
// This really should never happen at the time of writing,
|
|
|
|
|
// since to resolve an identifier it first needs to be located
|
|
|
|
|
// on the graph,
|
|
|
|
|
// and abstract identifiers do not have an indexed name.
|
|
|
|
|
// Does the system now discover identifiers through other means,
|
|
|
|
|
// e.g. by trying to pre-draw edges within template bodies?
|
|
|
|
|
Abstract(abstract_span) => Err((
|
|
|
|
|
self,
|
|
|
|
|
TransitionError::ResolveAbstract(abstract_span, span),
|
|
|
|
|
)),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Assertion to return self if identifier is resolved,
|
|
|
|
|
/// otherwise failing with [`UnresolvedError`].
|
|
|
|
|
///
|
|
|
|
|
/// This simplifies working with identifiers without having to match on
|
|
|
|
|
/// specific variants,
|
|
|
|
|
/// and will continue to work if new variants are added in the
|
|
|
|
|
/// future that are considered to be unresolved.
|
|
|
|
|
///
|
|
|
|
|
/// Since this does not cause a state transition and is useful in
|
|
|
|
|
/// contexts where ownership over the identifier is not possible,
|
|
|
|
|
/// this accepts and returns a reference to the identifier.
|
|
|
|
|
///
|
|
|
|
|
/// At present,
|
2022-05-19 11:17:04 -04:00
|
|
|
|
/// both [`Ident::Missing`] and [`Ident::Extern`] are
|
2022-05-19 11:05:20 -04:00
|
|
|
|
/// considered to be unresolved.
|
2023-06-26 15:00:51 -04:00
|
|
|
|
pub fn resolved(&self) -> Result<(&Ident, SPair), UnresolvedError> {
|
2022-05-19 11:05:20 -04:00
|
|
|
|
match self {
|
2023-01-13 15:01:53 -05:00
|
|
|
|
Missing(name) => Err(UnresolvedError::Missing(*name)),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
2023-01-13 15:01:53 -05:00
|
|
|
|
Extern(name, ref kind, _) => {
|
2022-12-15 12:07:58 -05:00
|
|
|
|
Err(UnresolvedError::Extern(*name, kind.clone()))
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
Abstract(span) => Err(UnresolvedError::Abstract(*span)),
|
|
|
|
|
|
2023-06-26 15:00:51 -04:00
|
|
|
|
Opaque(name, ..)
|
|
|
|
|
| IdentFragment(name, ..)
|
|
|
|
|
| Transparent(name, ..) => Ok((self, *name)),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Resolve identifier against an extern declaration or produce an
|
|
|
|
|
/// extern.
|
|
|
|
|
///
|
|
|
|
|
/// If the existing identifier has an assigned [`IdentKind`],
|
|
|
|
|
/// then it will be compared for equality against the given `kind`.
|
|
|
|
|
/// If it matches,
|
|
|
|
|
/// then the current identifier will be returned as-is.
|
|
|
|
|
/// This represents an extern resolution that occurs when a concrete
|
|
|
|
|
/// identifier is located before an extern that requires it,
|
|
|
|
|
/// or my represent a duplicate (but compatible) extern
|
|
|
|
|
/// declaration.
|
|
|
|
|
///
|
2022-05-19 11:17:04 -04:00
|
|
|
|
/// If no kind is assigned (such as [`Ident::Missing`]),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
/// then a new extern is produced.
|
2022-05-19 11:17:04 -04:00
|
|
|
|
/// See for example [`Ident::Extern`].
|
2022-05-19 11:05:20 -04:00
|
|
|
|
pub fn extern_(
|
|
|
|
|
self,
|
2022-12-15 12:07:58 -05:00
|
|
|
|
span: Span,
|
2022-05-19 11:05:20 -04:00
|
|
|
|
kind: IdentKind,
|
|
|
|
|
src: Source,
|
2022-05-19 11:17:04 -04:00
|
|
|
|
) -> TransitionResult<Ident> {
|
2023-06-26 15:00:51 -04:00
|
|
|
|
match self {
|
|
|
|
|
Missing(name) | Transparent(name) => {
|
|
|
|
|
Ok(Extern(name.overwrite(span), kind, src))
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Opaque(name, ref cur_kind, _)
|
|
|
|
|
| Extern(name, ref cur_kind, _)
|
|
|
|
|
| IdentFragment(name, ref cur_kind, _, _) => {
|
2022-05-19 11:05:20 -04:00
|
|
|
|
if cur_kind != &kind {
|
2022-12-15 12:07:58 -05:00
|
|
|
|
let err = TransitionError::ExternResolution(
|
2023-06-26 15:00:51 -04:00
|
|
|
|
name,
|
2022-12-15 12:07:58 -05:00
|
|
|
|
cur_kind.clone(),
|
|
|
|
|
(kind, span),
|
|
|
|
|
);
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
2023-06-26 15:00:51 -04:00
|
|
|
|
Err((self, err))
|
|
|
|
|
} else {
|
|
|
|
|
// Resolved successfully, so keep what we already have.
|
|
|
|
|
Ok(self)
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
|
|
|
|
|
// See notes on `resolve()` for this arm.
|
|
|
|
|
Abstract(abstract_span) => Err((
|
|
|
|
|
self,
|
|
|
|
|
TransitionError::ResolveAbstract(abstract_span, span),
|
|
|
|
|
)),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Attach a code fragment (compiled text) to an identifier.
|
|
|
|
|
///
|
|
|
|
|
/// This will fail if an identifier already has a fragment,
|
|
|
|
|
/// since only the owner of the identifier should be producing
|
|
|
|
|
/// compiled code.
|
|
|
|
|
/// Note, however, that an identifier's fragment may be cleared under
|
|
|
|
|
/// certain circumstances (such as symbol overrides),
|
|
|
|
|
/// making way for a new fragment to be set.
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
///
|
|
|
|
|
/// Fragments cannot be attached to abstract identifiers,
|
|
|
|
|
/// nor does it make sense to,
|
|
|
|
|
/// since fragment code generation only takes place on expanded
|
|
|
|
|
/// objects.
|
2022-05-19 11:17:04 -04:00
|
|
|
|
pub fn set_fragment(self, text: FragmentText) -> TransitionResult<Ident> {
|
2022-05-19 11:05:20 -04:00
|
|
|
|
match self {
|
2023-01-13 15:01:53 -05:00
|
|
|
|
Opaque(sym, kind, src) => Ok(IdentFragment(sym, kind, src, text)),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
|
|
|
|
// If we get to this point in a properly functioning program (at
|
|
|
|
|
// least as of the time of writing), then we have encountered a
|
|
|
|
|
// fragment for a virtual identifier _after_ we have already
|
|
|
|
|
// encountered the fragment for its _override_. We therefore
|
|
|
|
|
// want to keep the override.
|
|
|
|
|
//
|
|
|
|
|
// If this is not permissable, then we should have already
|
|
|
|
|
// prevented the `resolve` transition before this fragment was
|
|
|
|
|
// encountered.
|
2023-01-13 15:01:53 -05:00
|
|
|
|
IdentFragment(_, _, ref src, ..) if src.override_ => Ok(self),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
2022-06-23 09:17:57 -04:00
|
|
|
|
// These represent the prologue and epilogue of maps.
|
2023-06-26 15:00:51 -04:00
|
|
|
|
//
|
|
|
|
|
// TODO: Is this arm still needed after having eliminated their
|
|
|
|
|
// fragments from xmlo files?
|
2023-01-13 15:01:53 -05:00
|
|
|
|
IdentFragment(
|
2022-05-19 11:05:20 -04:00
|
|
|
|
_,
|
|
|
|
|
IdentKind::MapHead
|
|
|
|
|
| IdentKind::MapTail
|
|
|
|
|
| IdentKind::RetMapHead
|
|
|
|
|
| IdentKind::RetMapTail,
|
|
|
|
|
..,
|
|
|
|
|
) => Ok(self),
|
|
|
|
|
|
2023-06-26 15:00:51 -04:00
|
|
|
|
Missing(name)
|
|
|
|
|
| Extern(name, _, _)
|
|
|
|
|
| IdentFragment(name, _, _, _)
|
|
|
|
|
| Transparent(name) => {
|
2022-12-15 12:07:58 -05:00
|
|
|
|
Err((self, TransitionError::BadFragmentDest(name)))
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
|
|
|
|
|
Abstract(span) => {
|
|
|
|
|
Err((self, TransitionError::AbstractFragmentDest(span)))
|
|
|
|
|
}
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-19 11:17:04 -04:00
|
|
|
|
/// An error attempting to transition from one [`Ident`] state to
|
2022-05-19 11:05:20 -04:00
|
|
|
|
/// another.
|
|
|
|
|
#[derive(Clone, Debug, PartialEq)]
|
|
|
|
|
pub enum TransitionError {
|
|
|
|
|
/// Attempted to redeclare a concrete, non-virtual identifier without an
|
|
|
|
|
/// override.
|
2022-12-15 12:07:58 -05:00
|
|
|
|
Redeclare(SPair, Span),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
|
|
|
|
/// Extern resolution failure.
|
|
|
|
|
///
|
|
|
|
|
/// An extern could not be resolved because the provided identifier had
|
|
|
|
|
/// a type that is incompatible with the extern definition.
|
2022-12-15 12:07:58 -05:00
|
|
|
|
///
|
|
|
|
|
// TODO: Need more granular spans for `IdentKind`.
|
|
|
|
|
ExternResolution(SPair, IdentKind, (IdentKind, Span)),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
|
|
|
|
/// Attempt to override a non-virtual identifier.
|
2022-12-15 12:07:58 -05:00
|
|
|
|
NonVirtualOverride(SPair, Span),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
|
|
|
|
/// Overriding a virtual identifier failed due to an incompatible
|
|
|
|
|
/// [`IdentKind`].
|
2022-12-15 12:07:58 -05:00
|
|
|
|
// TODO: More granular spans for kind.
|
|
|
|
|
VirtualOverrideKind(SPair, IdentKind, (IdentKind, Span)),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
|
|
|
|
/// The provided identifier is not in a state that is permitted to
|
|
|
|
|
/// receive a fragment.
|
|
|
|
|
///
|
2022-05-19 11:17:04 -04:00
|
|
|
|
/// See [`Ident::set_fragment`].
|
2022-12-15 12:07:58 -05:00
|
|
|
|
BadFragmentDest(SPair),
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
|
|
|
|
|
/// Attempted to resolve an abstract identifier.
|
|
|
|
|
///
|
|
|
|
|
/// An abstract identifier must be made to be concrete before any
|
|
|
|
|
/// resolution can occur.
|
|
|
|
|
ResolveAbstract(Span, Span),
|
|
|
|
|
|
|
|
|
|
/// Like [`Self::BadFragmentDest`] but for abstract identifiers without
|
|
|
|
|
/// a name.
|
|
|
|
|
AbstractFragmentDest(Span),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl std::fmt::Display for TransitionError {
|
|
|
|
|
fn fmt(&self, fmt: &mut std::fmt::Formatter) -> std::fmt::Result {
|
2022-12-15 12:07:58 -05:00
|
|
|
|
use TransitionError::*;
|
|
|
|
|
|
2022-05-19 11:05:20 -04:00
|
|
|
|
match self {
|
2022-12-15 12:07:58 -05:00
|
|
|
|
Redeclare(name, _) => write!(
|
2022-05-19 11:05:20 -04:00
|
|
|
|
fmt,
|
2022-12-15 12:07:58 -05:00
|
|
|
|
"cannot redeclare identifier {}",
|
|
|
|
|
TtQuote::wrap(name),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
),
|
|
|
|
|
|
2022-12-15 12:07:58 -05:00
|
|
|
|
ExternResolution(name, expected, (given, _)) => write!(
|
2022-05-19 11:05:20 -04:00
|
|
|
|
fmt,
|
2022-12-15 12:07:58 -05:00
|
|
|
|
"extern {} of type {} is incompatible with type {}",
|
|
|
|
|
TtQuote::wrap(name),
|
|
|
|
|
TtQuote::wrap(expected),
|
|
|
|
|
TtQuote::wrap(given),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
),
|
|
|
|
|
|
2022-12-15 12:07:58 -05:00
|
|
|
|
NonVirtualOverride(name, _) => write!(
|
2022-05-19 11:05:20 -04:00
|
|
|
|
fmt,
|
2022-12-15 12:07:58 -05:00
|
|
|
|
"non-virtual identifier {} cannot be overridden",
|
|
|
|
|
TtQuote::wrap(name),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
),
|
|
|
|
|
|
2022-12-15 12:07:58 -05:00
|
|
|
|
VirtualOverrideKind(name, existing, (given, _)) => write!(
|
2022-05-19 11:05:20 -04:00
|
|
|
|
fmt,
|
2022-12-15 12:07:58 -05:00
|
|
|
|
"virtual identifier {} of type {} cannot be overridden with type {}",
|
|
|
|
|
TtQuote::wrap(name),
|
|
|
|
|
TtQuote::wrap(existing),
|
|
|
|
|
TtQuote::wrap(given),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
),
|
|
|
|
|
|
2022-12-15 12:07:58 -05:00
|
|
|
|
BadFragmentDest(name) => {
|
|
|
|
|
write!(fmt, "bad fragment destination: {}", TtQuote::wrap(name))
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
},
|
|
|
|
|
|
|
|
|
|
ResolveAbstract(_, _) => {
|
|
|
|
|
write!(fmt, "cannot resolve abstract identifier")
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
|
|
|
|
|
AbstractFragmentDest(_) => {
|
|
|
|
|
write!(fmt, "cannot attach fragment to abstract identifier")
|
|
|
|
|
},
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl std::error::Error for TransitionError {
|
|
|
|
|
fn source(&self) -> Option<&(dyn std::error::Error + 'static)> {
|
|
|
|
|
None
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-12-15 12:07:58 -05:00
|
|
|
|
impl Diagnostic for TransitionError {
|
|
|
|
|
fn describe(&self) -> Vec<crate::diagnose::AnnotatedSpan> {
|
|
|
|
|
use TransitionError::*;
|
|
|
|
|
|
|
|
|
|
match self {
|
|
|
|
|
Redeclare(name, sdup) => vec![
|
|
|
|
|
name.note("first declaration was found here"),
|
|
|
|
|
sdup.error(format!("cannot redeclare {}", TtQuote::wrap(name))),
|
|
|
|
|
sdup.help("identifiers in TAME are immutable and can"),
|
|
|
|
|
sdup.help(" only be associated with one definition."),
|
|
|
|
|
],
|
|
|
|
|
|
|
|
|
|
ExternResolution(name, expected, (given, sresolve)) => vec![
|
|
|
|
|
name.note(format!(
|
|
|
|
|
"extern {} declared here with type {}",
|
|
|
|
|
TtQuote::wrap(name),
|
|
|
|
|
TtQuote::wrap(expected),
|
|
|
|
|
)),
|
|
|
|
|
sresolve.error(format!(
|
|
|
|
|
"attempted to resolve extern {} with incompatible type {}",
|
|
|
|
|
TtQuote::wrap(name),
|
|
|
|
|
TtQuote::wrap(given),
|
|
|
|
|
)),
|
|
|
|
|
],
|
|
|
|
|
|
|
|
|
|
// TODO: Does this make a lie out of `Redeclare`'s help?
|
|
|
|
|
NonVirtualOverride(name, soverride) => vec![
|
|
|
|
|
name.note("attempting to override this non-virtual identifier"),
|
|
|
|
|
soverride.error(format!(
|
|
|
|
|
"cannot override {} because the first declaration \
|
|
|
|
|
was not virtual",
|
|
|
|
|
TtQuote::wrap(name),
|
|
|
|
|
)),
|
|
|
|
|
// TODO: let's see what type of help text will be useful
|
|
|
|
|
// once we've decided what is to be done with virtual
|
|
|
|
|
// identifiers generally
|
|
|
|
|
],
|
|
|
|
|
|
|
|
|
|
VirtualOverrideKind(name, orig, (given, soverride)) => vec![
|
|
|
|
|
name.note(format!(
|
|
|
|
|
"attempting to override this identifier of type {}",
|
|
|
|
|
TtQuote::wrap(orig),
|
|
|
|
|
)),
|
|
|
|
|
soverride.error(format!(
|
|
|
|
|
"type of this override is {}, but {} was expected",
|
|
|
|
|
TtQuote::wrap(given),
|
|
|
|
|
TtQuote::wrap(orig),
|
|
|
|
|
)),
|
|
|
|
|
],
|
|
|
|
|
|
|
|
|
|
BadFragmentDest(name) => vec![
|
|
|
|
|
name.internal_error(
|
|
|
|
|
"identifier {} cannot be assigned a text fragment",
|
|
|
|
|
),
|
|
|
|
|
name.help(
|
|
|
|
|
"the term 'text fragment' refers to compiled code from an",
|
|
|
|
|
),
|
|
|
|
|
name.help(" object file; this error should never occur."),
|
|
|
|
|
],
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
|
|
|
|
|
ResolveAbstract(span, resolve_span) => vec![
|
|
|
|
|
span.note("for this abstract identifier"),
|
|
|
|
|
resolve_span.internal_error(
|
|
|
|
|
"attempted to resolve abstract identifier here",
|
|
|
|
|
),
|
|
|
|
|
resolve_span.help(
|
|
|
|
|
"this is a suspicious error that may represent \
|
|
|
|
|
a compiler bug",
|
|
|
|
|
),
|
|
|
|
|
],
|
|
|
|
|
|
|
|
|
|
AbstractFragmentDest(span) => vec![
|
|
|
|
|
span.internal_error(
|
|
|
|
|
"this abstract identifier cannot be assigned a text fragment",
|
|
|
|
|
),
|
|
|
|
|
span.help(
|
|
|
|
|
"the term 'text fragment' refers to compiled code from an \
|
|
|
|
|
object file; this error should never occur."
|
|
|
|
|
),
|
|
|
|
|
],
|
2022-12-15 12:07:58 -05:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-19 11:05:20 -04:00
|
|
|
|
/// Resolved identifier was expected.
|
|
|
|
|
#[derive(Clone, Debug, PartialEq)]
|
|
|
|
|
pub enum UnresolvedError {
|
|
|
|
|
/// Expected identifier is missing and nothing about it is known.
|
2022-12-15 12:07:58 -05:00
|
|
|
|
///
|
|
|
|
|
/// The span represents the first reference to this identifier that
|
|
|
|
|
/// caused it to be added to the graph;
|
|
|
|
|
/// it is not necessarily the _only_ reference.
|
|
|
|
|
/// When reporting errors based on references to unknown identifiers,
|
|
|
|
|
/// keep this in mind to avoid duplicates.
|
|
|
|
|
Missing(SPair),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
|
|
|
|
/// Expected identifier has not yet been resolved with a concrete
|
|
|
|
|
/// definition.
|
2022-12-15 12:07:58 -05:00
|
|
|
|
Extern(SPair, IdentKind),
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
|
|
|
|
|
/// The identifier at the given location is pending expansion and is not
|
|
|
|
|
/// yet a concrete identifier.
|
|
|
|
|
///
|
|
|
|
|
/// These identifiers represent a template for the creation of a future
|
|
|
|
|
/// identifier during template expansion.
|
|
|
|
|
Abstract(Span),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl std::fmt::Display for UnresolvedError {
|
|
|
|
|
fn fmt(&self, fmt: &mut std::fmt::Formatter) -> std::fmt::Result {
|
2022-12-15 12:07:58 -05:00
|
|
|
|
use UnresolvedError::*;
|
|
|
|
|
|
2022-05-19 11:05:20 -04:00
|
|
|
|
match self {
|
2022-12-15 12:07:58 -05:00
|
|
|
|
Missing(name) => {
|
|
|
|
|
write!(fmt, "unknown identifier {}", TtQuote::wrap(name))
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
|
2022-12-15 12:07:58 -05:00
|
|
|
|
Extern(name, kind) => write!(
|
2022-05-19 11:05:20 -04:00
|
|
|
|
fmt,
|
2022-12-15 12:07:58 -05:00
|
|
|
|
"unresolved extern {} of type {}",
|
|
|
|
|
TtQuote::wrap(name),
|
|
|
|
|
TtQuote::wrap(kind),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
),
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
|
|
|
|
|
Abstract(_) => write!(fmt, "abstract (unexpanded) identifier"),
|
2022-05-19 11:05:20 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl std::error::Error for UnresolvedError {
|
|
|
|
|
fn source(&self) -> Option<&(dyn std::error::Error + 'static)> {
|
|
|
|
|
None
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-12-15 12:07:58 -05:00
|
|
|
|
impl Diagnostic for UnresolvedError {
|
|
|
|
|
fn describe(&self) -> Vec<crate::diagnose::AnnotatedSpan> {
|
|
|
|
|
use UnresolvedError::*;
|
|
|
|
|
|
|
|
|
|
match self {
|
|
|
|
|
// TODO: Do we want a single span, or should errors also be
|
|
|
|
|
// thrown for every reference to missing?
|
|
|
|
|
Missing(name) => vec![name.error(format!(
|
|
|
|
|
"identifier {} has not been defined",
|
|
|
|
|
TtQuote::wrap(name),
|
|
|
|
|
))],
|
|
|
|
|
|
|
|
|
|
Extern(name, _kind) => vec![
|
|
|
|
|
name.error(format!(
|
|
|
|
|
"no imported package provided a \
|
|
|
|
|
compatible definition for {}",
|
|
|
|
|
TtQuote::wrap(name),
|
|
|
|
|
)),
|
|
|
|
|
name.help(
|
|
|
|
|
"an extern declares an identifier so that it may be used,"
|
|
|
|
|
),
|
|
|
|
|
name.help(
|
|
|
|
|
" but with the expectation that some imported package will"
|
|
|
|
|
),
|
|
|
|
|
name.help(
|
|
|
|
|
" later provide a concrete definition for it."
|
|
|
|
|
)
|
|
|
|
|
],
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
|
|
|
|
|
// This should not occur under normal circumstances;
|
|
|
|
|
// the user is likely to hit a more helpful and
|
|
|
|
|
// context-specific error before this.
|
|
|
|
|
Abstract(span) => vec![
|
|
|
|
|
span.error("this identifier has not been expanded"),
|
|
|
|
|
span.help(
|
|
|
|
|
"are you using a metavariable outside of a template body?",
|
|
|
|
|
),
|
|
|
|
|
],
|
2022-12-15 12:07:58 -05:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-19 11:05:20 -04:00
|
|
|
|
/// Compiled fragment for identifier.
|
|
|
|
|
///
|
|
|
|
|
/// This represents the text associated with an identifier.
|
|
|
|
|
pub type FragmentText = SymbolId;
|
|
|
|
|
|
2020-01-12 22:59:16 -05:00
|
|
|
|
/// Types of identifiers.
|
|
|
|
|
///
|
|
|
|
|
/// Here, the term _calculation_ refers to a composable expression that
|
|
|
|
|
/// produces a numeric result.
|
|
|
|
|
///
|
2021-11-04 13:20:38 -04:00
|
|
|
|
/// These are derived from [`SymType`][crate::obj::xmlo::SymType]
|
2020-01-12 22:59:16 -05:00
|
|
|
|
/// and will be generalized in the future.
|
2020-03-16 11:49:41 -04:00
|
|
|
|
#[derive(Debug, PartialEq, Eq, Clone)]
|
2020-01-12 22:59:16 -05:00
|
|
|
|
pub enum IdentKind {
|
|
|
|
|
/// Classification generator.
|
|
|
|
|
///
|
|
|
|
|
/// This has the same number of dimensions as its highest-dimension
|
|
|
|
|
/// predicate.
|
|
|
|
|
/// Every [`Class`][IdentKind::Class] has an associated generator.
|
|
|
|
|
Cgen(Dim),
|
|
|
|
|
|
|
|
|
|
/// Boolean classification.
|
|
|
|
|
///
|
|
|
|
|
/// This is an artifact of an ancient system.
|
|
|
|
|
/// The dimensions here refers to the dimensions of the associated
|
|
|
|
|
/// [`Cgen`][IdentKind::Cgen].
|
|
|
|
|
Class(Dim),
|
|
|
|
|
|
|
|
|
|
/// Constant value.
|
2022-05-19 10:09:49 -04:00
|
|
|
|
Const(Dim, Dtype),
|
2020-01-12 22:59:16 -05:00
|
|
|
|
|
|
|
|
|
/// Re-usable encapsulated expression.
|
|
|
|
|
///
|
|
|
|
|
/// Functions are nothing more than expressions that can be re-used with
|
|
|
|
|
/// dynamic values at runtime.
|
|
|
|
|
/// See also [`Lparam`][IdentKind::Lparam].
|
2022-05-19 10:09:49 -04:00
|
|
|
|
Func(Dim, Dtype),
|
2020-01-12 22:59:16 -05:00
|
|
|
|
|
|
|
|
|
/// Generating calculation.
|
|
|
|
|
///
|
|
|
|
|
/// Generators are associated with iterative expressions,
|
|
|
|
|
/// such as sums and products.
|
|
|
|
|
/// They always have a parent [`Rate`][IdentKind::Rate].
|
2022-05-19 10:09:49 -04:00
|
|
|
|
Gen(Dim, Dtype),
|
2020-01-12 22:59:16 -05:00
|
|
|
|
|
|
|
|
|
/// Local (non-global) parameter.
|
|
|
|
|
///
|
|
|
|
|
/// Local parameters are lexically scoped to their parent expression:
|
|
|
|
|
/// - [`Func`][IdentKind::Func], where there exists one per defined
|
|
|
|
|
/// function parameter; and
|
|
|
|
|
/// - `let` expression bindings.
|
|
|
|
|
///
|
|
|
|
|
/// This is not to be confused with the global
|
|
|
|
|
/// [`Param`][IdentKind::Param].
|
2022-05-19 10:09:49 -04:00
|
|
|
|
Lparam(Dim, Dtype),
|
2020-01-12 22:59:16 -05:00
|
|
|
|
|
|
|
|
|
/// Global parameter.
|
|
|
|
|
///
|
|
|
|
|
/// These parameters serve as inputs to the system.
|
|
|
|
|
/// Input values are bound using [`Map`][IdentKind::Map].
|
2022-05-19 10:09:49 -04:00
|
|
|
|
Param(Dim, Dtype),
|
2020-01-12 22:59:16 -05:00
|
|
|
|
|
|
|
|
|
/// Scalar result of a named calculation.
|
|
|
|
|
///
|
|
|
|
|
/// The verb "rate" is historical,
|
|
|
|
|
/// since TAME was developed for insurance rating systems.
|
|
|
|
|
/// This represents a named expression that yields a scalar value.
|
|
|
|
|
///
|
|
|
|
|
/// This serves as a parent to [`Gen`][IdentKind::Gen].
|
2022-05-19 10:09:49 -04:00
|
|
|
|
Rate(Dtype),
|
2020-01-12 22:59:16 -05:00
|
|
|
|
|
|
|
|
|
/// Template definition.
|
|
|
|
|
///
|
|
|
|
|
/// A template is used only at expansion-time and,
|
|
|
|
|
/// unlike most other things in the system,
|
|
|
|
|
/// have no runtime value.
|
|
|
|
|
Tpl,
|
|
|
|
|
|
|
|
|
|
/// User-defined data type.
|
|
|
|
|
///
|
|
|
|
|
/// The only types typically defined are enums and unions of enums.
|
|
|
|
|
/// The type itself has no runtime value,
|
|
|
|
|
/// but each of the enum variants have an associated value of type
|
2022-05-19 10:09:49 -04:00
|
|
|
|
/// [`Dtype`].
|
|
|
|
|
Type(Dtype),
|
2020-01-12 22:59:16 -05:00
|
|
|
|
|
|
|
|
|
/// Input map head (meta identifier generated by compiler for each input
|
|
|
|
|
/// map).
|
|
|
|
|
MapHead,
|
|
|
|
|
|
|
|
|
|
/// Input field→param mapping.
|
|
|
|
|
///
|
|
|
|
|
/// These may only map to [`Param`][IdentKind::Param].
|
|
|
|
|
/// The source data is arbitrary and provided at runtime.
|
|
|
|
|
Map,
|
|
|
|
|
|
|
|
|
|
/// Input map tail (meta symbol generated by compiler for each input
|
|
|
|
|
/// map).
|
|
|
|
|
MapTail,
|
|
|
|
|
|
|
|
|
|
/// Return map head (meta symbol generated by compiler for each return
|
|
|
|
|
/// map).
|
|
|
|
|
RetMapHead,
|
|
|
|
|
|
|
|
|
|
/// Return param→field mapping.
|
|
|
|
|
///
|
|
|
|
|
/// Return mappings export data to calling systems.
|
|
|
|
|
/// They can map back any globally defined numeric expression.
|
|
|
|
|
RetMap,
|
|
|
|
|
|
|
|
|
|
/// Return map tail (meta symbol generated by compiler for each return
|
|
|
|
|
/// map).
|
|
|
|
|
RetMapTail,
|
|
|
|
|
|
|
|
|
|
/// Arbitrary metadata.
|
|
|
|
|
///
|
|
|
|
|
/// This permits the definition of static key/value data that is
|
|
|
|
|
/// compiled into the final executable.
|
|
|
|
|
Meta,
|
|
|
|
|
|
|
|
|
|
/// Rating worksheet (generated by compiler for worksheet packages).
|
|
|
|
|
///
|
|
|
|
|
/// The worksheet exposes intermediate calculation values in a much more
|
|
|
|
|
/// concise form than that of the Summary Page.
|
|
|
|
|
Worksheet,
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-29 23:18:23 -04:00
|
|
|
|
impl IdentKind {
|
|
|
|
|
pub fn as_sym(&self) -> SymbolId {
|
|
|
|
|
match self {
|
tamer: Use `..` for tuple unimportant variant matches
Tbh, I was unaware that this was supported by tuple variants until reading
over the Rustc source code for something. (Which I had previously read, but
I must have missed it.)
This is more proper, in the sense that in a lot of cases we not only care
about how many values a tuple has, but if we explicitly match on them using
`_`, then any time we modify the number of values, it would _break_ any code
doing so. Using this method, we improve maintainability by not causing
breakages under those circumstances.
But, consequently, it's important that we use this only when we _really_
don't care and don't want to be notified by the compiler.
I did not use `..` as a prefix, even where supported, because the intent is
to append additional information to tuples. Consequently, I also used `..`
in places where no additional fields currently exist, since they may in the
future (e.g. introducing `Span` for `IdentObject`).
2021-10-15 12:28:59 -04:00
|
|
|
|
Self::Cgen(..) => st::L_CGEN.as_sym(),
|
|
|
|
|
Self::Class(..) => st::L_CLASS.as_sym(),
|
|
|
|
|
Self::Const(..) => st::L_CONST.as_sym(),
|
|
|
|
|
Self::Func(..) => st::L_FUNC.as_sym(),
|
|
|
|
|
Self::Gen(..) => st::L_GEN.as_sym(),
|
|
|
|
|
Self::Lparam(..) => st::L_LPARAM.as_sym(),
|
|
|
|
|
Self::Param(..) => st::L_PARAM.as_sym(),
|
|
|
|
|
Self::Rate(..) => st::L_RATE.as_sym(),
|
2021-09-29 23:18:23 -04:00
|
|
|
|
Self::Tpl => st::L_TPL.as_sym(),
|
tamer: Use `..` for tuple unimportant variant matches
Tbh, I was unaware that this was supported by tuple variants until reading
over the Rustc source code for something. (Which I had previously read, but
I must have missed it.)
This is more proper, in the sense that in a lot of cases we not only care
about how many values a tuple has, but if we explicitly match on them using
`_`, then any time we modify the number of values, it would _break_ any code
doing so. Using this method, we improve maintainability by not causing
breakages under those circumstances.
But, consequently, it's important that we use this only when we _really_
don't care and don't want to be notified by the compiler.
I did not use `..` as a prefix, even where supported, because the intent is
to append additional information to tuples. Consequently, I also used `..`
in places where no additional fields currently exist, since they may in the
future (e.g. introducing `Span` for `IdentObject`).
2021-10-15 12:28:59 -04:00
|
|
|
|
Self::Type(..) => st::L_TYPE.as_sym(),
|
2021-09-29 23:18:23 -04:00
|
|
|
|
Self::MapHead => st::L_MAP_HEAD.as_sym(),
|
|
|
|
|
Self::Map => st::L_MAP.as_sym(),
|
|
|
|
|
Self::MapTail => st::L_MAP_TAIL.as_sym(),
|
|
|
|
|
Self::RetMapHead => st::L_RETMAP_HEAD.as_sym(),
|
|
|
|
|
Self::RetMap => st::L_RETMAP.as_sym(),
|
|
|
|
|
Self::RetMapTail => st::L_RETMAP_TAIL.as_sym(),
|
|
|
|
|
Self::Meta => st::L_META.as_sym(),
|
|
|
|
|
Self::Worksheet => st::L_WORKSHEET.as_sym(),
|
2020-04-30 14:33:10 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
tamer: asg: Track roots on graph
Previously, since the graph contained only identifiers, discovered roots
were stored in a separate vector and exposed to the caller. This not only
leaked details, but added complexity; this was left over from the
refactoring of the proof-of-concept linker some time ago.
This moves the root management into the ASG itself, mostly, with one item
being left over for now in the asg_builder (eligibility classifications).
There are two roots that were added automatically:
- __yield
- __worksheet
The former has been removed and is now expected to be explicitly mapped in
the return map, which is now enforced with an extern in `core/base`. This
is still special, in the sense that it is explicitly referenced by the
generated code, but there's nothing inherently special about it and I'll
continue to generalize it into oblivion in the future, such that the final
yield is just a convention.
`__worksheet` is the only symbol of type `IdentKind::Worksheet`, and so that
was generalized just as the meta and map entries were.
The goal in the future will be to have this more under the control of the
source language, and to consolodate individual roots under packages, so that
the _actual_ roots are few.
As far as the actual ASG goes: this introduces a single root node that is
used as the sole reference for reachability analysis and topological
sorting. The edges of that root node replace the vector that was removed.
DEV-11864
2022-05-17 10:42:05 -04:00
|
|
|
|
|
|
|
|
|
/// Whether this identifier should be automatically added as a root when
|
|
|
|
|
/// declared.
|
|
|
|
|
pub fn is_auto_root(&self) -> bool {
|
tamer: Integrate clippy
This invokes clippy as part of `make check` now, which I had previously
avoided doing (I'll elaborate on that below).
This commit represents the changes needed to resolve all the warnings
presented by clippy. Many changes have been made where I find the lints to
be useful and agreeable, but there are a number of lints, rationalized in
`src/lib.rs`, where I found the lints to be disagreeable. I have provided
rationale, primarily for those wondering why I desire to deviate from the
default lints, though it does feel backward to rationalize why certain lints
ought to be applied (the reverse should be true).
With that said, this did catch some legitimage issues, and it was also
helpful in getting some older code up-to-date with new language additions
that perhaps I used in new code but hadn't gone back and updated old code
for. My goal was to get clippy working without errors so that, in the
future, when others get into TAMER and are still getting used to Rust,
clippy is able to help guide them in the right direction.
One of the reasons I went without clippy for so long (though I admittedly
forgot I wasn't using it for a period of time) was because there were a
number of suggestions that I found disagreeable, and I didn't take the time
to go through them and determine what I wanted to follow. Furthermore, it
was hard to make that judgment when I was new to the language and lacked
the necessary experience to do so.
One thing I would like to comment further on is the use of `format!` with
`expect`, which is also what the diagnostic system convenience methods
do (which clippy does not cover). Because of all the work I've done trying
to understand Rust and looking at disassemblies and seeing what it
optimizes, I falsely assumed that Rust would convert such things into
conditionals in my otherwise-pure code...but apparently that's not the case,
when `format!` is involved.
I noticed that, after making the suggested fix with `get_ident`, Rust
proceeded to then inline it into each call site and then apply further
optimizations. It was also previously invoking the thread lock (for the
interner) unconditionally and invoking the `Display` implementation. That
is not at all what I intended for, despite knowing the eager semantics of
function calls in Rust.
Anyway, possibly more to come on that, I'm just tired of typing and need to
move on. I'll be returning to investigate further diagnostic messages soon.
2023-01-12 10:46:48 -05:00
|
|
|
|
matches!(
|
|
|
|
|
self,
|
|
|
|
|
Self::Meta | Self::Map | Self::RetMap | Self::Worksheet
|
|
|
|
|
)
|
tamer: asg: Track roots on graph
Previously, since the graph contained only identifiers, discovered roots
were stored in a separate vector and exposed to the caller. This not only
leaked details, but added complexity; this was left over from the
refactoring of the proof-of-concept linker some time ago.
This moves the root management into the ASG itself, mostly, with one item
being left over for now in the asg_builder (eligibility classifications).
There are two roots that were added automatically:
- __yield
- __worksheet
The former has been removed and is now expected to be explicitly mapped in
the return map, which is now enforced with an extern in `core/base`. This
is still special, in the sense that it is explicitly referenced by the
generated code, but there's nothing inherently special about it and I'll
continue to generalize it into oblivion in the future, such that the final
yield is just a convention.
`__worksheet` is the only symbol of type `IdentKind::Worksheet`, and so that
was generalized just as the meta and map entries were.
The goal in the future will be to have this more under the control of the
source language, and to consolodate individual roots under packages, so that
the _actual_ roots are few.
As far as the actual ASG goes: this introduces a single root node that is
used as the sole reference for reachability analysis and topological
sorting. The edges of that root node replace the vector that was removed.
DEV-11864
2022-05-17 10:42:05 -04:00
|
|
|
|
}
|
2020-04-30 14:33:10 -04:00
|
|
|
|
}
|
|
|
|
|
|
2020-03-24 16:28:22 -04:00
|
|
|
|
impl std::fmt::Display for IdentKind {
|
|
|
|
|
/// Format identifier type for display to the user.
|
|
|
|
|
///
|
|
|
|
|
/// TODO: We have not yet finalized how we will represent types in the
|
|
|
|
|
/// new type system,
|
|
|
|
|
/// so for now this just uses a syntax similar to Rust.
|
|
|
|
|
fn fmt(&self, fmt: &mut std::fmt::Formatter) -> std::fmt::Result {
|
2021-09-29 23:18:23 -04:00
|
|
|
|
let name = self.as_sym().lookup_str();
|
2020-04-30 14:33:10 -04:00
|
|
|
|
|
2020-03-24 16:28:22 -04:00
|
|
|
|
match self {
|
|
|
|
|
Self::Cgen(dim) => {
|
2022-05-19 10:09:49 -04:00
|
|
|
|
write!(fmt, "{}[{}; {}]", name, Dtype::Boolean, dim)
|
2020-03-24 16:28:22 -04:00
|
|
|
|
}
|
|
|
|
|
Self::Class(dim) => {
|
2022-05-19 10:09:49 -04:00
|
|
|
|
write!(fmt, "{}[{}; {}]", name, Dtype::Boolean, dim)
|
2020-04-30 14:33:10 -04:00
|
|
|
|
}
|
|
|
|
|
Self::Const(dim, dtype) => {
|
|
|
|
|
write!(fmt, "{}[{}; {}]", name, dtype, dim)
|
|
|
|
|
}
|
|
|
|
|
Self::Func(dim, dtype) => {
|
|
|
|
|
write!(fmt, "{}[{}; {}]", name, dtype, dim)
|
|
|
|
|
}
|
|
|
|
|
Self::Gen(dim, dtype) => {
|
|
|
|
|
write!(fmt, "{}[{}; {}]", name, dtype, dim)
|
2020-03-24 16:28:22 -04:00
|
|
|
|
}
|
|
|
|
|
Self::Lparam(dim, dtype) => {
|
2020-04-30 14:33:10 -04:00
|
|
|
|
write!(fmt, "{}[{}; {}]", name, dtype, dim)
|
|
|
|
|
}
|
|
|
|
|
Self::Param(dim, dtype) => {
|
|
|
|
|
write!(fmt, "{}[{}; {}]", name, dtype, dim)
|
2020-03-24 16:28:22 -04:00
|
|
|
|
}
|
2020-04-30 14:33:10 -04:00
|
|
|
|
Self::Rate(dtype) => write!(fmt, "{}[{}; 0]", name, dtype),
|
|
|
|
|
Self::Type(dtype) => write!(fmt, "{}[{}]", name, dtype),
|
|
|
|
|
_ => write!(fmt, "{}", name),
|
2020-03-24 16:28:22 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2022-05-19 11:05:20 -04:00
|
|
|
|
|
|
|
|
|
/// Metadata about the source of an object.
|
|
|
|
|
///
|
|
|
|
|
/// This contains information from the symbol table that does not belong on
|
|
|
|
|
/// [`IdentKind`],
|
|
|
|
|
/// since that stores _type_ information.
|
|
|
|
|
///
|
|
|
|
|
/// TODO: This does not currently store byte offsets within the source file
|
|
|
|
|
/// since the original XSLT-based compiler did not have that capability;
|
|
|
|
|
/// this will provide that information in the future.
|
|
|
|
|
#[derive(Debug, Default, PartialEq, Clone)]
|
|
|
|
|
pub struct Source {
|
|
|
|
|
/// Name of package containing reference to this object.
|
|
|
|
|
pub pkg_name: Option<SymbolId>,
|
|
|
|
|
|
|
|
|
|
/// Relative path to the source of this object,
|
|
|
|
|
/// if not present in the current package.
|
|
|
|
|
pub src: Option<SymbolId>,
|
|
|
|
|
|
|
|
|
|
/// The identifier from which this one is derived.
|
|
|
|
|
///
|
|
|
|
|
/// See [`IdentKind`] for more information on parents.
|
|
|
|
|
/// For example,
|
|
|
|
|
/// a [`IdentKind::Cgen`] always has a parent [`IdentKind::Class`].
|
|
|
|
|
pub parent: Option<SymbolId>,
|
|
|
|
|
|
|
|
|
|
/// Child identifier associated with this identifier.
|
|
|
|
|
///
|
|
|
|
|
/// For [`IdentKind::Class`],
|
|
|
|
|
/// this represents an associated [`IdentKind::Cgen`].
|
|
|
|
|
pub yields: Option<SymbolId>,
|
|
|
|
|
|
|
|
|
|
/// User-friendly identifier description.
|
|
|
|
|
///
|
|
|
|
|
/// This is used primarily by [`IdentKind::Class`] and
|
|
|
|
|
/// [`IdentKind::Gen`].
|
|
|
|
|
pub desc: Option<SymbolId>,
|
|
|
|
|
|
|
|
|
|
/// Whether this identifier was generated by the compiler.
|
|
|
|
|
///
|
|
|
|
|
/// A generated identifier is representative of an internal
|
|
|
|
|
/// implementation detail that should remain encapsulated from the
|
|
|
|
|
/// user and is subject to change over time.
|
|
|
|
|
///
|
|
|
|
|
/// Identifiers created by templates are not considered to be generated.
|
|
|
|
|
pub generated: bool,
|
|
|
|
|
|
|
|
|
|
/// Related identifiers.
|
|
|
|
|
///
|
|
|
|
|
/// These data represent a kluge created to add additional symbol
|
|
|
|
|
/// information in two different contexts:
|
|
|
|
|
///
|
|
|
|
|
/// - [`IdentKind::Map`] includes the name of the source field; and
|
|
|
|
|
/// - [`IdentKind::Func`] lists params in order (so that the compiler
|
|
|
|
|
/// knows application order).
|
|
|
|
|
///
|
|
|
|
|
/// TODO: We have `parent`, `yields`, and `from`.
|
|
|
|
|
/// We should begin to consolodate.
|
|
|
|
|
pub from: Option<SymbolId>,
|
|
|
|
|
|
|
|
|
|
/// Whether identifier is virtual (can be overridden).
|
|
|
|
|
///
|
|
|
|
|
/// This feature adds complexity and will ideally be removed in the
|
|
|
|
|
/// future.
|
|
|
|
|
///
|
|
|
|
|
/// See also [`override`][Source::override_].
|
|
|
|
|
pub virtual_: bool,
|
|
|
|
|
|
|
|
|
|
/// Whether identifier overrides a virtual identifier.
|
|
|
|
|
///
|
|
|
|
|
/// This feature adds complexity and will ideally be removed in the
|
|
|
|
|
/// future.
|
|
|
|
|
///
|
|
|
|
|
/// See also [`virtual_`][Source::virtual_].
|
|
|
|
|
pub override_: bool,
|
|
|
|
|
}
|
|
|
|
|
|
2023-02-25 23:56:05 -05:00
|
|
|
|
object_rel! {
|
2023-02-03 15:53:50 -05:00
|
|
|
|
/// Identifiers are either transparent
|
|
|
|
|
/// (bound to a definition)
|
|
|
|
|
/// or opaque.
|
|
|
|
|
/// If transparent,
|
|
|
|
|
/// then the identifier represents a definition,
|
|
|
|
|
/// and is therefore a root to that definition.
|
|
|
|
|
///
|
|
|
|
|
/// Opaque identifiers at the time of writing are used by the linker
|
|
|
|
|
/// which does not reason about cross edges
|
|
|
|
|
/// (again at the time of writing).
|
2023-04-28 14:33:48 -04:00
|
|
|
|
///
|
|
|
|
|
/// Identifiers representing functions are able to produce cycles,
|
|
|
|
|
/// representing recursion.
|
|
|
|
|
/// This is a legacy feature expected to be removed in the future;
|
|
|
|
|
/// see [`ObjectRel::can_recurse`] for more information.
|
2023-02-25 23:56:05 -05:00
|
|
|
|
Ident -> {
|
|
|
|
|
tree Ident,
|
|
|
|
|
tree Expr,
|
2023-02-28 15:31:49 -05:00
|
|
|
|
tree Tpl,
|
2023-03-23 00:04:53 -04:00
|
|
|
|
tree Meta,
|
2023-04-28 14:33:48 -04:00
|
|
|
|
} can_recurse(ident) if matches!(ident.kind(), Some(IdentKind::Func(..)))
|
2023-01-31 20:54:03 -05:00
|
|
|
|
}
|
|
|
|
|
|
2023-01-17 16:31:13 -05:00
|
|
|
|
impl ObjectIndex<Ident> {
|
2023-04-18 14:05:01 -04:00
|
|
|
|
/// Declare a concrete identifier.
|
|
|
|
|
///
|
|
|
|
|
/// An identifier declaration is similar to a declaration in a header
|
|
|
|
|
/// file in a language like C,
|
|
|
|
|
/// describing the structure of the identifier.
|
|
|
|
|
/// Once declared,
|
|
|
|
|
/// this information cannot be changed.
|
|
|
|
|
///
|
|
|
|
|
/// Identifiers are uniquely identified by a [`SPair`] `name`.
|
|
|
|
|
/// If an identifier of the same `name` already exists,
|
|
|
|
|
/// then the provided declaration is compared against the existing
|
|
|
|
|
/// declaration---should
|
|
|
|
|
/// they be incompatible,
|
|
|
|
|
/// then the operation will fail;
|
|
|
|
|
/// otherwise,
|
|
|
|
|
/// the existing identifier will be returned.
|
|
|
|
|
///
|
|
|
|
|
/// If a concrete identifier has already been declared,
|
|
|
|
|
/// then extern declarations will be compared and,
|
|
|
|
|
/// if compatible,
|
|
|
|
|
/// the identifier will be immediately _resolved_ and the object
|
|
|
|
|
/// on the graph will not be altered.
|
|
|
|
|
/// Resolution will otherwise fail in error.
|
|
|
|
|
///
|
|
|
|
|
/// For more information on state transitions that can occur when
|
|
|
|
|
/// redeclaring an identifier that already exists,
|
|
|
|
|
/// see [`Ident::resolve`].
|
|
|
|
|
///
|
|
|
|
|
/// A successful declaration will add an identifier to the graph
|
|
|
|
|
/// and return an [`ObjectIndex`] reference.
|
|
|
|
|
pub fn declare(
|
|
|
|
|
self,
|
|
|
|
|
asg: &mut Asg,
|
|
|
|
|
name: SPair,
|
|
|
|
|
kind: IdentKind,
|
|
|
|
|
src: Source,
|
|
|
|
|
) -> Result<ObjectIndex<Ident>, AsgError> {
|
|
|
|
|
let is_auto_root = kind.is_auto_root();
|
|
|
|
|
|
|
|
|
|
self.try_map_obj(asg, |obj| obj.resolve(name.span(), kind, src))
|
|
|
|
|
.map_err(Into::into)
|
|
|
|
|
.map(|ident| {
|
|
|
|
|
is_auto_root.then(|| self.root(asg));
|
|
|
|
|
ident
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Declare an abstract identifier.
|
|
|
|
|
///
|
|
|
|
|
/// See [`Ident::extern_`] and [`Ident::resolve`] for more information.
|
|
|
|
|
pub fn declare_extern(
|
|
|
|
|
self,
|
|
|
|
|
asg: &mut Asg,
|
|
|
|
|
name: SPair,
|
|
|
|
|
kind: IdentKind,
|
|
|
|
|
src: Source,
|
|
|
|
|
) -> Result<Self, AsgError> {
|
|
|
|
|
self.try_map_obj(asg, |obj| obj.extern_(name.span(), kind, src))
|
|
|
|
|
.map_err(Into::into)
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-17 16:31:13 -05:00
|
|
|
|
/// Bind an identifier to a `definition`,
|
|
|
|
|
/// making it [`Transparent`].
|
|
|
|
|
///
|
|
|
|
|
/// If an identifier is successfully bound,
|
|
|
|
|
/// then an edge will be added to `definition`.
|
|
|
|
|
/// An edge will _not_ be added if there is an error in this operation.
|
|
|
|
|
///
|
|
|
|
|
/// If an identifier is already [`Transparent`],
|
|
|
|
|
/// then it is already defined and this operation will result in an
|
|
|
|
|
/// [`AsgError::IdentRedefine`] error.
|
|
|
|
|
pub fn bind_definition<O: ObjectKind>(
|
|
|
|
|
self,
|
|
|
|
|
asg: &mut Asg,
|
2023-02-07 10:23:48 -05:00
|
|
|
|
id: SPair,
|
2023-01-17 16:31:13 -05:00
|
|
|
|
definition: ObjectIndex<O>,
|
|
|
|
|
) -> Result<ObjectIndex<Ident>, AsgError>
|
|
|
|
|
where
|
|
|
|
|
Ident: ObjectRelTo<O>,
|
|
|
|
|
{
|
|
|
|
|
let my_span = self.into();
|
|
|
|
|
|
tamer: asg::graph::object::ident::ObjectIndex::<Ident>: No edge reassignment yet
I'm spending a lot of time considering how the future system will work,
which is complicating the needs of the system now, which is to re-output the
source XML so that we can selectively start to replace things.
So I'm going to punt on this.
I was also planning out how that edge reassignment out to work, along with
traits to try to enforce it, and that is also complicated, so I may wind up
wanting to leave them in the end, or handling this
differently. Specifically, I'll want to know how `value-of` expressions are
going to work on the graph first, since its target is going to be dynamic
and therefore not knowable at compile-time. (Rather, I know how I want to
make them work, but I want to observe that working in practice first.)
DEV-13597
2023-01-19 15:55:27 -05:00
|
|
|
|
// TODO: Should we move all incoming edges to `definition`?
|
|
|
|
|
// This will complicate re-outputting source XML,
|
|
|
|
|
// but may simplify other aspects of the system.
|
|
|
|
|
// Perhaps wait until this is needed.
|
2023-01-17 16:31:13 -05:00
|
|
|
|
self.try_map_obj(asg, |ident| match ident {
|
|
|
|
|
Transparent(id) => {
|
|
|
|
|
Err((ident, AsgError::IdentRedefine(id, my_span)))
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-18 22:52:48 -05:00
|
|
|
|
Opaque(id, ..) | IdentFragment(id, ..) | Extern(id, ..) => {
|
|
|
|
|
diagnostic_todo!(
|
|
|
|
|
vec![
|
|
|
|
|
id.note("must resolve definition against declaration"),
|
|
|
|
|
my_span.error(
|
|
|
|
|
"attempting to provide a definition for prior \
|
|
|
|
|
declaration"
|
|
|
|
|
),
|
|
|
|
|
my_span.help(
|
|
|
|
|
"this identifier was previously declared and so \
|
|
|
|
|
its definition needs to be checked for \
|
|
|
|
|
compatibility with that declaration"
|
|
|
|
|
)
|
|
|
|
|
],
|
|
|
|
|
"resolve opaque declaration {} to definition",
|
|
|
|
|
TtQuote::wrap(id),
|
|
|
|
|
)
|
|
|
|
|
}
|
2023-01-17 16:31:13 -05:00
|
|
|
|
|
tamer: nir: Interpolate concrete binds into abstract binds
This introduces the notion of an abstract identifier, where the previous
identifiers are concrete. This serves as a compromise to either introducing
a new object type (another `Ident`), or having every `Ident` name be defined
by a `Meta` edge, which would bloat the graph significantly.
This change causes interpolation within a bind context to desugar into a new
`BindIdentAbstract` token, but AIR will throw an error if it encounters it
for now; that implementation will come soon.
This does not yet handle non-interpolation cases,
e.g. `<classify as="@foo@">`. This is a well-established shorthand for
`as="{@foo@}"`, but is unfortunately ambiguous in the context of
metavariable definitions (template parameters). This language ambiguity
will have to be handled here, and will have to fall back to today's behavior
of assuming concrete in that `param/@name` context but abstract every else,
unless of course interpolation is triggered using `{}` to disambiguate (as
in `<param name="{@foo@}"`).
I was going to handle the short-hand meta binding case as part of
interpolation, but I decided it may be appropriate for its own lowering
operation, since it is intended to work regardless of whether interpolation
takes place; it's a _translation_ of a binding into an abstract one, and it
can clearly delineate the awkward syntactic rules that we have to inherit,
as mentioned above.
DEV-13163
2023-06-27 12:37:44 -04:00
|
|
|
|
// e.g. in a template body
|
|
|
|
|
Abstract(span) => diagnostic_todo!(
|
|
|
|
|
vec![span.note("abstract defintion bind here")],
|
|
|
|
|
"bind definition to abstract identifier",
|
|
|
|
|
),
|
|
|
|
|
|
2023-01-17 16:31:13 -05:00
|
|
|
|
// We are okay to proceed to add an edge to the `definition`.
|
2023-02-07 10:23:48 -05:00
|
|
|
|
// Discard the original span
|
|
|
|
|
// (which is the location of the first reference _to_ this
|
|
|
|
|
// identifier before it was defined),
|
|
|
|
|
// and use the newly provided `id` and its span.
|
|
|
|
|
Missing(_) => Ok(Transparent(id)),
|
2023-01-17 16:31:13 -05:00
|
|
|
|
})
|
tamer: asg::graph: Formalize dynamic relationships (edges)
The `TreePreOrderDfs` iterator needed to expose additional edge context to
the caller (specifically, the `Span`). This was getting a bit messy, so
this consolodates everything into a new `DynObjectRel`, which also
emphasizes that it is in need of narrowing.
Packing everything up like that also allows us to return more information to
the caller without complicating the API, since the caller does not need to
be concerned with all of those values individually.
Depth is kept separate, since that is a property of the traversal and is not
stored on the graph. (Rather, it _is_ a property of the graph, but it's not
calculated until traversal. But, depth will also vary for a given node
because of cross edges, and so we cannot store any concrete depth on the
graph for a given node. Not even a canonical one, because once we start
doing inlining and common subexpression elimination, there will be shared
edges that are _not_ cross edges (the node is conceptually part of _both_
trees). Okay, enough of this rambling parenthetical.)
DEV-13708
2023-02-09 13:11:27 -05:00
|
|
|
|
.map(|ident_oi| ident_oi.add_edge_to(asg, definition, None))
|
2023-01-17 16:31:13 -05:00
|
|
|
|
}
|
2023-01-23 15:49:25 -05:00
|
|
|
|
|
2023-04-18 14:05:01 -04:00
|
|
|
|
/// Set the fragment associated with a concrete identifier.
|
|
|
|
|
///
|
|
|
|
|
/// Fragments are intended for use by the [linker][crate::ld].
|
|
|
|
|
/// For more information,
|
|
|
|
|
/// see [`Ident::set_fragment`].
|
|
|
|
|
pub fn set_fragment(
|
|
|
|
|
self,
|
|
|
|
|
asg: &mut Asg,
|
|
|
|
|
text: SymbolId,
|
|
|
|
|
) -> Result<Self, AsgError> {
|
|
|
|
|
self.try_map_obj(asg, |obj| obj.set_fragment(text))
|
|
|
|
|
.map_err(Into::into)
|
|
|
|
|
}
|
|
|
|
|
|
2023-04-05 10:45:54 -04:00
|
|
|
|
/// Look up the definition that this identifier binds to,
|
|
|
|
|
/// if any.
|
|
|
|
|
///
|
|
|
|
|
/// See [`Self::bind_definition`].
|
|
|
|
|
pub fn definition<O: ObjectRelFrom<Ident> + ObjectRelatable>(
|
|
|
|
|
&self,
|
|
|
|
|
asg: &Asg,
|
|
|
|
|
) -> Option<ObjectIndex<O>> {
|
|
|
|
|
self.edges(asg).find_map(ObjectRel::narrow)
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-23 15:49:25 -05:00
|
|
|
|
/// Whether this identifier is bound to the object represented by `oi`.
|
|
|
|
|
///
|
|
|
|
|
/// To bind an identifier,
|
|
|
|
|
/// see [`Self::bind_definition`].
|
2023-02-03 15:53:50 -05:00
|
|
|
|
pub fn is_bound_to<O: ObjectRelFrom<Ident> + ObjectRelatable>(
|
2023-01-23 15:49:25 -05:00
|
|
|
|
&self,
|
|
|
|
|
asg: &Asg,
|
|
|
|
|
oi: ObjectIndex<O>,
|
|
|
|
|
) -> bool {
|
|
|
|
|
self.edges(asg).find_map(ObjectRel::narrow) == Some(oi)
|
|
|
|
|
}
|
2023-01-31 16:37:25 -05:00
|
|
|
|
|
2023-03-23 00:04:53 -04:00
|
|
|
|
/// Whether this identifier is bound to an object of kind `O`.
|
|
|
|
|
///
|
|
|
|
|
/// To bind an identifier,
|
|
|
|
|
/// see [`Self::bind_definition`].
|
|
|
|
|
pub fn is_bound_to_kind<O: ObjectRelFrom<Ident>>(&self, asg: &Asg) -> bool {
|
|
|
|
|
self.edges_filtered::<O>(asg).next().is_some()
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-31 16:37:25 -05:00
|
|
|
|
/// The source package defining this identifier,
|
|
|
|
|
/// if known.
|
|
|
|
|
pub fn src_pkg(&self, asg: &Asg) -> Option<ObjectIndex<Pkg>> {
|
|
|
|
|
self.incoming_edges_filtered(asg).next()
|
|
|
|
|
}
|
2023-04-18 14:05:01 -04:00
|
|
|
|
|
|
|
|
|
/// Declare that `oi_dep` is an opaque dependency of `self`.
|
|
|
|
|
pub fn add_opaque_dep(
|
|
|
|
|
&self,
|
|
|
|
|
asg: &mut Asg,
|
|
|
|
|
oi_dep: ObjectIndex<Ident>,
|
|
|
|
|
) -> Self {
|
|
|
|
|
self.add_edge_to(asg, oi_dep, None)
|
|
|
|
|
}
|
2023-06-26 15:00:51 -04:00
|
|
|
|
|
|
|
|
|
/// Retrieve either the concrete name of the identifier or the name of
|
|
|
|
|
/// the metavariable that will be used to produce it.
|
|
|
|
|
pub fn name_or_meta(&self, asg: &Asg) -> SPair {
|
|
|
|
|
let ident = self.resolve(asg);
|
|
|
|
|
|
|
|
|
|
ident.name().unwrap_or_else(|| {
|
|
|
|
|
diagnostic_todo!(
|
|
|
|
|
vec![ident.span().internal_error("for this abstract ident")],
|
|
|
|
|
"metavariable lookup not yet supported",
|
|
|
|
|
)
|
|
|
|
|
})
|
|
|
|
|
}
|
2023-01-17 16:31:13 -05:00
|
|
|
|
}
|
|
|
|
|
|
2022-05-19 11:05:20 -04:00
|
|
|
|
#[cfg(test)]
|
2022-12-13 22:43:39 -05:00
|
|
|
|
mod test;
|