In the first pass I erred on the cautious side, only migrating safe
bets, to here's some trivial migrations that I missed
Change-Id: I934011919837b0aa491113afdcad603cf6b9cbbb
All changes are uniform and done with the same script, so checking only
some should suffice. For that reason, any tests involving multiple files
or custom CLI flags are not included in this commit.
Change-Id: Ib2d0e08937b56e241d99771a58aad34ed3ad308a
The current `RelativeTo` design is both more complex and more confusing
than necessary. Its four variants are now reduced to only two. They are
now also represented as different classes, to better communicate the
difference in semantics and also intent.
Change-Id: Ia60fc7a2dfa0f62bdef90dde347fd8603fd3fbf9
That file was written once in 2008 and never updated since, and let's
just say that a lot of things have changed since
Change-Id: I66b0c87ecbba6ca653470966c9514edb21882ca3
It was introduced back in 2013, was disabled in 2014 again for dubious
reasons and according to horrors is unsound anyways and can never really
work.
It was the only disabled test, so I removed the "infrastructure" for
that in the test runner as well. functional2/lang will have much better
ways for skipping tests anyways
Change-Id: Icb8697fb85221e3206fb64cb917c03607ef278a7
Back in the days, this used to be the modus operandi, but then, still
many but less years ago, Eelco came along and changed it to passing in
the actual file. Of course, no motivation was provided, and it was only
done on half of the test runners for some reason, leaving us to wonder
what the true intentions of this code are …
Anyways, with this commit now everything standardises on passing in the
file by path instead of via stdin. Motivation:
- We need to `sed` out the path anyways for various other reasons,
including import tests and path value tests
- Given that, the presumed primary motivation for using stdin in the
first place becomes moot
- Bonus points for giving better error messages, especially in tests
that involve multiple input files
Change-Id: Ic6de1ec24f4c4d3c05e33d1ee053614784677513
Don't ask me the fuck why, but *somehow* Nix prints error locations
differently if the input file is passed as a path vs through stdin, and
I have a hunch that this might have to do with tabs
Change-Id: I186b0edb90edd48856da3621815463e372c37512
Currently, all tests are relative to `./tests/functional` instead of
`./tests/functional/lang`. Whether this is a historical artefact or as
intended, the current move is to align the tests with the new design of
functional2, preparing them for an easier migration.
Change-Id: Ie394691b071488a8000a005080b9167786d5bd9a
Now that we can correctly point to all expressions, we can remove
redundant intermediate traces to reduce clutter.
Co-authored-by: eldritch horrors <pennae@lix.systems>
Co-authored-by: Raito Bezarius <raito@lix.systems>
Change-Id: I3e9d7c1c7a6599a8e68302448bbb961d051002b7
We now properly shell out to the parser instead of hacking stuff
together with a regex. Stuff we get for free by doing this:
- Optional trailing semicolon
- Declaring nested attribute sets
- String identifiers, and future proofing for eventual grammar
improvements to identifiers
- Dynamic attributes
Change-Id: Ibf1ad815e5e27caf162df05ea5ba5b1b4955d9c9
I've always been annoyed that it just silently succeeded without any
feedback, but now with the upcoming improvements on defining variables
this is more necessary than ever.
Change-Id: I565897fa2f97cf6f567d4449dcc8d4ad4eb73fce
- `pos` is not used anymore and can be removed
- `path` and `value` are more correctly placed in their own sub state,
to mirror `InheritState`
Change-Id: Ie7c8a3aea3fe4af0f9c5c15ab5897a59d1b3f7b0
I absolutely want to go back to allowing them, I am strongly of the
opinion that nothing should be special about NUL in a string, but this
will have to wait until at least the GC rewrite, so for now the least I
can do is to disarm this gun.
Change-Id: Id14b6037bc8b274c6c60ad970b1c74d436fb62a7
They are broken beyond repair, and barring a language version revision
this is our only option besides doing nothing about it.
Change-Id: I25fa4f032ca9b5ca67356946bcd889289583592e
This is kind of a painful change, because a lot of code grew around the
bad abstraction, but the goal here is to abstract formals in a way that
allows adding other means of pattern matching / argument destructuring
in the future.
Change-Id: If4e681a4be3d1f42ceea81a8e07297f0d08acc80
I'm sorry but checking the name of the function arguments to be "final"
and "prev" is just absurd. That's like worst of
type-checking-meets-static-analysis. And the error message of the second
`throw` was not even good, as it mixed all three failure cases together.
Change-Id: Id4244171123dd8a228be71ce9f04d8e9f647c111
It has been renamed to `emplaceExpr` to be more consistent with the fact
that it actually creates the expression pointer. Moreover, `pushExpr`
has been added which directly takes a `unique_ptr<Expr>`.
All manual calls to `exprs.emplace_back` have been removed and replaced
with `pushExpr`, and `exprs` is now a protected field. This allows for
enforcing invariants and modifying state within `pushExpr`.
Change-Id: I995f0bdc1c090cf78080c9f0b7737e2be359b3e4
The code for serialization Expr nodes back into (pseudo-)Nix has been
removed for being subtly error-prone and tedious to maintain. Instead,
`nix-instantiate --parse` now prints a JSON representation of the AST.
Usage patterns of the --parse flag I've found in the wild:
1. Check if a file is well-formed, i.e. discard output and test exit code
2. Get parser errors from a file, i.e. discard stdout and use stderr
3. Nixfmt uses --parse to test equivalence pre/post format, and that property is (should be?) preserved
None of these should break with the current change
Closes#487
Change-Id: Icdbaad17790f2ad8765fa08e02e6597ee4c7a909
After gathering more community feedback, more non-trivial use cases for
overriding `__findFile` emerged. Unlike the use case of Tvix mentioned
in #599, these can't easily be worked around by overriding `nixPath`
instead.
This is the second fixup/partial revert for
81d5f0a7d9.
See also #599.
Change-Id: I7ca75e1a2b196c0da341969c61f4c168b5f657f9
It being overridable was an intended feature with good use cases, and
should not have been removed. However, this feature is generally in a
bad state and needs revisiting in the future.
Fixup for 81d5f0a7d9Fixes#599
Change-Id: I2d93e012caa65aa795bce3a71d8e56d7052ef9df
Calls to `show` have been removed. To counter the loss of information,
the error positions have been improved and now correctly point to the
current selector instead of the entire select expression.
Change-Id: I4771fe874af1ac15828a9863550cd4369a8f0e94
This is a pretty small change because the parser already has all
necessary information (needed for parse errors), now we want to keep it
to also provide better eval errors.
Change-Id: Ifc7a9516b9b0c8d9698f1899a6912ae91f6696ab
The `show` functionality needs to be removed because it is deeply
flawed, and given that we already print position information in the
error message (which probably wasn't always the case in the past) the
assertion printing is redundant anyways.
Change-Id: I1f5e05ab73aaa0ec92994c2211463260fd374898
ExprLet was previously inheriting from ExprAttrs for the data, while
ignoring all
set-specific operations on it. The set specific code has now been split
off so that
let doesn't inherit it anymore:
- ExprAttrs (not an Expr), containing the attributes and the related
logic
- ExprLet : Expr, ExprAttrs
- ExprSet : Expr, ExprAttrs
Co-authored-by: eldritch horrors <pennae@lix.systems>
Change-Id: I63f2fbcd1e790b3cffb56eec1e7565ee3cdbf964
It was never intended to be a feature to be used, and moreover it is
inconsistent: One cannot override `+`, and overriding `__lessThan` won't
affect the builtins which do comparisons.
Change-Id: Iaba54a05aa4c2eb37cdb3dc0d731fcee5a86deba
Some stuff wasn't working on my machine because it depended on the host
environment in some ways, fixed those.
Change-Id: Iff4931a9a26c6827978f1ee6434710f406d67a96
The old behavior results in lots of concatenations happening for no good
reason and is an artifact of the technical limitations of the old parser
(combined with some lack of care for such details).
Change-Id: I0d78d6220ca6aeaa10bc437e48e08bf7922e0bb3
This is only a minor semantical distinction, but we should be able to
properly test it, and the parser tests rely on show for that.
Change-Id: I25e868cf9544e30cdff17deb5fd50a434e0f367e
This commit should faithfully reproduce the old behavior down to the
bugs. The new code is a lot more readable, all quirks are well
documented, and it is overall much more maintainable.
Change-Id: I629585918e4f2b7d296b6b8330235cdc90b7bade
They are like experimental features, but opt-in instead of opt-out. They
will allow us to gracefully remove language features. See #437
Change-Id: I9ca04cc48e6926750c4d622c2b229b25cc142c42
The |> operator is a reverse function operator with low binding strength
to replace lib.pipe. Implements RFC 148, see the RFC text for more
details. Closes#438.
Change-Id: I21df66e8014e0d4dd9753dd038560a2b0b7fd805
Currently, the parser relies on the global experimental feature flags.
In order to properly test conditional language features, we instead need
to pass it around in the parser::State.
This means that the parser cannot cache the result of isEnabled anymore,
which wouldn't necessarily hurt performance if the function didn't
perform a linear search on the list of enabled features on every single
call. While we could simply evaluate once at the start of parsing and
cache the result in the parser state, the more sustainable solution
would be to fix `isEnabled` such that all callers may profit from the
performance improvement.
Change-Id: Ic9b9c5d882b6270e1114988b63e6064d36c25cf2
piegames