Fixes multiple issues with stack traces leading to missing
stack trace lines. Also, we no longer put builtin context
on the line which *calls* the builtin as if it was a part
of the builtin itself.
Code for stack trace handling was centralized. We no longer
need traceElement argument in ~every function. Now the stack
trace state is kept solely in the interpreter.
When adding long strings, don't copy them immediately. Instead
build long strings only when their contents are requested.
This allows to build a long string from parts, using a regular
operator+ in linear time. This lets users to worry much less
about using std.join etc.
If indexing the string is mixed with building it using operator+
the behavior can still be quadratic. We may want to address it in
a later change.
This change adds caching to objects fields, i.e. now subsequent
references to an object field are going to be served from cache.
Cache is kept within an object. Objects created with operator +
start with a clean cache (they have to, because in general all
the fields may have changed their values due to late binding).
This change comes naturally with a change of structure of objects,
now valueObject is a concrete struct which keeps "uncachedObject"
which is roughly equivalent to old objects.
When object fields are evaluated the locals from the object
are added to the environment. These locals should have the same
environment as the field, in particular they should be
at the same inheritance level. Instead they were evaluated as if
they were on the level from which original field lookup was performed,
resulting in subtle and hard to debug issues.
Keep object locals only once in AST
For example this reduces the size of stdlib ast file
roughly 3x. Note that this change doesn't regenerate the stdlib,
so that the diff here is sane.
It is likely to slightly improve performance of code using
a lot of locals (~10% on bench.05.gen.jsonnet).
The desugaring is more strightforward now, and we're back
to desugaring each node exactly once.
People use these operators in tight loops, without even
thinking about it, and it's previous implementation required
multiple object lookups (std.), string comparisons (for types)
and multiple jsonnet function calls.
This change introduces builtin, efficient implementation.
It results in ~3x speedup in strContains benchmark that
Angus provided on Slack.
Additional benefit is that equals/primitiveEquals distinction
is now obsolete, which made things simpler for everyone.
EvaluateSnippetMulti comment was copied from another function by mistake.
Add a space between the license and the package name.
Add a few periods after the comments.
Fixesgoogle/go-jsonnet#160
Fix a bunch of bugs:
- Reverse meaning of boolean argument to objectFieldsEx and objectHasEx
- Slice desugaring using `std.slice` instead of `slice` as a field name.
Support + on string and something else.
Support + on arrays
assertEqual should now work properly
* Array comprehensions
Implemented using flatMap.
The representation in AST was changed - now it expresses
the semantic structure better.
Ifs in comprehensions are not supported yet, but easy.
* Interpreter & runtime - minimal usable version
Accomplishments in this commit:
* Majority of language features implemented:
* Unary operators
* Binary operators
* Conditionals
* Errors
* Indexing arrays
* Indexing objects
* Object inheritance
* Imports
* Functions
* Function calls
* There is a quite nice way for creating builtins
* Static analyzer is there with most of the functionality
* Standard library is included and parts unaffected by missing features
work
* Some bugs in existing parts fixed
* Most positive tests from C++ version pass, the rest is failing mostly
due to missing builtins and comprehensions.
* Some initial structure was created that should allow more incremental
and focused changes in the future PRs.
* Some comments/explanations added
* Panics translated to a little bit more gentle internal errors (with a
link to issues on github).
What still sucks:
* Stack traces & error messages (there's some stuff in place)
* Almost everything is in the same package
* Stuff is exported or unexporeted randomly (see above)
* Missing a few lexing/parsing features
* Missing builtins
* Missing support for extvars and top-level-args
* Checking function arguments is missing
* No clean Go API that commandline and compatibility layer to C can use
* No compatibility layer to C
* Assertions don't work (desugaring level, assertEquals works).
* Manifestation stack traces (and generally it could use some work).
* The way environments are constructed is sometimes suboptimal/clumsy.
