2020-01-12 22:59:16 -05:00
|
|
|
|
// Abstract semantic graph (ASG) intermediate representation (IR)
|
|
|
|
|
|
//
|
2022-05-03 14:14:29 -04:00
|
|
|
|
// Copyright (C) 2014-2022 Ryan Specialty Group, 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/>.
|
|
|
|
|
|
|
|
|
|
|
|
//! Abstract semantic graph.
|
|
|
|
|
|
//!
|
|
|
|
|
|
//! The [abstract semantic graph][asg] (ASG) is an IR representing the
|
|
|
|
|
|
//! relationship between objects using a directed [graph][].
|
|
|
|
|
|
//! An _object_ is an identifier or expression.
|
|
|
|
|
|
//!
|
|
|
|
|
|
//! Since TAME is a declarative language,
|
|
|
|
|
|
//! the ASG does not represent control flow;
|
|
|
|
|
|
//! instead, it represents the relationship between objects and their
|
|
|
|
|
|
//! dependencies.
|
|
|
|
|
|
//! Control flow is determined solely by the [linker][crate::ld] based on
|
|
|
|
|
|
//! these dependencies.
|
|
|
|
|
|
//!
|
|
|
|
|
|
//! See [`crate::global`] for available index sizes depending on context.
|
|
|
|
|
|
//! For example,
|
|
|
|
|
|
//! a linker may choose to use [`crate::global::ProgIdentSize`];
|
|
|
|
|
|
//!
|
|
|
|
|
|
//!
|
|
|
|
|
|
//! Graph Structure
|
|
|
|
|
|
//! ===============
|
2022-05-19 12:31:37 -04:00
|
|
|
|
//! Each node (vector) in the graph represents an [`Object`],
|
2020-01-12 22:59:16 -05:00
|
|
|
|
//! such as an identifier or an expression.
|
|
|
|
|
|
//! Each directed edge `(A->B)` represents that `A` depends upon `B`.
|
|
|
|
|
|
//!
|
|
|
|
|
|
//! Graphs may contain cycles for recursive functions—that is,
|
|
|
|
|
|
//! TAME's ASG is _not_ a DAG.
|
|
|
|
|
|
//! Mutually recursive functions are therefore represented as
|
|
|
|
|
|
//! [strongly connected components][scc].
|
|
|
|
|
|
//!
|
|
|
|
|
|
//! [asg]: https://en.wikipedia.org/wiki/Abstract_semantic_graph
|
|
|
|
|
|
//! [graph]: https://en.wikipedia.org/wiki/Graph_(discrete_mathematics)
|
|
|
|
|
|
//! [scc]: https://en.wikipedia.org/wiki/Strongly_connected_component
|
|
|
|
|
|
//!
|
|
|
|
|
|
//! Each object may have a number of valid states;
|
2022-05-19 11:17:04 -04:00
|
|
|
|
//! see [`Ident`] for valid object states and transitions.
|
2020-01-12 22:59:16 -05:00
|
|
|
|
//!
|
2020-01-14 16:26:36 -05:00
|
|
|
|
//! Missing Identifiers
|
|
|
|
|
|
//! -------------------
|
|
|
|
|
|
//! Since identifiers in TAME can be defined in any order relative to their
|
|
|
|
|
|
//! dependencies within a source file,
|
|
|
|
|
|
//! it is often the case that a dependency will have to be added to the
|
|
|
|
|
|
//! graph before it is resolved.
|
|
|
|
|
|
//! For example,
|
2022-05-19 11:17:04 -04:00
|
|
|
|
//! [`Asg::add_dep_lookup`] will add an [`Ident::Missing`] to the graph
|
2020-01-14 16:26:36 -05:00
|
|
|
|
//! if either identifier has not yet been declared.
|
2020-01-12 22:59:16 -05:00
|
|
|
|
|
2022-05-11 16:38:59 -04:00
|
|
|
|
mod error;
|
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
|
|
|
|
mod expr;
|
2020-01-12 22:59:16 -05:00
|
|
|
|
mod graph;
|
|
|
|
|
|
mod ident;
|
|
|
|
|
|
mod object;
|
|
|
|
|
|
|
tamer: Refactor asg_builder into obj::xmlo::lower and asg::air
This finally uses `parse` all the way up to aggregation into the ASG, as can
be seen by the mess in `poc`. This will be further simplified---I just need
to get this committed so that I can mentally get it off my plate. I've been
separating this commit into smaller commits, but there's a point where it's
just not worth the effort anymore. I don't like making large changes such
as this one.
There is still work to do here. First, it's worth re-mentioning that
`poc` means "proof-of-concept", and represents things that still need a
proper home/abstraction.
Secondly, `poc` is retrieving the context of two parsers---`LowerContext`
and `Asg`. The latter is desirable, since it's the final aggregation point,
but the former needs to be eliminated; in particular, packages need to be
worked into the ASG so that `found` can be removed.
Recursively loading `xmlo` files still happens in `poc`, but the compiler
will need this as well. Once packages are on the ASG, along with their
state, that responsibility can be generalized as well.
That will then simplify lowering even further, to the point where hopefully
everything has the same shape (once final aggregation has an abstraction),
after which we can then create a final abstraction to concisely stitch
everything together. Right now, Rust isn't able to infer `S` for
`Lower<S, LS>`, which is unfortunate, but we'll be able to help it along
with a more explicit abstraction.
DEV-11864
2022-05-27 13:51:29 -04:00
|
|
|
|
pub mod air;
|
|
|
|
|
|
|
2022-05-11 16:38:59 -04:00
|
|
|
|
pub use error::AsgError;
|
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
|
|
|
|
pub use expr::{Expr, ExprDim, ExprOp};
|
|
|
|
|
|
pub use graph::{Asg, AsgResult, IndexType};
|
2022-05-19 11:05:20 -04:00
|
|
|
|
pub use ident::{
|
2022-05-19 11:17:04 -04:00
|
|
|
|
FragmentText, Ident, IdentKind, Source, TransitionError, TransitionResult,
|
|
|
|
|
|
UnresolvedError,
|
2020-03-16 11:49:41 -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
|
|
|
|
pub use object::{Object, ObjectRef};
|
2020-01-12 22:59:16 -05:00
|
|
|
|
|
|
|
|
|
|
/// Default concrete ASG implementation.
|
2022-05-12 15:44:32 -04:00
|
|
|
|
pub type DefaultAsg = graph::Asg;
|