M-Labs/nac3
M-Labs
/
nac3
8
0
Fork 10
Code Issues 99 Pull Requests 21 Releases Wiki Activity

Use sequenced collection for VarMap #388

Merged
sb10q merged 1 commits from refactor/sequenced-varmap into master 2024-03-25 12:44:43 +08:00
Conversation 0 Commits 1 Files Changed 12 +30 -35
derppening commented 2024-03-21 19:15:11 +08:00
Collaborator
Copy Link

While tackling the issue of type variables (still) not outputting according to their declared order, I realized that neither BTreeMap nor Vec are good enough solutions.

  • BTreeMap sorts automatically by its key (in our case, the type variable ID). However, some type variables at the same position will be generated more than once during declaration parsing (e.g. A[typevar40, typvar37]), therefore the order of type variables will be wrong.
  • Vec is a sequenced container, however VarMap also wants guarantees that no two entries share the same type variable ID, as this would mean that the same type variable possesses two values at the same time.

To solve this, VarMap is now aliased to IndexMap, which preserves the insertion order of elements, and uses the insertion order as its default iteration order.

While tackling the issue of type variables (still) not outputting according to their declared order, I realized that neither `BTreeMap` nor `Vec` are good enough solutions. - `BTreeMap` sorts automatically by its key (in our case, the type variable ID). However, some type variables at the same position will be generated more than once during declaration parsing (e.g. `A[typevar40, typvar37]`), therefore the order of type variables will be wrong. - `Vec` is a sequenced container, however `VarMap` also wants guarantees that no two entries share the same type variable ID, as this would mean that the same type variable possesses two values at the same time. To solve this, `VarMap` is now aliased to `IndexMap`, which preserves the insertion order of elements, and uses the insertion order as its default iteration order.
derppening added 3 commits 2024-03-21 19:15:11 +08:00
84a888758a core: Rename unsafe functions to unchecked 
This is this intended name of the functions.
derppening added a new dependency 2024-03-21 19:15:18 +08:00
#387 Add miscellaneous abstraction
derppening force-pushed refactor/sequenced-varmap from d03ad8a1c4 to 9a8342d6d4 2024-03-21 20:38:10 +08:00 Compare
derppening force-pushed refactor/sequenced-varmap from 9a8342d6d4 to d2eb9255c3 2024-03-21 20:40:43 +08:00 Compare
derppening force-pushed refactor/sequenced-varmap from d2eb9255c3 to aa84cc425f 2024-03-21 21:12:30 +08:00 Compare
derppening force-pushed refactor/sequenced-varmap from aa84cc425f to ba9e417967 2024-03-22 15:08:05 +08:00 Compare
derppening force-pushed refactor/sequenced-varmap from ba9e417967 to d49f8b4a81 2024-03-22 15:21:48 +08:00 Compare
derppening force-pushed refactor/sequenced-varmap from d49f8b4a81 to edd9832f6c 2024-03-22 15:34:23 +08:00 Compare
derppening force-pushed refactor/sequenced-varmap from edd9832f6c to ae2c1a7ee5 2024-03-22 15:40:43 +08:00 Compare
derppening force-pushed refactor/sequenced-varmap from ae2c1a7ee5 to 13f06f3e29 2024-03-22 15:51:29 +08:00 Compare
sb10q merged commit 13f06f3e29 into master 2024-03-25 12:44:43 +08:00
sb10q deleted branch refactor/sequenced-varmap 2024-03-25 12:44:44 +08:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
future-extension

   
high-priority

   
low-priority

   
UROP0622
No Label
future-extension
high-priority
low-priority
UROP0622
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Depends on
#387 Add miscellaneous abstraction
M-Labs/nac3
Reference: M-Labs/nac3#388
No description provided.
Delete Branch "refactor/sequenced-varmap"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?