* Introduce contract key to exercise node
Track the contract key in NodeExercises. This is in
preparation for adding the key into exercise events, and
for support for contract keys in kvutils, where we need
to be able to compute the outputs of the submission, e.g.
the contract key that would be unset by a consuming exercise.
This introduces transaction version 8.
* Move release note on contract keys in exercises to unreleased.rst
* Address Stephen's review
- Drop changelog entry for this change as it is not user facing
- Add info on version 8 to transaction.rst. Fix typo in version 7.
- Reorder VersionTimeline as per review
- Only compare the NodeExercise 'key' if it is set in the original
transaction (in order to compare transactions in a backwards
compatible manner)
* Unbork unreleased.rst
I find the current names very confusing and unintuitive.
I'm aware that there are other primitives called `TO_TEXT_X`. But there the
`X` is meant to be a type index to `TO_TEXT`. This doesn't make much sense in
the context of `TO_TEXT_CODE_POINTS` though since there's no type named
`CodePoints`.
* encode ast in protobuf
* daml-lf parser: make defaultPackageId and languageVersion parametric
* daml-lf rewritting of AST
* test ast encoder
* copyright
* test function type encoding
* daml-lf add parameter to parser implicits
* damlfl-as stands for "damllf assembler"
* move encoder in its own private package
* Make the actors optional in DAML-LF's exercise instruction
If they are not present, the controllers will be filled in. Surface DAML
does this currenty anyway by fetching the contract and computing the
choice controllers before each `exercise`. This change will allow for
getting rid of the additional `fetch` preceding each `exercise`.
The compiler does not use the new form yet. I will do this in a separate
PR together with tests for the new behaviour.
This fixes#1347.
* Fix DAML-LF type checker test
* Check presence of actors for old DAML-LF versions in decoder
* Rename Value's ContractId to VContractId
* daml-lf: a bit more about PartyId
* daml-lf: Concatenable MatchingStringModule
* daml-lf make clear type used for Scenarios only
* daml-lf create ContractId, LedgerId, TransactionId
* sandbox-sql conversion util
* LedgerName -> LedgerString
* futher type cleanup in the sandbox
* daml-lf add test for LedgerString
* fixing tests
* a bit more safety in the DB
* Address Stephen's comments
* fix rebase
* More fixes for StringModule
* change length of LedgerString (256 -> 255)
* daml-lf: make Decimal type safe
* daml-lf: create Utf8String type
* daml-lf: cleanup in data package
* Address Stephen Comments
* daml-lf: remove UTF8String
* enable Return wartremover wart
* remove return keyword from various places in daml-lf
* remove return keyword from various places in ledger
* simpler ImmArray equals
* move traverseEitherStrictly to point of use
* remove return from ledger-api-server-example
Up to now, the engine blindly assumed that contract ids pointed to
contracts of the right type. However, this assumption is faulty:
contract ids coming from the Ledger API cannot be type checked
in command translation since we need access to the contract itself
to do so.
This caused some seriously surprising / broken behavior: one could
send an exercise command with the wrong template id and still go
through, or break internal invariants about the type of choices.
This commit fixes this by checking that the type of the contract
instances we fetch is correct at runtime.
cc @hurryabit @dajmaki @remyhaemmerle-da @S11001001 @meiersi-da
* remove outdated flags from comments
* update tests in preparation for visibility rules
* check visibility of contract keys, fixes#751
* add release notes
* include visibility check in scenario runner
* stephen's suggestions
* fix type error in api server example
* scalafmt
* bring TransactionFiltration.scala up to speed with disclosure
see
<faf1cde1a1/ledger-api/grpc-definitions/com/digitalasset/ledger/api/v1/event.proto>
for an in-depth description. fixes#794.
* add tests for contract key visibility
* move a lot of ledger testing utils out of command checks
* move a lot of ledger testing utils out of command checks
* remove useless checks regarding divulgence
* add tests regarding event witnesses
* update release notes
* re-introduce safety when disclosing
Add field 'usedPackages' to Transaction to record the packages
that were used during interpretation to produce said transaction.
This serves as a hint to specify what packages are required to
validate the transaction. Note that this may not be sufficient
for future implementations that e.g. compile DAML-LF to JVM
bytecode and require packages containing only type definitions
as inputs.
This hint is mainly required for ledger implementations for which the
packages are tracked similarly to contract instances, and which
require that all inputs to their transaction must be declared
beforehand.
This work is required for the participant-state key-value utilities
described in issue #410 and implemented in PR #637.
* GenTransaction.WithTxValue alias
* undo parts of parent dealing explicitly with serialization
* use GenNode.WithTxValue more often
* use Node*.WithTxValue more often
* Add release notes entry
* Add CreateAndExercise command to Java Bindings data layer
* Add CreateAndExercise command to DAMLe
The CreateAndExerciseCommand allows users to create a contract and
exercise a choice on it within the same transaction. Users can use this
method to implement "callable update functions" by creating a template
that calls the update function in a choice body.
Fixes#382.
* Add CreateAndExercise command handling to the sandbox
* Add CreateAndExercise command to the Ledger API
* fix various conversion functions from string to Decimal
Fixes#399.
This fixes a critical bug -- since:
* The DAML-LF spec specifies that the scale of `Decimal` is 10 --
that is, there are at most 10 digits past the decimal point:
<79bbf5c794/daml-lf/spec/value.rst (field-decimal)>.
* However, the code converting from the string representation that
we get on the wire was _not_ performing this check. This is due
to two reasons:
- `Decimal.check` is a function that checks whether a given
`Decimal` is within the upper and lower bounds of what the
DAML-LF spec specifies, but crucially it does _not_ check that
the scale is not exceeded:
<79bbf5c794/daml-lf/data/src/main/scala/com/digitalasset/daml/lf/data/Decimal.scala (L31)>.
This behavior is correct in some cases (more on that later),
but not in others. Crucially, `Decimal.fromString`, which was
supposed to check if a decimal string literal is valid, used
this function, which means that it accepted string literals
containing numbers out of the required scale, rounding them to
make them fit within the scale. This function has been renamed
to `Decimal.checkWithinBoundsAndRound`, and a new function
`Decimal.checkWithinBoundsAndWithinScale` has been added, which
fails if the number provided has data not within the scale.
`Decimal.fromString` now uses
`Decimal.checkWithinBoundsAndWithinScale`.
- `ApiToLfEngine.parseDecimal` assumed that `Decimal.fromString` _did_
fail when passed numbers that were in any way invalid, and
moreover did _not_ use the result of `Decimal.fromString`, but rather
re-parsed the string into an unconstrained `BigDecimal`:
<79bbf5c794/ledger/ledger-api-common/src/main/scala/com/digitalasset/platform/participant/util/ApiToLfEngine.scala (L96)>.
The reason for the code to work this way is that in the past
it was responsible for converting decimal strings both for the
current engine but also for an older version of the engine which
handled decimals of a different type. Both issues have been fixed.
* Therefore, `Decimal`s with scale exceeding the specified scale
made it into the engine, and contracts could be created containing
this invalid value.
* Once on the ledger, these bad numbers can be used to produce extremely
surprising results, due to how `Decimal` operations are
implemented. Generally speaking, all operations on `Decimal`
first compute the result and then run the output through
`Decimal.checkWithinBoundsAndRound`. The reason for this behavior
is that we specify multiplication and division as rounding their
output. Consider the case where the bad value 0.00000000005 made
it to the engine, and is then added to 100. The full-precision
result will be 100.00000000005, which after rounding becomes 100.
Therefore, on a ledger where such invalid values exist, it is not
the case that `y > 0 ==> x + y != x`, and so on.
Thanks a bunch to @briandbecker for the excellent bug report.
* fix failing test using to much precision
* Add buildifier targets.
The tool allows to check and format BUILD files in the repo.
To check if files are well formatted, run:
bazel run //:buildifier
To fix badly-formatted files run:
bazel run //:buildifier-fix
* Cleanup dade-copyright-headers formatting.
* Fix dade-copyright-headers on files with just the copyright.
* Run buildifier automatically on CI via 'fmt.sh'.
* Reformat all BUILD files with buildifier.
Excludes autogenerated Bazel files.
* Do not divulge contracts to observers in nonconsuming exercises
Disables support for non-default ledger feature flags, as they
are meaningless since ledger server logic does not respect the flags.
Instead of large refactoring to add support for the old flag settings,
it is best to disallow the deprecated flags, and later on phase out the
flags completely.
Re-enables test_divulgence_of_token in sandbox semantic tests.
Fixes#157.
* purge LedgerFlags entirely...
...since we only support one version of them anyway, and clearing them
* updated release notes
