roc/crates/compiler/unify/Cargo.toml

[package]
name = "roc_unify"
description = "Implements Roc's unification algorithm, the heartstone of Roc's type inference."

authors.workspace = true
edition.workspace = true
license.workspace = true
version.workspace = true

[dependencies]
bitflags.workspace = true

[dependencies.roc_collections]
path = "../collections"

[dependencies.roc_error_macros]
path = "../../error_macros"

[dependencies.roc_module]
path = "../module"

[dependencies.roc_types]
path = "../types"

[dependencies.roc_debug_flags]
path = "../debug_flags"

[dependencies.roc_tracing]
path = "../../tracing"

[dependencies.roc_checkmate]
path = "../checkmate"
Move solve and unify into their own crates 2020-03-06 09:42:53 +03:00			`[package]`
centralize package versions except for vendor and excluded 2023-03-07 06:29:09 +03:00			`name = "roc_unify"`
			`description = "Implements Roc's unification algorithm, the heartstone of Roc's type inference."`

update to using workspace package spec 2023-03-07 03:36:18 +03:00			`authors.workspace = true`
			`edition.workspace = true`
			`license.workspace = true`
			`version.workspace = true`
Move solve and unify into their own crates 2020-03-06 09:42:53 +03:00
			`[dependencies]`
centralize package versions except for vendor and excluded 2023-03-07 06:29:09 +03:00			`bitflags.workspace = true`
Treat rigids as flex vars when checking number range types 2022-02-06 21:42:28 +03:00
			`[dependencies.roc_collections]`
			`path = "../collections"`

Add needed imports 2022-04-12 22:36:36 +03:00			`[dependencies.roc_error_macros]`
			`path = "../../error_macros"`

Treat rigids as flex vars when checking number range types 2022-02-06 21:42:28 +03:00			`[dependencies.roc_module]`
			`path = "../module"`

			`[dependencies.roc_types]`
			`path = "../types"`
Factor bespoke debug variables into debug_flags crate 2022-04-30 00:45:55 +03:00
			`[dependencies.roc_debug_flags]`
			`path = "../debug_flags"`
Wrap unification subs in Env 2022-07-26 00:36:46 +03:00
Support custom abilities for opaques with immaterial lambda sets If a specialization of an ability member has a lambda set that is not reflected in the unspecialized lambda sets of the member's prototype signature, then the specialization lambda set is deemed to be immaterial to the specialization lambda set mapping, and we don't need to associate it with a particular region from the prototype signature. This can happen when an opaque contains functions that are some specific than the generalized prototype signature; for example, when we are defining a custom impl for an opaque with functions. Addresses a bug found in https://github.com/roc-lang/roc/pull/4427/commits/8c3158c3e0af48ac96dbb1db0873684299afc1fb 2022-11-22 03:00:56 +03:00			`[dependencies.roc_tracing]`
			`path = "../../tracing"`
Hide subs behind Env deref 2023-07-16 17:09:26 +03:00
			`[dependencies.roc_checkmate]`
			`path = "../checkmate"`