Commit Graph

18 Commits

Author SHA1 Message Date
Remy
0591075187 cleanup daml-lf scala packages (#1581)
* cleanup daml-lf scala packages

* Address Stephen's Comments

* update maven coordinates of language package
2019-06-12 15:55:48 +00:00
Remy
bf5309b42e daml-lf: add enum pattern matching (#1506)
* daml-lf: add enum pattern matching

* daml-lf: add test for interpreter pattern matching
2019-06-04 22:25:22 +00:00
Remy
0d25b73d1f daml-lf add builtin to (un)pack string in code points (#1480)
, namely

* FROM_TEXT_CODE_POINTS: Text -> [Int64]
* TO_TEXT_CODE_POINTS: [Int64] -> Text
2019-06-04 14:06:25 +00:00
Remy
f84e7d79d2 Add enum type to daml-lf (#1397)
* add enum type to daml-lf dev

* Address Francesco's comments

* Address Martin's comments

* fix daml-lf proto version history
2019-05-29 12:15:01 +00:00
Martin Huschenbett
2605f00804 Freeze DAML-LF 1.dev into DAML-LF 1.5 (#1408)
* Freeze DAML-LF 1.dev into DAML-LF 1.5

In other words, we release DAML-LF 1.5.

This is required for generic templates (#1387).

* description of FROM_TEXT_INT64 & FROM_TEXT_DECIMAL

* amend version history

add ``FROM_TEXT_INT64`` and ``FROM_TEXT_DECIMAL`` in the specification changelog

* typos

* Fix markup in DAML-LF spec

* Add release notes
2019-05-27 21:11:37 +00:00
Remy
439613bee8 daml-lf: add FROM_TEXT_INT64 and FROM_TEXT_DECIMAL (#1407)
* daml-lf: add FROM_TEXT_INT64 and FROM_TEXT_DECIMAL

* Fix typos in Haskell

* cosmetic change

* Fix DAML-LF type checker

* Fix merging fallout
2019-05-27 17:19:01 +00:00
Martin Huschenbett
c30ec0fc03
Make the actors optional in DAML-LF's exercise instruction (#1377)
* 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
2019-05-24 15:01:56 +02:00
Martin Huschenbett
b09cbd037b
Add coerce for contract ids to DAML-LF (#1346)
* Add coerce for contract ids to DAML-LF

This is needed for our implementation plan for generic templates.

Fixes #1277.

* Reformat Scala
2019-05-24 09:08:15 +02:00
Martin Huschenbett
8ec03875c6
Lift restriction on serializable contract ids in DAML-LF 1.dev (#1315)
* Lift restriction on serializable contract ids in DAML-LF 1.dev

In DAML-LF 1.dev, make `ContractId a` serializable whenever `a` is
serializable. This is part 2 of #1277.

* Reformat Scala

* Add changelog entry to daml_lf_1.proto
2019-05-22 22:23:59 +02:00
Martin Huschenbett
a50c2edf9a
Fix package validation for DAML-LF 1.4 (#1316)
* Fix package valdiation for DAML-LF 1.4

Currently, complex contract keys are are not accepted for DAML-LF 1.4
although they should because we forgot to roll the version when freezing
DAML-LF 1.4.

@bitonic we need a way forward to avoid this in the future.

* Fix test

* Format Scala
2019-05-22 22:22:57 +02:00
Martin Huschenbett
d87ba19ea2 Add more tests for (un)serializable contract ids (#1296)
* Add more tests for (un)serializable contract ids

I want to lift this restriction in a subsequent PR for the next version
of DAML-LF. Let's first make sure we have a correct implementation for the
current version though.

* fix test

* in serializability tests, check the modules are properly typed
2019-05-22 10:19:51 +00:00
Martin Huschenbett
24e305c1af Relax syntactic restriction on contract keys in DAML-LF 1.dev (#1219)
* Relax syntactic restriction on contract keys in DAML-LF 1.dev

We lift the syntactic restriction that contact keys must be built using
only record constructions and projections entirely when compiling to
DAML-LF 1.dev. To make this more useful, we also search all sub-expressions
of `maintainer` in `key` during our rewriting of `maintainer` for using
`this` to using `key`.

As one of our next steps we should bring `key` into scope in `maintainer`
and perhaps deprecate the use of `this` at some point in the future.

* Fix versioning

* Adapt package validation to complext contract keys
2019-05-17 20:06:23 +00:00
Remy
2e3a87934b Daml lf type safty (ChoiceName, VarName, FieldName, ConstructorName) (#983)
* daml-lf: make DefinitionRef more typesafe

* daml-lf: Identifier -> DefinitionRef

* daml-lf: remove unsafe apply and copy methods from DottedName

* daml-lf: create identifier

* daml-lf: make ChoiceNames Identifiers

* daml-lf: cleanup TVar

* daml-lf: FieldNames & VariantConstructors -> Identifiers

* bazel fmt

* daml-lf: VarName -> Identifier

* daml-lf: drop return inside Ref.scala

* daml-lf Identifier -> Name

* daml-lf DefinitionRef -> Identifier

* daml-lf make iface more type safe
+ address Francesco's comments

* daml-lf: remove unsafe unapply from MatchingStringModule

* fix navigator

* Address Stephen's Comments
2019-05-13 11:17:12 +00:00
Stephen Compall
a3e9aad147
remove major LF dev version (#681)
* removing major LF dev version from Haskell proto codecs

* removing major LF dev version from scenario service client

* missed import

* remove Scala support for dev major version; remove --allow-dev option from sandbox cli

* Version.minorFromCliOption function

* don't build daml-stdlib artifacts for dev major

* remove damlc CLI --target dev

* release note about removed dev major LF version

* governance now discusses minor dev, no more major dev

* don't build from daml_lf_dev.proto anymore

* remove daml_lf_dev.proto

* raise deprecated release

* reserve 9999 in the ArchivePayload sum, as suggested by @bitonic

* use reserved proto keyword, as suggested by @bitonic

- `reserved` cannot occur within `oneof` block

* remove --allow-dev test

* dev removal release note followed the previous release; move it back to HEAD
2019-04-26 13:10:09 -04:00
Francesco Mazzoli
6af84051ee
fix various conversion functions from string to Decimal (#439)
* 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
2019-04-14 13:49:28 +02:00
gleber
aa70c7f64e
Enforce consistent formatting of BUILD files. (#412)
* 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.
2019-04-12 13:10:16 +02:00
moritzkiefer-da
fa4067ad1b
Move POM file generation to Bazel rules (#374)
* Move POM file generation to Bazel rules
2019-04-11 11:24:52 +02:00
Digital Asset GmbH
05e691f558 open-sourcing daml 2019-04-04 09:33:38 +01:00