Folkert
d6632981c8
update Num.roc
2022-04-08 16:47:17 +02:00
Folkert
beee95f83c
parse the header of builtins too
2022-04-08 16:02:30 +02:00
Folkert
1d0f9e9192
Merge remote-tracking branch 'origin/trunk' into builtins-in-roc
2022-04-08 15:47:11 +02:00
Richard Feldman
8322ed95ed
Merge pull request #2806 from rtfeldman/toF32
...
Num.toF32/toF64 for LLVM backend
2022-04-08 08:28:07 -04:00
Richard Feldman
bfb7bb3874
Update comment
2022-04-07 18:36:33 -04:00
Ayaz Hafiz
17b3c7d8ee
Generate type variables when there are lots
...
Closes #2797
2022-04-07 17:49:48 -04:00
Richard Feldman
6adaf0905e
Fix missing * in type annotation
2022-04-07 16:29:17 -04:00
Richard Feldman
4dc7e61f3f
Move conversion tests to test_gen
2022-04-07 16:27:01 -04:00
Richard Feldman
a4233ad661
Add LLVM implementation for toF32/64
2022-04-07 16:13:58 -04:00
Richard Feldman
cd00a98636
Add toF32/64 and checked versions
2022-04-07 16:13:57 -04:00
Richard Feldman
bd623d65bc
Formatting whitespace
2022-04-07 16:13:57 -04:00
Ayaz
23bc8aab49
Merge pull request #2805 from rtfeldman/type-vs-value-defs
...
Split up Defs into TypeDef and ValueDef
2022-04-07 14:04:05 -04:00
Ayaz Hafiz
c7d439136b
Flip refcount test symbols
2022-04-07 08:54:07 -04:00
Brian Carroll
9116770a00
wasm: Adjust List.map code gen for capacity
2022-04-07 09:29:42 +01:00
Brian Carroll
2b74e55240
Merge branch 'trunk' of github.com:rtfeldman/roc into wasm-higher-order-calls
2022-04-07 09:03:34 +01:00
Ayaz Hafiz
d3b848fa46
Clippy
2022-04-06 22:24:14 -04:00
Ayaz Hafiz
a3ac68a41f
Split up Defs into TypeDef and ValueDef
...
Just a refactoring PR. This is useful because during canonicalization
we always process type defs first, then value defs. With abilities this
distinction continues to grow; in that case, we have patterns associated
with types that we want to process before patterns from values.
2022-04-06 22:18:57 -04:00
Ayaz
37729c08cc
Merge pull request #2802 from rtfeldman/abilities-multi-def-parse
2022-04-06 14:14:46 -04:00
Richard Feldman
c19f8acb8c
Merge pull request #2781 from rtfeldman/zig-macos
...
add target triple for zig on macos
2022-04-06 13:43:11 -04:00
Ayaz Hafiz
eee19bba2b
s/demands/members
2022-04-06 11:34:55 -04:00
Ayaz Hafiz
bd8333ebb1
Parse multiple abilities behind each other
2022-04-06 11:20:51 -04:00
Ayaz Hafiz
2dc0445f46
s/AbilityDemand/AbilityMember
...
This is a better name
2022-04-06 11:20:34 -04:00
Ayaz
d58300e016
Merge pull request #2799 from rtfeldman/i/2583
...
Unify type alias "real variables"
2022-04-05 18:40:02 -04:00
Ayaz Hafiz
72b93e51f1
Bugfix
2022-04-05 18:08:24 -04:00
Ayaz Hafiz
886e5a0c8f
Don't unify real vars when there are no type variables, or nothing changed
2022-04-05 17:51:30 -04:00
Folkert de Vries
d3a3b6456a
Merge pull request #2800 from rtfeldman/parse-out-dec-suffix
...
Make sure float suffixes are parsed out after can
2022-04-05 23:43:15 +02:00
Ayaz Hafiz
9fbc525d02
Make sure float suffixes are parsed out after can
...
Before we hit mono, we need to make sure the suffixes of numeric
literals are parsed out from the literal string, so that we don't try to
parse something whose type we already know but has the extraneous
suffix.
Co'ed with @tagraves
2022-04-05 11:32:34 -04:00
Ayaz Hafiz
163c6b39d6
Unify type alias "real variables"
...
Turns out that we can't always assume that a successful unification of
type alias type variables means that those aliases had the same real
type from the start. Because type variables may contain unbound type
variables and grow during their unification (for example,
`[InvalidNumStr]a ~ [ListWasEmpty]b` unify to give `[InvalidNumStr,
ListWasEmpty]`), the real type may grow as well.
For this reason, continue to explicitly unify alias real types for now.
We can get away with not having to do so when the type variable
unification causes no changes to the unification tree at all, but we
don't have a great way to detect that right now (maybe snapshots?)
Closes #2583
2022-04-05 11:21:52 -04:00
Richard Feldman
08466380df
Merge pull request #2798 from rtfeldman/wasm-fix-dec-isfinite
...
Wasm: fix Num.isFinite for Dec
2022-04-04 20:58:46 -04:00
Richard Feldman
b35cc6ac8c
Merge pull request #2795 from rtfeldman/i/2582
...
Deal with fastcc return-by-pointer convention correctly
2022-04-04 20:14:49 -04:00
Brian Carroll
0910831f59
wasm: fix Num.isFinite for Dec
...
When I wrote this code I thought it was the base10 floating point format,
but in fact it's fixed-point.
2022-04-05 00:02:31 +01:00
Brian Carroll
a07cac6682
PR tweaks
2022-04-05 00:02:05 +01:00
Brian Carroll
e342b21d43
wasm: enable some List.map tests
2022-04-05 00:02:05 +01:00
Brian Carroll
ab3a75b754
wasm: fix WasmLayout for LambdaSet
2022-04-05 00:02:05 +01:00
Brian Carroll
a63e55e023
wasm: fix stack order in higher-order wrapper
2022-04-05 00:02:05 +01:00
Brian Carroll
b1f15799e3
wasm: Ensure TableSection matches ElementSection
2022-04-05 00:02:05 +01:00
Brian Carroll
8620cdf75c
wasm: function pointers for higher order calls
2022-04-05 00:02:05 +01:00
Brian Carroll
5db3ae0227
wasm: code gen for higher order wrapper function
2022-04-05 00:02:05 +01:00
Brian Carroll
51789f38c2
wasm: generate RC inc for higher order builtins
2022-04-05 00:02:05 +01:00
Brian Carroll
05459455ec
wasm: ProcLayout for higher order wrapper fns
2022-04-05 00:02:05 +01:00
Brian Carroll
83cae16a60
wasm: Generate code for List.map call (incomplete)
2022-04-05 00:02:05 +01:00
Brian Carroll
ff9bbfab63
wasm: generate code for ZigCC wrapper function
2022-04-05 00:01:11 +01:00
Brian Carroll
973d6dc41f
wasm: Create ProcLookupData structure to help with callconv wrapper
2022-04-05 00:01:11 +01:00
Brian Carroll
448140d223
wasm: refactor to prepare for HigherOrder calls
2022-04-05 00:01:11 +01:00
Ayaz Hafiz
0f0e56a21c
Deal with fastcc return-by-pointer convention correctly
...
Closes #2582
2022-04-04 16:33:01 -04:00
Folkert
68536e4026
Merge remote-tracking branch 'origin/trunk' into list-str-capacity
2022-04-04 19:55:04 +02:00
Folkert
1e397e950d
changes after review
2022-04-04 19:53:33 +02:00
Brendan Hansknecht
19c02aa087
Merge pull request #2789 from rtfeldman/atomic-rc
...
Use zig for all refcounts and add atomic support
2022-04-03 22:23:28 +00:00
Brendan Hansknecht
3ef40e2e82
use exhaustive refcount pattern match
2022-04-03 13:29:16 -07:00
Brendan Hansknecht
6f8de4492e
correct typo
2022-04-01 23:09:32 -07:00
