2021-08-13 14:59:25 -04:00
|
|
|
|
// Source spans
|
|
|
|
|
//
|
2023-01-17 23:09:25 -05:00
|
|
|
|
// Copyright (C) 2014-2023 Ryan Specialty, LLC.
|
2021-08-13 14:59:25 -04:00
|
|
|
|
//
|
|
|
|
|
// This file is part of TAME.
|
|
|
|
|
//
|
|
|
|
|
// 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/>.
|
|
|
|
|
|
|
|
|
|
//! Mapping to source input byte intervals.
|
|
|
|
|
//!
|
|
|
|
|
//! A [`Span`] is a mapping to a byte interval within a source file,
|
|
|
|
|
//! representing primarily where some IR entity originated.
|
|
|
|
|
//! This underpins the diagnostic system,
|
|
|
|
|
//! intended to:
|
|
|
|
|
//!
|
|
|
|
|
//! 1. Give the user specific information for debugging errors in their
|
|
|
|
|
//! programs; and
|
|
|
|
|
//! 2. Provide high-resolution information for source code inquiries,
|
|
|
|
|
//! such as "where is this identifier?" and "what exists at my cursor
|
|
|
|
|
//! position within this file"?
|
|
|
|
|
//!
|
|
|
|
|
//! A span contains a [`Context`] representing the source location.
|
2022-04-13 09:59:11 -04:00
|
|
|
|
//! A context's path is a [`PathSymbolId`],
|
2021-08-13 14:59:25 -04:00
|
|
|
|
//! which represents an interned string slice,
|
|
|
|
|
//! _not_ a [`PathBuf`](std::path::PathBuf) or
|
|
|
|
|
//! [`OsStr`](std::ffi::OsStr).
|
|
|
|
|
//!
|
|
|
|
|
//! ```
|
|
|
|
|
//! use tamer::span::{Span, Context};
|
|
|
|
|
//! use tamer::sym::GlobalSymbolIntern;
|
|
|
|
|
//!
|
|
|
|
|
//! // From raw parts
|
|
|
|
|
//! let ctx: Context = "some/path/foo".intern().into();
|
|
|
|
|
//! let span = Span::new(2, 6, ctx);
|
|
|
|
|
//!
|
|
|
|
|
//! assert_eq!(2, span.offset());
|
|
|
|
|
//! assert_eq!(6, span.len());
|
2022-04-26 10:52:32 -04:00
|
|
|
|
//! assert_eq!(ctx, span.context());
|
2021-08-13 14:59:25 -04:00
|
|
|
|
//!
|
|
|
|
|
//! // From a closed byte interval
|
|
|
|
|
//! let spani = Span::from_byte_interval((10, 25), "some/path/bar".intern());
|
|
|
|
|
//! assert_eq!(10, spani.offset());
|
|
|
|
|
//! assert_eq!(15, spani.len());
|
|
|
|
|
//!
|
|
|
|
|
//! // Freely copyable
|
|
|
|
|
//! let cp = span;
|
|
|
|
|
//! assert_eq!(cp, span);
|
|
|
|
|
//! ```
|
|
|
|
|
//!
|
|
|
|
|
//! Span is expected to be able to fit within a general-purpose CPU register
|
|
|
|
|
//! on a 64-bit system, and so does not exceed 8 bytes in length.
|
|
|
|
|
//!
|
|
|
|
|
//! Spans are one of the most common objects in TAMER,
|
|
|
|
|
//! competing only with [symbols](crate::sym).
|
|
|
|
|
//! But unlike symbols,
|
|
|
|
|
//! [`Span`]s are designed to be meaningfully identifiable and copyable
|
|
|
|
|
//! without interning.
|
|
|
|
|
//!
|
|
|
|
|
//! A span is ordered as such:
|
|
|
|
|
//!
|
|
|
|
|
//! 1. Spans group by [`Context`],
|
|
|
|
|
//! though the relative ordering of each [`Context`] isn't
|
|
|
|
|
//! necessarily meaningful;
|
|
|
|
|
//! 2. Spans are then ordered relative to their offset; and
|
|
|
|
|
//! 3. Spans are finally ordered by their length.
|
|
|
|
|
//!
|
|
|
|
|
//! Note that this means that a span beginning after but ending before
|
|
|
|
|
//! another span will still order higher,
|
|
|
|
|
//! as shown in the example below.
|
|
|
|
|
//!
|
|
|
|
|
//! ```
|
|
|
|
|
//! # use tamer::span::{Span, Context};
|
|
|
|
|
//! # use tamer::sym::GlobalSymbolIntern;
|
|
|
|
|
//! #
|
|
|
|
|
//! # let ctx: Context = "some/path/foo".intern().into();
|
|
|
|
|
//! #
|
|
|
|
|
//! // Visualization of spans:
|
2022-06-06 11:29:17 -04:00
|
|
|
|
//! // [....,....,....,....,]
|
|
|
|
|
//! // [A-+-] [B-+]|
|
|
|
|
|
//! // | [C-] |
|
|
|
|
|
//! // | [D-+-]
|
|
|
|
|
//! // | [E]
|
|
|
|
|
//! // [F----] |
|
|
|
|
|
//! // [G------]
|
2021-08-13 14:59:25 -04:00
|
|
|
|
//!
|
|
|
|
|
//! let A = Span::new(2, 6, ctx);
|
|
|
|
|
//! let B = Span::new(10, 5, ctx);
|
|
|
|
|
//! let C = Span::new(10, 4, ctx);
|
|
|
|
|
//! let D = Span::new(10, 6, ctx);
|
|
|
|
|
//! let E = Span::new(11, 3, ctx);
|
|
|
|
|
//! let F = Span::new(5, 7, ctx);
|
|
|
|
|
//! let G = Span::new(5, 8, ctx);
|
|
|
|
|
//!
|
|
|
|
|
//! let mut spans = vec![A, B, C, D, E, F, G];
|
|
|
|
|
//! spans.sort();
|
|
|
|
|
//!
|
|
|
|
|
//! assert_eq!(spans, vec![A, F, G, C, B, D, E]);
|
|
|
|
|
//! ```
|
|
|
|
|
//!
|
|
|
|
|
//! Design Rationale
|
|
|
|
|
//! ================
|
|
|
|
|
//! It is expected that spans will be created and copied frequently,
|
|
|
|
|
//! as they are propagated to every IR in the system.
|
|
|
|
|
//! It is further expected that the data within a span will only be
|
|
|
|
|
//! referenced for diagnostic purposes,
|
|
|
|
|
//! or for utilities operating on original source code
|
|
|
|
|
//! (such as code formatters).
|
|
|
|
|
//!
|
|
|
|
|
//! When a span is referenced,
|
|
|
|
|
//! it will either be to determine the exact location of a particular
|
|
|
|
|
//! entity,
|
|
|
|
|
//! or it will be to attempt to locate a similar entity in a higher-level
|
|
|
|
|
//! IR associated with the same region of code.
|
|
|
|
|
//! The latter requires that spans be comparable in a meaningful way,
|
|
|
|
|
//! exhibiting at least partial ordering.
|
|
|
|
|
//!
|
|
|
|
|
//! Spans are therefore optimized for three primary use cases:
|
|
|
|
|
//! - copying;
|
|
|
|
|
//! - comparison; and
|
|
|
|
|
//! - ordering.
|
|
|
|
|
//!
|
|
|
|
|
//! Span Structure
|
|
|
|
|
//! --------------
|
|
|
|
|
//! Spans are packed into 64-bit values that can be readily converted into a
|
|
|
|
|
//! [`u64`] value that is totally ordered relative to a given [`Context`],
|
|
|
|
|
//! byte offset, and byte length.
|
|
|
|
|
//! This means that sorting a collection of [`Span`]s will group spans by
|
|
|
|
|
//! their [`Context`];
|
|
|
|
|
//! will sort those spans relative to their starting offset within that
|
|
|
|
|
//! context; and
|
|
|
|
|
//! will sort again by the ending offset.
|
|
|
|
|
//!
|
|
|
|
|
//! This means that spans are [`Eq`] and [`Ord`],
|
|
|
|
|
//! and efficiently so by simply comparing the byte values of the entire
|
|
|
|
|
//! struct as a single [`u64`].
|
|
|
|
|
//! This allows spans to be sorted relative to their positions within a
|
|
|
|
|
//! context;
|
|
|
|
|
//! be placed into a binary tree for mapping back to higher-level IRs;
|
|
|
|
|
//! gives spans a meaningful unique identifier;
|
|
|
|
|
//! be freely copied without cost;
|
|
|
|
|
//! and more,
|
|
|
|
|
//! all very efficiently and without having to access individual
|
|
|
|
|
//! struct members.
|
|
|
|
|
//!
|
|
|
|
|
//! To accomplish this,
|
|
|
|
|
//! [`Span`] uses `repr(packed)` and orders the fields for little endian
|
|
|
|
|
//! systems like `x86_64`,
|
|
|
|
|
//! which is what our team uses.
|
|
|
|
|
//! The `packed` representation had to be used because the byte orderings
|
|
|
|
|
//! are [`u16`], [`u32`], [`u16`],
|
|
|
|
|
//! which makes the [`u32`] byte offset unaligned.
|
|
|
|
|
//! Note that,
|
|
|
|
|
//! while this _is_ unaligned,
|
|
|
|
|
//! this is _not_ unaligned _memory_ access,
|
|
|
|
|
//! since the entire [`Span`] will be retrieved from (aligned) memory at
|
|
|
|
|
//! once;
|
|
|
|
|
//! the unaligned fields within the [`u64`] do not incur a measurable
|
|
|
|
|
//! performance cost.
|
|
|
|
|
//!
|
|
|
|
|
//! Related Work
|
|
|
|
|
//! ============
|
|
|
|
|
//! This span is motivated by [rustc's compressed `Span`](rustc-span).
|
2021-09-23 14:52:53 -04:00
|
|
|
|
//! TAMER's span size relies on 16 bits being sufficient for holding
|
|
|
|
|
//! interned paths,
|
|
|
|
|
//! which _should_ be a very reasonable assumption unless the interner
|
|
|
|
|
//! ends up being shared with too many different things.
|
2021-08-13 14:59:25 -04:00
|
|
|
|
//! If ever that assumption becomes violated,
|
|
|
|
|
//! and it is deemed that packages containing so many symbols should be permitted,
|
|
|
|
|
//! TAMER's [`Span`] can accommodate in a similar with to rustc's by
|
|
|
|
|
//! interning the larger span data and tagging this span as such.
|
|
|
|
|
//!
|
|
|
|
|
//!
|
|
|
|
|
//! [rustc-span]: https://doc.rust-lang.org/stable/nightly-rustc/rustc_span/struct.Span.html
|
|
|
|
|
|
2021-10-11 15:39:53 -04:00
|
|
|
|
use crate::{
|
2022-11-08 00:55:04 -05:00
|
|
|
|
debug_diagnostic_panic, global,
|
2022-04-15 09:57:49 -04:00
|
|
|
|
sym::{st16, ContextStaticSymbolId, GlobalSymbolResolve, SymbolId},
|
2021-10-11 15:39:53 -04:00
|
|
|
|
};
|
2022-04-15 09:57:49 -04:00
|
|
|
|
use std::{convert::TryInto, fmt::Display, path::Path};
|
2021-08-13 14:59:25 -04:00
|
|
|
|
|
2021-09-23 14:52:53 -04:00
|
|
|
|
/// A symbol size sufficient for holding interned paths.
|
|
|
|
|
pub type PathSymbolId = SymbolId<u16>;
|
2021-08-13 14:59:25 -04:00
|
|
|
|
|
2022-04-15 09:57:49 -04:00
|
|
|
|
/// Size of a [`Span`]'s `offset` field.
|
|
|
|
|
pub type SpanOffsetSize = global::SourceFileSize;
|
|
|
|
|
|
|
|
|
|
/// Size of a [`Span`]'s `len` field.
|
|
|
|
|
pub type SpanLenSize = global::FrontendTokenLength;
|
|
|
|
|
|
2021-08-13 14:59:25 -04:00
|
|
|
|
/// Description of a source location and byte interval for some object.
|
|
|
|
|
///
|
|
|
|
|
/// Spans represent byte intervals within a given source context.
|
|
|
|
|
/// A span should map to useful positions for helping users debug error
|
|
|
|
|
/// messages.
|
|
|
|
|
/// If code is generated, desugared, or otherwise manipulated,
|
|
|
|
|
/// the span ought to reference the original location of the code that can
|
|
|
|
|
/// be referenced and modified to correct any problems.
|
|
|
|
|
///
|
|
|
|
|
/// See the [module-level documentation](self) for more information.
|
|
|
|
|
#[cfg(target_endian = "little")]
|
|
|
|
|
#[repr(packed)]
|
|
|
|
|
#[derive(Debug, Clone, Copy)]
|
|
|
|
|
pub struct Span {
|
|
|
|
|
/// Token length (ending byte offset - `offset`).
|
2022-04-15 09:57:49 -04:00
|
|
|
|
len: SpanLenSize,
|
2021-08-13 14:59:25 -04:00
|
|
|
|
|
|
|
|
|
/// Starting 0-indexed byte position, inclusive.
|
2022-04-15 09:57:49 -04:00
|
|
|
|
offset: SpanOffsetSize,
|
2021-08-13 14:59:25 -04:00
|
|
|
|
|
|
|
|
|
/// Context onto which byte offsets are mapped,
|
|
|
|
|
/// such as a source file.
|
2022-04-21 14:15:25 -04:00
|
|
|
|
///
|
|
|
|
|
/// N.B.: This is an unaligned field,
|
|
|
|
|
/// and accessing it frequently may have a negative impact on
|
|
|
|
|
/// performance.
|
2021-08-13 14:59:25 -04:00
|
|
|
|
ctx: Context,
|
|
|
|
|
}
|
|
|
|
|
|
2023-02-07 14:59:36 -05:00
|
|
|
|
assert_eq_size!(Span, Option<Span>);
|
|
|
|
|
|
2021-08-13 14:59:25 -04:00
|
|
|
|
impl Span {
|
|
|
|
|
/// Create a new span from its constituent parts.
|
|
|
|
|
pub fn new<C: Into<Context>>(
|
2022-04-15 09:57:49 -04:00
|
|
|
|
offset: SpanOffsetSize,
|
|
|
|
|
len: SpanLenSize,
|
2021-08-13 14:59:25 -04:00
|
|
|
|
ctx: C,
|
|
|
|
|
) -> Self {
|
|
|
|
|
Self {
|
|
|
|
|
ctx: ctx.into(),
|
|
|
|
|
offset,
|
|
|
|
|
len,
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-28 14:52:31 -04:00
|
|
|
|
/// Create a constant span from a static context.
|
|
|
|
|
pub const fn st_ctx(sym: ContextStaticSymbolId) -> Self {
|
|
|
|
|
Self {
|
2022-04-13 09:59:11 -04:00
|
|
|
|
ctx: Context(sym.as_sym()),
|
2021-09-28 14:52:31 -04:00
|
|
|
|
offset: 0,
|
|
|
|
|
len: 0,
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-08-13 14:59:25 -04:00
|
|
|
|
/// Create a span from a byte interval and context.
|
|
|
|
|
///
|
|
|
|
|
/// Panics
|
|
|
|
|
/// ======
|
|
|
|
|
/// This will panic in the unlikely case that the difference between the
|
|
|
|
|
/// start and end of the interval exceeds the maximum of
|
|
|
|
|
/// [`global::FrontendTokenLength`].
|
|
|
|
|
///
|
|
|
|
|
/// If this error occurs,
|
|
|
|
|
/// the parser should consider splitting large tokens up into multiple
|
|
|
|
|
/// tokens;
|
|
|
|
|
/// increasing [`global::FrontendTokenLength`] should be a last
|
|
|
|
|
/// resort,
|
|
|
|
|
/// since it has wide-reaching implications on the size of
|
|
|
|
|
/// [`Span`].
|
|
|
|
|
///
|
|
|
|
|
/// The user is not expected to know how to recover from this error
|
|
|
|
|
/// without debugging the compiler.
|
|
|
|
|
/// It is not expected that this would occur on any valid inputs.
|
|
|
|
|
pub fn from_byte_interval<B, C>(interval: B, ctx: C) -> Self
|
|
|
|
|
where
|
|
|
|
|
B: Into<ClosedByteInterval>,
|
|
|
|
|
C: Into<Context>,
|
|
|
|
|
{
|
|
|
|
|
let binterval = interval.into();
|
|
|
|
|
|
|
|
|
|
Self {
|
|
|
|
|
offset: binterval.0,
|
|
|
|
|
len: (binterval.1 - binterval.0)
|
|
|
|
|
.try_into()
|
|
|
|
|
.expect("span length exceeds global::FrontendTokenLength"),
|
|
|
|
|
ctx: ctx.into(),
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// A span represented uniquely as a totally ordered [`u64`].
|
|
|
|
|
//
|
|
|
|
|
// For more information on this important properly,
|
|
|
|
|
// see the documentation for [`Span`] itself.
|
|
|
|
|
pub fn as_u64(self) -> u64 {
|
|
|
|
|
// We take a number of precautions to make this safe (in the sense
|
|
|
|
|
// of correctness),
|
|
|
|
|
// through struct packing and a `cfg` directive for endianness.
|
|
|
|
|
// In any case,
|
|
|
|
|
// a `u64` isn't going to harm anyone.
|
|
|
|
|
unsafe { std::mem::transmute(self) }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Byte offset of the beginning of the span relative to its context.
|
2022-04-15 09:57:49 -04:00
|
|
|
|
pub fn offset(&self) -> SpanOffsetSize {
|
2021-08-13 14:59:25 -04:00
|
|
|
|
self.offset
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Length of the span in bytes.
|
|
|
|
|
///
|
|
|
|
|
/// The interval of the span is `[offset, offset+len]`.
|
2022-04-15 09:57:49 -04:00
|
|
|
|
pub fn len(&self) -> SpanLenSize {
|
2021-08-13 14:59:25 -04:00
|
|
|
|
self.len
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// The context to which the span applies.
|
|
|
|
|
///
|
|
|
|
|
/// The context is, for example, a file.
|
2022-04-26 10:52:32 -04:00
|
|
|
|
pub fn context(&self) -> Context {
|
2021-08-13 14:59:25 -04:00
|
|
|
|
self.ctx
|
|
|
|
|
}
|
2021-10-11 10:28:35 -04:00
|
|
|
|
|
|
|
|
|
/// Further offset a span.
|
|
|
|
|
///
|
|
|
|
|
/// This attempts to offset a span relative to its current offset by the
|
|
|
|
|
/// provided value.
|
2022-04-15 09:57:49 -04:00
|
|
|
|
/// If the resulting offset exceeds [`SpanOffsetSize`],
|
2021-10-11 10:28:35 -04:00
|
|
|
|
/// the result will be [`None`].
|
2022-04-15 09:57:49 -04:00
|
|
|
|
pub const fn offset_add(self, value: SpanOffsetSize) -> Option<Self> {
|
2022-03-16 14:14:42 -04:00
|
|
|
|
match self.offset.checked_add(value) {
|
|
|
|
|
Some(offset) => Some(Self { offset, ..self }),
|
|
|
|
|
None => None,
|
|
|
|
|
}
|
2021-10-11 10:28:35 -04:00
|
|
|
|
}
|
2022-03-17 21:33:05 -04:00
|
|
|
|
|
|
|
|
|
/// Create two zero-length spans representing respectively the first and
|
|
|
|
|
/// last offsets in the span.
|
|
|
|
|
///
|
|
|
|
|
/// The second endpoint will be [`None`] if the offset cannot be
|
2022-04-15 09:57:49 -04:00
|
|
|
|
/// represented by [`SpanOffsetSize`].
|
2022-03-17 21:33:05 -04:00
|
|
|
|
///
|
|
|
|
|
/// ```
|
|
|
|
|
/// # use tamer::span::{Span, Context};
|
|
|
|
|
/// # use tamer::sym::GlobalSymbolIntern;
|
|
|
|
|
/// #
|
|
|
|
|
/// # let ctx: Context = "some/path/foo".intern().into();
|
|
|
|
|
/// #
|
2022-06-06 11:29:17 -04:00
|
|
|
|
/// // [0123456789]
|
|
|
|
|
/// // [---]
|
|
|
|
|
/// // 2 6
|
|
|
|
|
/// // A
|
2022-03-17 21:33:05 -04:00
|
|
|
|
/// let A = Span::new(2, 6, ctx);
|
|
|
|
|
///
|
|
|
|
|
/// assert_eq!(
|
|
|
|
|
/// A.endpoints(),
|
|
|
|
|
/// (
|
|
|
|
|
/// Span::new(2, 0, ctx),
|
|
|
|
|
/// Some(Span::new(8, 0, ctx)),
|
|
|
|
|
/// ),
|
|
|
|
|
/// );
|
|
|
|
|
/// ```
|
|
|
|
|
pub const fn endpoints(self) -> (Self, Option<Self>) {
|
|
|
|
|
(
|
|
|
|
|
// First endpoint.
|
|
|
|
|
Self {
|
|
|
|
|
offset: self.offset,
|
|
|
|
|
len: 0,
|
|
|
|
|
..self
|
|
|
|
|
},
|
|
|
|
|
// Second endpoint.
|
|
|
|
|
match self.offset.checked_add(self.len as u32) {
|
|
|
|
|
Some(offset) => Some(Self {
|
|
|
|
|
offset,
|
|
|
|
|
len: 0,
|
|
|
|
|
..self
|
|
|
|
|
}),
|
|
|
|
|
None => None,
|
|
|
|
|
},
|
|
|
|
|
)
|
|
|
|
|
}
|
2022-04-21 14:15:25 -04:00
|
|
|
|
|
|
|
|
|
/// Create two zero-length spans representing respectively the first and
|
|
|
|
|
/// last offsets in the span,
|
|
|
|
|
/// saturating the ending offset if it cannot be represented by
|
|
|
|
|
/// [`SpanOffsetSize`].
|
|
|
|
|
///
|
|
|
|
|
/// Aside from the saturation,
|
|
|
|
|
/// this is identical to [`Span::endpoints`].
|
|
|
|
|
pub fn endpoints_saturated(self) -> (Self, Self) {
|
|
|
|
|
let endpoints = self.endpoints();
|
|
|
|
|
|
|
|
|
|
(
|
|
|
|
|
endpoints.0,
|
|
|
|
|
endpoints.1.unwrap_or(Self {
|
|
|
|
|
offset: SpanOffsetSize::MAX,
|
|
|
|
|
..endpoints.0
|
|
|
|
|
}),
|
|
|
|
|
)
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-08 00:55:04 -05:00
|
|
|
|
/// Create a new span that is a slice of this one.
|
|
|
|
|
///
|
|
|
|
|
/// If either `rel_offset` or `len` are too large,
|
|
|
|
|
/// then a copy of the span will be returned unsliced.
|
|
|
|
|
///
|
|
|
|
|
/// Panics (Debug Mode)
|
|
|
|
|
/// -------------------
|
|
|
|
|
/// If the offset and length exceeds the bounds of the span,
|
|
|
|
|
/// then the system has an arithmetic bug that ought to be corrected,
|
|
|
|
|
/// and so this will panic with a diagnostic message.
|
|
|
|
|
/// This check does not occur on release builds since this is not a
|
|
|
|
|
/// safety issue and should be caught by tests.
|
|
|
|
|
pub fn slice(self, rel_offset: usize, len: usize) -> Self {
|
|
|
|
|
let (irel_offset, ilen) = match (rel_offset.try_into(), len.try_into())
|
|
|
|
|
{
|
|
|
|
|
(Ok(x), Ok(y)) => (x, y),
|
|
|
|
|
_ => (0, self.len()),
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
// We shouldn't ignore slices that exceed the length of the span,
|
|
|
|
|
// since this represents a bug that'll cause nonsense diagnostic
|
|
|
|
|
// data and it represents an arithmetic bug in the system
|
|
|
|
|
// (but there are no safety concerns).
|
|
|
|
|
if ((irel_offset as usize).saturating_add(ilen as usize))
|
|
|
|
|
> self.len() as usize
|
|
|
|
|
{
|
|
|
|
|
use crate::diagnose::Annotate;
|
|
|
|
|
debug_diagnostic_panic!(
|
|
|
|
|
self.error("attempting to slice this span").into(),
|
|
|
|
|
"length {len} at offset {rel_offset} \
|
|
|
|
|
exceeds bounds of span {self}",
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Self {
|
|
|
|
|
ctx: self.ctx,
|
|
|
|
|
offset: self.offset.saturating_add(irel_offset),
|
|
|
|
|
len: ilen,
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-04-21 14:15:25 -04:00
|
|
|
|
/// Adjust span such that its offset is relative to the provided span.
|
|
|
|
|
///
|
|
|
|
|
/// If the provide `rel_span` does not precede this span,
|
|
|
|
|
/// [`None`] will be returned.
|
|
|
|
|
///
|
|
|
|
|
/// If the two spans do not share the same [`Context`],
|
|
|
|
|
/// no comparison can be made and [`None`] will be returned.
|
|
|
|
|
pub fn relative_to(self, rel_span: Span) -> Option<Self> {
|
|
|
|
|
// Note that this is unaligned.
|
2022-04-26 10:52:32 -04:00
|
|
|
|
if self.context() != rel_span.context() {
|
2022-04-21 14:15:25 -04:00
|
|
|
|
return None;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if self.offset() < rel_span.offset() {
|
|
|
|
|
return None;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Some(Self {
|
|
|
|
|
ctx: self.ctx,
|
|
|
|
|
offset: self.offset.saturating_sub(rel_span.offset),
|
|
|
|
|
len: self.len,
|
|
|
|
|
})
|
|
|
|
|
}
|
2022-12-20 13:03:23 -05:00
|
|
|
|
|
|
|
|
|
/// Merge with another span `b` such that the combined span begins at
|
|
|
|
|
/// the offset of the earlier of the two spans and extends to the end
|
|
|
|
|
/// of the later of the two.
|
|
|
|
|
///
|
|
|
|
|
/// Both spans must have the same [`Context`],
|
|
|
|
|
/// otherwise the result will be [`None`].
|
|
|
|
|
/// Merged values beyond [`SpanOffsetSize`] and [`SpanLenSize`] will
|
|
|
|
|
/// also result in [`None`].
|
|
|
|
|
///
|
|
|
|
|
/// This properly handles overlapping spans,
|
|
|
|
|
/// including the case where one of the spans is entirely contained
|
|
|
|
|
/// within another.
|
|
|
|
|
/// See test cases for more information.
|
|
|
|
|
/// (TODO: Maybe we should move the test cases into these docs?)
|
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 fn merge<S: Into<Span>>(self, other: S) -> Option<Span> {
|
|
|
|
|
let b = other.into();
|
|
|
|
|
|
2022-12-20 13:03:23 -05:00
|
|
|
|
if self.context() != b.context() {
|
|
|
|
|
return None;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Order arguments such that `self` is placed at or before `b`
|
|
|
|
|
// rather than having to worry about confounding accommodations
|
|
|
|
|
// below.
|
|
|
|
|
if self.offset() > b.offset() {
|
|
|
|
|
return b.merge(self);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
let (_, end) = b.endpoints();
|
|
|
|
|
|
|
|
|
|
end.and_then(|Span { offset, .. }| {
|
|
|
|
|
SpanLenSize::try_from(offset - self.offset).ok()
|
|
|
|
|
})
|
|
|
|
|
.map(|new_len| Self {
|
|
|
|
|
ctx: self.ctx,
|
|
|
|
|
offset: self.offset,
|
|
|
|
|
len: self.len.max(new_len),
|
|
|
|
|
})
|
|
|
|
|
}
|
2021-08-13 14:59:25 -04:00
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
impl From<Span> for u64 {
|
|
|
|
|
fn from(val: Span) -> Self {
|
|
|
|
|
val.as_u64()
|
2021-08-13 14:59:25 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl PartialEq for Span {
|
|
|
|
|
fn eq(&self, other: &Self) -> bool {
|
|
|
|
|
self.as_u64() == other.as_u64()
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl Eq for Span {}
|
|
|
|
|
|
|
|
|
|
impl PartialOrd for Span {
|
|
|
|
|
fn partial_cmp(&self, other: &Self) -> Option<std::cmp::Ordering> {
|
|
|
|
|
Some(self.cmp(other))
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl Ord for Span {
|
|
|
|
|
fn cmp(&self, other: &Self) -> std::cmp::Ordering {
|
|
|
|
|
self.as_u64().cmp(&other.as_u64())
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// This assertion verifies our above expectations.
|
|
|
|
|
// If this fails,
|
|
|
|
|
// then you have either modified [`global`] constants or you have modified
|
|
|
|
|
// the fields of [`Span`] itself,
|
|
|
|
|
// in which case you should read "Related Work" above to determine
|
|
|
|
|
// whether this was a good idea or if interned spans should be
|
|
|
|
|
// introduced.
|
|
|
|
|
// In any case,
|
|
|
|
|
// hopefully this was planned for,
|
|
|
|
|
// because otherwise your week has just been ruined.
|
|
|
|
|
assert_eq_size!(Span, u64);
|
|
|
|
|
|
2021-10-11 09:56:48 -04:00
|
|
|
|
impl From<Span> for (Span, Span) {
|
|
|
|
|
/// Expand a [`Span`] into a two-span.
|
|
|
|
|
///
|
|
|
|
|
/// A two-span `(A, B)` is equivalent to a span beginning at the start
|
|
|
|
|
/// of `A` and ending at the end of `B`.
|
|
|
|
|
///
|
|
|
|
|
/// We gain no resolution from performing this operation,
|
|
|
|
|
/// but it does allow for using a single span in contexts where a
|
|
|
|
|
/// higher resolution is supported.
|
|
|
|
|
fn from(span: Span) -> Self {
|
|
|
|
|
(span, span)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-10-11 14:14:43 -04:00
|
|
|
|
impl Display for Span {
|
|
|
|
|
fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
|
|
|
|
|
// Needed to avoid unaligned references since Span is packed.
|
|
|
|
|
let ctx = self.ctx;
|
|
|
|
|
let offset = self.offset as usize;
|
|
|
|
|
|
|
|
|
|
let end = offset + self.len as usize;
|
|
|
|
|
|
|
|
|
|
// Very primitive information to begin with; we'll have something
|
|
|
|
|
// more useful in the future.
|
|
|
|
|
write!(f, "[{} offset {}-{}]", ctx, offset, end)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-29 11:14:47 -04:00
|
|
|
|
/// A placeholder span indicating that a span is expected but is not yet
|
|
|
|
|
/// known.
|
tamer: xir::reader: Initial introduction of spans
This is a large change, and was a bit of a tedious one, given the
comprehensive tests.
This introduces proper offsets and lengths for spans, with the exception of
some quick-xml errors that still need proper mapping. Further, this still
uses `UNKNOWN_CONTEXT`, which will be resolved shortly.
This also introduces `SpanlessError`, which `Error` explicitly _does not_
implement `From<SpanlessError>` for---this forces the caller to provide a
span before the error is compatable with the return value, ensuring that
spans will actually be available rather than forgotten for errors. This is
important, given that errors are generally less tested than the happy path,
and errors are when users need us the most (so, need span information).
Further, I had to use pointer arithmetic in order to calculate many of the
spans, because quick-xml does not provide enough information. There's no
safety considerations here, and the comprehensive unit test will ensure
correct behavior if the implementation changes in the future.
I would like to introduce typed spans at some point---I made some
opinionated choices when it comes to what the spans ought to
represent. Specifically, whether to include the `<` or `>` with the open
span (depends), whether to include quotes with attribute values (no),
and some other details highlighted in the test cases. If we provide typed
spans, then we could, knowing the type of span, calculate other spans on
request, e.g. to include or omit quotes for attributes. Different such
spans may be useful in different situations when presenting information to
the user.
This also highlights gaps in the tokens emitted by XIR, such as whitespace
between attributes, the `=` between name and value, and so on. These are
important when it comes to code formatting, so that we can reliably
reconstruct the XML tree, but it's not important right now. I anticipate
future changes would allow the XIR reader to be configured (perhaps via
generics, like a strategy-type pattern) to optionally omit these tokens if
desired.
Anyway, more to come.
DEV-10934
2022-04-08 11:03:46 -04:00
|
|
|
|
pub const UNKNOWN_SPAN: Span = Span::st_ctx(st16::CTX_UNKNOWN);
|
2022-03-29 11:14:47 -04:00
|
|
|
|
|
2021-08-13 14:59:25 -04:00
|
|
|
|
/// Context for byte offsets (e.g. a source file).
|
|
|
|
|
///
|
|
|
|
|
/// A context is lifetime-free and [`Copy`]-able,
|
2022-04-13 09:59:11 -04:00
|
|
|
|
/// with the assumption that an interned [`PathSymbolId`] will only need
|
|
|
|
|
/// to be resolved to its underlying value in a diagnostic context where
|
|
|
|
|
/// the internment system is readily available.
|
2021-08-13 14:59:25 -04:00
|
|
|
|
///
|
|
|
|
|
/// Since this is used within [`Span`],
|
|
|
|
|
/// it must be kept as small as possible.
|
2022-04-15 09:57:49 -04:00
|
|
|
|
#[derive(Debug, PartialEq, Eq, Clone, Copy, Hash)]
|
2022-04-13 09:59:11 -04:00
|
|
|
|
pub struct Context(PathSymbolId);
|
2021-08-13 14:59:25 -04:00
|
|
|
|
|
tamer: xir::reader: Initial introduction of spans
This is a large change, and was a bit of a tedious one, given the
comprehensive tests.
This introduces proper offsets and lengths for spans, with the exception of
some quick-xml errors that still need proper mapping. Further, this still
uses `UNKNOWN_CONTEXT`, which will be resolved shortly.
This also introduces `SpanlessError`, which `Error` explicitly _does not_
implement `From<SpanlessError>` for---this forces the caller to provide a
span before the error is compatable with the return value, ensuring that
spans will actually be available rather than forgotten for errors. This is
important, given that errors are generally less tested than the happy path,
and errors are when users need us the most (so, need span information).
Further, I had to use pointer arithmetic in order to calculate many of the
spans, because quick-xml does not provide enough information. There's no
safety considerations here, and the comprehensive unit test will ensure
correct behavior if the implementation changes in the future.
I would like to introduce typed spans at some point---I made some
opinionated choices when it comes to what the spans ought to
represent. Specifically, whether to include the `<` or `>` with the open
span (depends), whether to include quotes with attribute values (no),
and some other details highlighted in the test cases. If we provide typed
spans, then we could, knowing the type of span, calculate other spans on
request, e.g. to include or omit quotes for attributes. Different such
spans may be useful in different situations when presenting information to
the user.
This also highlights gaps in the tokens emitted by XIR, such as whitespace
between attributes, the `=` between name and value, and so on. These are
important when it comes to code formatting, so that we can reliably
reconstruct the XML tree, but it's not important right now. I anticipate
future changes would allow the XIR reader to be configured (perhaps via
generics, like a strategy-type pattern) to optionally omit these tokens if
desired.
Anyway, more to come.
DEV-10934
2022-04-08 11:03:46 -04:00
|
|
|
|
impl Context {
|
|
|
|
|
/// Produce a [`Span`] within the given context.
|
|
|
|
|
#[inline]
|
2022-06-06 11:05:41 -04:00
|
|
|
|
pub const fn span(self, offset: SpanOffsetSize, len: SpanLenSize) -> Span {
|
|
|
|
|
Span {
|
|
|
|
|
ctx: self,
|
|
|
|
|
offset,
|
|
|
|
|
len,
|
|
|
|
|
}
|
tamer: xir::reader: Initial introduction of spans
This is a large change, and was a bit of a tedious one, given the
comprehensive tests.
This introduces proper offsets and lengths for spans, with the exception of
some quick-xml errors that still need proper mapping. Further, this still
uses `UNKNOWN_CONTEXT`, which will be resolved shortly.
This also introduces `SpanlessError`, which `Error` explicitly _does not_
implement `From<SpanlessError>` for---this forces the caller to provide a
span before the error is compatable with the return value, ensuring that
spans will actually be available rather than forgotten for errors. This is
important, given that errors are generally less tested than the happy path,
and errors are when users need us the most (so, need span information).
Further, I had to use pointer arithmetic in order to calculate many of the
spans, because quick-xml does not provide enough information. There's no
safety considerations here, and the comprehensive unit test will ensure
correct behavior if the implementation changes in the future.
I would like to introduce typed spans at some point---I made some
opinionated choices when it comes to what the spans ought to
represent. Specifically, whether to include the `<` or `>` with the open
span (depends), whether to include quotes with attribute values (no),
and some other details highlighted in the test cases. If we provide typed
spans, then we could, knowing the type of span, calculate other spans on
request, e.g. to include or omit quotes for attributes. Different such
spans may be useful in different situations when presenting information to
the user.
This also highlights gaps in the tokens emitted by XIR, such as whitespace
between attributes, the `=` between name and value, and so on. These are
important when it comes to code formatting, so that we can reliably
reconstruct the XML tree, but it's not important right now. I anticipate
future changes would allow the XIR reader to be configured (perhaps via
generics, like a strategy-type pattern) to optionally omit these tokens if
desired.
Anyway, more to come.
DEV-10934
2022-04-08 11:03:46 -04:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Attempt to produce a [`Span`] of the given length at the given
|
|
|
|
|
/// offset,
|
|
|
|
|
/// otherwise fall back to a `(0,0)` (ZZ) span.
|
|
|
|
|
///
|
|
|
|
|
/// If the offset cannot be stored,
|
|
|
|
|
/// then the length will always be `0` even if it could otherwise be
|
|
|
|
|
/// represented;
|
|
|
|
|
/// `(0,0)` indicates no span,
|
|
|
|
|
/// whereas `(0,N)` would indicate a span of length `N` at
|
|
|
|
|
/// offset `0`,
|
|
|
|
|
/// which would not be true.
|
|
|
|
|
///
|
|
|
|
|
/// If the offset can be represented but not the length,
|
|
|
|
|
/// then a zero-length span at that offset will be produced,
|
|
|
|
|
/// which still provides useful information.
|
|
|
|
|
/// This may be the case for very large objects,
|
|
|
|
|
/// like compiled text fragments.
|
|
|
|
|
///
|
|
|
|
|
/// The rationale here is that spans are intended to be informative.
|
|
|
|
|
/// If we are unable to provide that information due to exceptional
|
|
|
|
|
/// circumstances
|
|
|
|
|
/// (very large file or very large token),
|
|
|
|
|
/// then it's better to provide _some_ information than to bail out
|
|
|
|
|
/// with an error and interrupt the entire process,
|
|
|
|
|
/// potentially masking errors in the process.
|
|
|
|
|
#[inline]
|
|
|
|
|
pub fn span_or_zz(self, offset: usize, len: usize) -> Span {
|
|
|
|
|
self.span(offset.try_into().unwrap_or(0), len.try_into().unwrap_or(0))
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// A placeholder context indicating that a context is expected but is not
|
|
|
|
|
/// yet known.
|
2022-04-13 09:59:11 -04:00
|
|
|
|
pub const UNKNOWN_CONTEXT: Context = Context(st16::raw::CTX_UNKNOWN);
|
tamer: xir::reader: Initial introduction of spans
This is a large change, and was a bit of a tedious one, given the
comprehensive tests.
This introduces proper offsets and lengths for spans, with the exception of
some quick-xml errors that still need proper mapping. Further, this still
uses `UNKNOWN_CONTEXT`, which will be resolved shortly.
This also introduces `SpanlessError`, which `Error` explicitly _does not_
implement `From<SpanlessError>` for---this forces the caller to provide a
span before the error is compatable with the return value, ensuring that
spans will actually be available rather than forgotten for errors. This is
important, given that errors are generally less tested than the happy path,
and errors are when users need us the most (so, need span information).
Further, I had to use pointer arithmetic in order to calculate many of the
spans, because quick-xml does not provide enough information. There's no
safety considerations here, and the comprehensive unit test will ensure
correct behavior if the implementation changes in the future.
I would like to introduce typed spans at some point---I made some
opinionated choices when it comes to what the spans ought to
represent. Specifically, whether to include the `<` or `>` with the open
span (depends), whether to include quotes with attribute values (no),
and some other details highlighted in the test cases. If we provide typed
spans, then we could, knowing the type of span, calculate other spans on
request, e.g. to include or omit quotes for attributes. Different such
spans may be useful in different situations when presenting information to
the user.
This also highlights gaps in the tokens emitted by XIR, such as whitespace
between attributes, the `=` between name and value, and so on. These are
important when it comes to code formatting, so that we can reliably
reconstruct the XML tree, but it's not important right now. I anticipate
future changes would allow the XIR reader to be configured (perhaps via
generics, like a strategy-type pattern) to optionally omit these tokens if
desired.
Anyway, more to come.
DEV-10934
2022-04-08 11:03:46 -04:00
|
|
|
|
|
tamer: diagnose: Introduction of diagnostic system
This is a working concept that will continue to evolve. I wanted to start
with some basic output before getting too carried away, since there's a lot
of potential here.
This is heavily influenced by Rust's helpful diagnostic messages, but will
take some time to realize a lot of the things that Rust does. The next step
will be to resolve line and column numbers, and then possibly include
snippets and underline spans, placing the labels alongside them. I need to
balance this work with everything else I have going on.
This is a large commit, but it converts the existing Error Display impls
into Diagnostic. This separation is a bit verbose, so I'll see how this
ends up evolving.
Diagnostics are tied to Error at the moment, but I imagine in the future
that any object would be able to describe itself, error or not, which would
be useful in the future both for the Summary Page and for query
functionality, to help developers understand the systems they are writing
using TAME.
Output is integrated into tameld only in this commit; I'll add tamec
next. Examples of what this outputs are available in the test cases in this
commit.
DEV-10935
2022-04-13 14:41:54 -04:00
|
|
|
|
impl<P: Into<PathSymbolId>> From<P> for Context {
|
|
|
|
|
fn from(sym: P) -> Self {
|
|
|
|
|
Self(sym.into())
|
2021-08-13 14:59:25 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-04-13 09:59:11 -04:00
|
|
|
|
impl Display for Context {
|
2021-10-11 14:14:43 -04:00
|
|
|
|
fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
|
|
|
|
|
self.0.fmt(f)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-04-15 09:57:49 -04:00
|
|
|
|
impl AsRef<Path> for Context {
|
|
|
|
|
fn as_ref(&self) -> &Path {
|
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
|
|
|
|
Path::new(self.0.lookup_str())
|
2022-04-15 09:57:49 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-08-13 14:59:25 -04:00
|
|
|
|
/// A closed interval (range of values including its endpoints) representing
|
|
|
|
|
/// source bytes associated with a token.
|
|
|
|
|
#[derive(Debug, PartialEq, Eq, Clone, Copy)]
|
2022-04-15 09:57:49 -04:00
|
|
|
|
pub struct ClosedByteInterval<T = SpanOffsetSize>(pub T, pub T)
|
2021-08-13 14:59:25 -04:00
|
|
|
|
where
|
|
|
|
|
T: Copy + PartialOrd;
|
|
|
|
|
|
|
|
|
|
impl<T: Copy + PartialOrd> From<(T, T)> for ClosedByteInterval<T> {
|
|
|
|
|
/// Convert a tuple into a closed byte interval where the first index
|
|
|
|
|
/// represents the start of the interval and the second index the
|
|
|
|
|
/// end.
|
|
|
|
|
///
|
|
|
|
|
/// Panics
|
|
|
|
|
/// ======
|
|
|
|
|
/// The second value must be ≥ the first.
|
|
|
|
|
fn from(src: (T, T)) -> Self {
|
|
|
|
|
assert!(src.1 >= src.0);
|
|
|
|
|
|
|
|
|
|
Self(src.0, src.1)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
assert_eq_size!(ClosedByteInterval, u64);
|
|
|
|
|
|
2022-07-29 10:27:46 -04:00
|
|
|
|
/// Dummy spans for testing.
|
|
|
|
|
#[cfg(test)]
|
|
|
|
|
pub mod dummy {
|
|
|
|
|
use super::{st16, Context, Span};
|
|
|
|
|
|
|
|
|
|
/// A dummy span that can be used in contexts where a span is expected
|
|
|
|
|
/// but is not important.
|
|
|
|
|
///
|
|
|
|
|
/// This is intended primarily for tests;
|
|
|
|
|
/// you should always use an appropriate span to permit sensible error
|
|
|
|
|
/// messages and source analysis.
|
|
|
|
|
/// For spans that are actually unknown,
|
|
|
|
|
/// use [`super::UNKNOWN_SPAN`].
|
|
|
|
|
///
|
|
|
|
|
/// Additional dummy spans can be derived from this one.
|
|
|
|
|
pub const DUMMY_SPAN: Span = Span::st_ctx(st16::CTX_DUMMY);
|
|
|
|
|
|
|
|
|
|
/// A dummy context that can be used where a span is expected but is not
|
|
|
|
|
/// important.
|
|
|
|
|
///
|
|
|
|
|
/// This is intended primarily for tests;
|
|
|
|
|
/// you should always use an appropriate span to permit sensible error
|
|
|
|
|
/// messages and source analysis.
|
|
|
|
|
/// For contexts that are actually unknown,
|
|
|
|
|
/// use [`super::UNKNOWN_CONTEXT`].
|
|
|
|
|
///
|
|
|
|
|
/// See also [`UNKNOWN_CONTEXT`].
|
|
|
|
|
pub const DUMMY_CONTEXT: Context = Context(st16::raw::CTX_DUMMY);
|
|
|
|
|
|
|
|
|
|
// This name is for brevity;
|
|
|
|
|
// we don't want to expose it because we don't want anyone to assume
|
|
|
|
|
// that a different name means that it's somehow different from
|
|
|
|
|
// `DUMMY_SPAN`.
|
|
|
|
|
const S0: Span = DUMMY_SPAN;
|
|
|
|
|
|
|
|
|
|
pub const S1: Span = S0.offset_add(1).unwrap();
|
|
|
|
|
pub const S2: Span = S0.offset_add(2).unwrap();
|
|
|
|
|
pub const S3: Span = S0.offset_add(3).unwrap();
|
|
|
|
|
pub const S4: Span = S0.offset_add(4).unwrap();
|
|
|
|
|
pub const S5: Span = S0.offset_add(5).unwrap();
|
|
|
|
|
pub const S6: Span = S0.offset_add(6).unwrap();
|
|
|
|
|
pub const S7: Span = S0.offset_add(7).unwrap();
|
|
|
|
|
pub const S8: Span = S0.offset_add(8).unwrap();
|
|
|
|
|
pub const S9: Span = S0.offset_add(9).unwrap();
|
2023-01-17 16:31:13 -05:00
|
|
|
|
pub const S10: Span = S0.offset_add(10).unwrap();
|
2023-02-07 14:59:36 -05:00
|
|
|
|
pub const S11: Span = S0.offset_add(11).unwrap();
|
|
|
|
|
pub const S12: Span = S0.offset_add(12).unwrap();
|
|
|
|
|
pub const S13: Span = S0.offset_add(13).unwrap();
|
|
|
|
|
pub const S14: Span = S0.offset_add(14).unwrap();
|
|
|
|
|
pub const S15: Span = S0.offset_add(15).unwrap();
|
|
|
|
|
pub const S16: Span = S0.offset_add(16).unwrap();
|
|
|
|
|
pub const S17: Span = S0.offset_add(17).unwrap();
|
|
|
|
|
pub const S18: Span = S0.offset_add(18).unwrap();
|
|
|
|
|
pub const S19: Span = S0.offset_add(19).unwrap();
|
|
|
|
|
pub const S20: Span = S0.offset_add(20).unwrap();
|
2022-07-29 10:27:46 -04:00
|
|
|
|
}
|
|
|
|
|
|
2021-08-13 14:59:25 -04:00
|
|
|
|
#[cfg(test)]
|
|
|
|
|
mod test {
|
|
|
|
|
use super::*;
|
|
|
|
|
|
|
|
|
|
// Little endian check.
|
|
|
|
|
//
|
|
|
|
|
// This ensures that the byte ordering is as expected,
|
|
|
|
|
// otherwise the resulting integer will not have the properties we
|
|
|
|
|
// require for sorting and comparison.
|
|
|
|
|
#[cfg(target_endian = "little")]
|
|
|
|
|
#[test]
|
|
|
|
|
fn span_pack_le() {
|
|
|
|
|
let span =
|
2021-09-23 14:52:53 -04:00
|
|
|
|
Span::new(0xA3A2A1A0, 0xB1B0, SymbolId::test_from_int(0xC1C0));
|
2021-08-13 14:59:25 -04:00
|
|
|
|
|
|
|
|
|
assert_eq!(
|
|
|
|
|
0xC1C0_A3A2A1A0_B1B0,
|
|
|
|
|
// ^ ^ ^
|
|
|
|
|
// ctx offset len
|
|
|
|
|
span.as_u64(),
|
|
|
|
|
"endianness check failed: {:X?}",
|
|
|
|
|
span.as_u64()
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[cfg(target_endian = "big")]
|
|
|
|
|
#[test]
|
|
|
|
|
fn span_pack_be_not_supported() {
|
|
|
|
|
panic!("Big-endian systems are not currently supported");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// The tests that follow are corollaries of the above, but the below
|
|
|
|
|
// tests do test that the implementations function as intended.
|
|
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
|
fn span_at_later_offset_in_same_context_compares_greater() {
|
2022-04-14 12:16:16 -04:00
|
|
|
|
let ctx = Context::from("imaginary");
|
|
|
|
|
let first = ctx.span(10, 5);
|
|
|
|
|
let second = ctx.span(20, 5);
|
2021-08-13 14:59:25 -04:00
|
|
|
|
|
|
|
|
|
// These two assertions must be identical.
|
|
|
|
|
assert!(second > first);
|
|
|
|
|
assert!(second.as_u64() > first.as_u64());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
|
fn spans_order_by_context_start_and_len() {
|
2022-04-14 12:16:16 -04:00
|
|
|
|
let ctxa = Context::from("context a");
|
|
|
|
|
let ctxb = Context::from("context b");
|
2021-08-13 14:59:25 -04:00
|
|
|
|
|
|
|
|
|
// Sanity check, otherwise this test won't work as expected.
|
2022-04-14 12:16:16 -04:00
|
|
|
|
assert!(ctxa.0 < ctxb.0);
|
2021-08-13 14:59:25 -04:00
|
|
|
|
|
2022-04-14 12:16:16 -04:00
|
|
|
|
let sa1 = ctxa.span(10, 1);
|
|
|
|
|
let sa2 = ctxa.span(22, 1);
|
|
|
|
|
let sa3 = ctxa.span(35, 1);
|
2021-08-13 14:59:25 -04:00
|
|
|
|
|
2022-04-14 12:16:16 -04:00
|
|
|
|
let sb1 = ctxb.span(11, 1);
|
|
|
|
|
let sb2 = ctxb.span(20, 1);
|
|
|
|
|
let sb3 = ctxb.span(33, 1);
|
2021-08-13 14:59:25 -04:00
|
|
|
|
|
|
|
|
|
let mut spans = vec![sa3, sb2, sb1, sa2, sa1, sb3];
|
|
|
|
|
spans.sort();
|
|
|
|
|
|
|
|
|
|
assert_eq!(spans, vec![sa1, sa2, sa3, sb1, sb2, sb3]);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[test]
|
2022-04-14 12:16:16 -04:00
|
|
|
|
fn retrieve_span_components() {
|
|
|
|
|
let ctx = Context::from("foo");
|
2021-08-13 14:59:25 -04:00
|
|
|
|
let offset = 100;
|
|
|
|
|
let len = 50;
|
|
|
|
|
|
2022-04-14 12:16:16 -04:00
|
|
|
|
let span = ctx.span(offset, len);
|
2021-08-13 14:59:25 -04:00
|
|
|
|
|
2022-04-26 10:52:32 -04:00
|
|
|
|
assert_eq!(
|
|
|
|
|
(offset, len, ctx),
|
|
|
|
|
(span.offset(), span.len(), span.context())
|
|
|
|
|
);
|
2021-08-13 14:59:25 -04:00
|
|
|
|
}
|
2021-10-11 09:56:48 -04:00
|
|
|
|
|
2021-10-11 10:28:35 -04:00
|
|
|
|
#[test]
|
2022-04-14 12:16:16 -04:00
|
|
|
|
fn span_offset_add() {
|
|
|
|
|
let ctx = Context::from("addtest");
|
2021-10-11 10:28:35 -04:00
|
|
|
|
let offset = 10;
|
|
|
|
|
let len = 5;
|
|
|
|
|
|
2022-04-14 12:16:16 -04:00
|
|
|
|
let span = ctx.span(offset, len);
|
2021-10-11 10:28:35 -04:00
|
|
|
|
|
|
|
|
|
// Successful add.
|
|
|
|
|
assert_eq!(
|
|
|
|
|
span.offset_add(10),
|
|
|
|
|
Some(Span {
|
|
|
|
|
offset: offset + 10,
|
|
|
|
|
len,
|
|
|
|
|
ctx
|
|
|
|
|
})
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
// Fail, do not wrap.
|
2022-04-15 09:57:49 -04:00
|
|
|
|
assert_eq!(span.offset_add(SpanOffsetSize::MAX), None);
|
2021-10-11 10:28:35 -04:00
|
|
|
|
}
|
|
|
|
|
|
2021-10-11 09:56:48 -04:00
|
|
|
|
#[test]
|
2022-04-14 12:16:16 -04:00
|
|
|
|
fn span_into_twospan() {
|
|
|
|
|
let ctx = Context::from("foo");
|
|
|
|
|
let span = ctx.span(10, 50);
|
2021-10-11 09:56:48 -04:00
|
|
|
|
|
|
|
|
|
assert_eq!((span, span), span.into());
|
|
|
|
|
}
|
2022-03-17 21:33:05 -04:00
|
|
|
|
|
|
|
|
|
#[test]
|
2022-04-14 12:16:16 -04:00
|
|
|
|
fn span_endpoints() {
|
|
|
|
|
let ctx = Context::from("end");
|
|
|
|
|
let span = ctx.span(10, 20);
|
2022-03-17 21:33:05 -04:00
|
|
|
|
|
|
|
|
|
let (start, end) = span.endpoints();
|
|
|
|
|
|
|
|
|
|
assert_eq!(start, Span::new(10, 0, ctx));
|
|
|
|
|
assert_eq!(end, Some(Span::new(30, 0, ctx)));
|
|
|
|
|
}
|
2022-04-21 14:15:25 -04:00
|
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
|
fn span_endpoints_exceeding_max_offset() {
|
|
|
|
|
let ctx = Context::from("end");
|
|
|
|
|
let offset = SpanOffsetSize::MAX - 5;
|
|
|
|
|
let span = ctx.span(offset, 10);
|
|
|
|
|
|
|
|
|
|
let (start, end) = span.endpoints();
|
|
|
|
|
|
|
|
|
|
assert_eq!(start, Span::new(offset, 0, ctx));
|
|
|
|
|
assert_eq!(end, None);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
|
fn span_endpoints_saturated() {
|
|
|
|
|
let ctx = Context::from("end");
|
|
|
|
|
let offset = SpanOffsetSize::MAX - 5;
|
|
|
|
|
let span = ctx.span(offset, 10);
|
|
|
|
|
|
|
|
|
|
let (start, end) = span.endpoints_saturated();
|
|
|
|
|
|
|
|
|
|
assert_eq!(start, Span::new(offset, 0, ctx));
|
|
|
|
|
assert_eq!(end, Span::new(SpanOffsetSize::MAX, 0, ctx));
|
|
|
|
|
}
|
2022-11-08 00:55:04 -05:00
|
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
|
fn span_slice_yields_slice_within_original() {
|
|
|
|
|
let ctx = Context::from("slice");
|
|
|
|
|
let span = ctx.span(10, 10);
|
|
|
|
|
|
|
|
|
|
assert_eq!(ctx.span(15, 5), span.slice(5, 5));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
|
fn span_slice_large_values_yield_original() {
|
|
|
|
|
let span = Context::from("slice").span(0, 50);
|
|
|
|
|
|
|
|
|
|
// Too large of an offset should return original even though legnth
|
|
|
|
|
// is okay.
|
|
|
|
|
assert_eq!(span, span.slice(usize::MAX, 5));
|
|
|
|
|
|
|
|
|
|
// Too large of length should return original even though offset is
|
|
|
|
|
// okay.
|
|
|
|
|
assert_eq!(span, span.slice(0, usize::MAX));
|
|
|
|
|
}
|
2022-12-20 13:03:23 -05:00
|
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
|
fn span_merge_one_after_other() {
|
|
|
|
|
let ctx = Context::from("merge");
|
|
|
|
|
|
|
|
|
|
// "an example string"
|
|
|
|
|
// [-----] [----]
|
|
|
|
|
// 3 9 11 16
|
|
|
|
|
// | A B |
|
|
|
|
|
// [------------]
|
|
|
|
|
// 3 16
|
|
|
|
|
// C
|
|
|
|
|
|
|
|
|
|
let a = ctx.span(3, 7);
|
|
|
|
|
let b = ctx.span(11, 6);
|
|
|
|
|
let c = ctx.span(3, 14);
|
|
|
|
|
|
|
|
|
|
assert_eq!(a.merge(b), Some(c));
|
|
|
|
|
assert_eq!(b.merge(a), Some(c));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
|
fn span_merge_overlap() {
|
|
|
|
|
let ctx = Context::from("merge");
|
|
|
|
|
|
|
|
|
|
// "an example string"
|
|
|
|
|
// [---+-] |
|
|
|
|
|
// 3 | 9 |
|
|
|
|
|
// | A| |
|
|
|
|
|
// | [--------]
|
|
|
|
|
// | 7 16
|
|
|
|
|
// | B |
|
|
|
|
|
// [------------]
|
|
|
|
|
// 3 16
|
|
|
|
|
// C
|
|
|
|
|
|
|
|
|
|
let a = ctx.span(3, 7);
|
|
|
|
|
let b = ctx.span(7, 10);
|
|
|
|
|
let c = ctx.span(3, 14);
|
|
|
|
|
|
|
|
|
|
// We compare in both orders,
|
|
|
|
|
// so this will test when a span overlaps on either side.
|
|
|
|
|
assert_eq!(a.merge(b), Some(c));
|
|
|
|
|
assert_eq!(b.merge(a), Some(c));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
|
fn span_merge_overlap_within() {
|
|
|
|
|
let ctx = Context::from("merge");
|
|
|
|
|
|
|
|
|
|
// "an example string"
|
|
|
|
|
// |[----] |
|
|
|
|
|
// |1 6 |
|
|
|
|
|
// | B |
|
|
|
|
|
// [--------]
|
|
|
|
|
// 0 9
|
|
|
|
|
// C
|
|
|
|
|
|
|
|
|
|
let b = ctx.span(1, 6);
|
|
|
|
|
let c = ctx.span(0, 10);
|
|
|
|
|
|
|
|
|
|
assert_eq!(b.merge(c), Some(c));
|
|
|
|
|
assert_eq!(c.merge(b), Some(c));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// It doesn't make sense to merge two spans that are located in
|
|
|
|
|
// different contexts.
|
|
|
|
|
#[test]
|
|
|
|
|
fn span_merge_different_contexts() {
|
|
|
|
|
let ctx_a = Context::from("merge_a");
|
|
|
|
|
let ctx_b = Context::from("merge_b");
|
|
|
|
|
|
|
|
|
|
assert_eq!(ctx_a.span(0, 1).merge(ctx_b.span(1, 2)), None);
|
|
|
|
|
}
|
2021-08-13 14:59:25 -04:00
|
|
|
|
}
|