Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keep casts of the form x ~ Integer #1928

Closed
wants to merge 1 commit into from
Closed

Keep casts of the form x ~ Integer #1928

wants to merge 1 commit into from

Conversation

christiaanb
Copy link
Member

Really a work-around until we properly handle all casts.

Fixes #1927

  • Write a changelog entry (see changelog/README.md)
  • Check copyright notices are up to date in edited files

Really a work-around until we properly handle all casts.

Fixes #1927
@@ -659,6 +659,8 @@ isSizedCast (TyConApp tc1 _) (TyConApp tc2 _) = do
,tc2 `hasKey` naturalTyConKey &&
tc1Nm == "Clash.Sized.Internal.Unsigned.Unsigned"
])
-- XXX: a work-around for issue #1927, the real fix is to handle all casts
isSizedCast (TyVarTy {}) (TyConApp tc2 _) = return (tc2 `hasKey` integerTyConKey)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this also need a case for Integer ~ x?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not for issue #1927 specifically.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, but would you trigger the same issue by changing counter ~ (Index numStages) to (Index numStages) ~ counter in the test? If so I think we should add the extra case to avoid weird (albeit unlikely) situations where someone's design fails unexpectedly unless they change the argument order to (~)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't tried. I'm somewhat uncomfortable with this PR to begin with. I'd rather properly support all casts.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, supporting all casts would be the better option. How far was #1064 from being finished?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It went in the right direction. But I would want to redo some aspects, especially with regards to Tick. So squashCollectApp was there in terms of handling casts I think, but Ticks still need more care: depending on the type of info (source location, HDL naming, etc.) the ticks either should or shouldn't be distributed towards the arguments as we "squash" the entire application.

@martijnbastiaan
Copy link
Member

Superseded by #1064

@martijnbastiaan martijnbastiaan deleted the fix1927 branch July 10, 2024 12:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use of satSucc triggers "Not in normal form: application of a Lambda-expression"
3 participants