libexpr: allocate ExprPath strings in the allocator #14106
Merged
+10
−8
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
See this tracking issue for big-picture plan and motivation
Where does this fall in that picture?
Note that we've added a bunch of copies that weren't necessary before. This doesn't seem to impact performance. In the future, we can address this by passing the allocator down into functions like
getHome()
and having them allocate directly there instead.Rant about plans for removing the `accessor` field as well
I would like to also remove `ref accessor`. It does take up 16 needless bytes, but the bigger reason is that eventually I want `ExprInt`, `ExprFloat`, `ExprString`, and `ExprPath`, all the "literals" to be referred to **as** Values directly (See tracking issue's todo item "Combine `Expr`s and `Value`s into one address space...") This would remove a layer of indirection and the need to store the Expr at all, but it requires that they not have any other fields (i.e. `accessor`).The only thing
accessor
is doing is incrementing/decrementing a refcount for theSourceAccessor
. I scoured the internet and could not find a reasonable way to manually increment / decrement the refcount of anstd::shared_ptr
. I did come up with a janky way that involves usingmemset
andmemcpy
to skip constructors/destructors, but that seemed like a bad path to go down.I'm now thinking
boost::intrusive_ptr
is the way to go here, but I think we should tackle that down the road when it actually becomes relevant.Context
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.