-
Notifications
You must be signed in to change notification settings - Fork 485
Bug: Cannot construct a value of type: PlutusTx.Builtins.Internal.BuiltinUnit
#7162
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
base: master
Are you sure you want to change the base?
Conversation
|
97d926e
to
07b20e0
Compare
07b20e0
to
da0e24d
Compare
da0e24d
to
9e42a6c
Compare
…iltin types Add intelligent detection of stage violations when using PlutusTx builtin types. The previous error message "Cannot construct a value of type: BuiltinUnit" was cryptic and unhelpful for users encountering stage violations. This change introduces: - Template Haskell-based detection of builtin types from PlutusTx.Builtins.Internal - Module-aware type checking to avoid false positives - Comprehensive error messages explaining stage violations and how to fix them - Clear guidance on moving functions to top-level scope The improved error message explains the root cause (stage violation), provides actionable solutions (move to top-level, check variable scope), and maintains the original technical context for advanced debugging. This addresses the confusing error reported in plutus-private#1626 while maintaining full compatibility with existing functionality.
Document investigation into disabling mkSimplPass for better error messages. This investigation explored whether removing the GHC simplifier pass could improve error messages for stage violations. While disabling the pass does provide clearer errors, it breaks legitimate plugin functionality that depends on pre-inlining. The investigation concludes that targeted error message improvements (like the stage violation detection) are more practical than removing core functionality. These notes preserve the analysis for future reference and provide context for the chosen approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer adding special handling for providing better error message instead of disabling simplpass entirely. It seems writing a new simplifier(or rather, unfolder) would require some changes to GHC itself which would be undesirable.
- **Solutions**: | ||
- Move functions to top-level | ||
- Generate minimal unfoldings during desugaring (GHC enhancement needed) | ||
- Create lightweight unfolding pass (lighter than full simplifier) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this possible without making changes to GHC itself? From what I can see(which can be very wrong), we can only really change the plugin pass and the plugin pass doesn't have access to other stages of compilation.
This would be very easy if we have whole compilation pipeline under control.
OtherCon [] | ||
``` | ||
- **Root cause**: GHC #16615 - local bindings lack unfoldings without simplifier | ||
- **Pattern**: Functions marked `{-# INLINEABLE #-}` but defined after their use site |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's probably also the case for function marked inlineable but defined on the other module.
Closes https://github.com/IntersectMBO/plutus-private/issues/1626