~sircmpwn/hare-dev

This thread contains a patchset. You're looking at the original emails, but you may wish to use the patch review UI. Review patch
3 2

[PATCH hare-specification] Update to match harec flexible promotion

Details
Message ID
<20250111192018.4415-3-rkl@rosiesworkshop.net>
Sender timestamp
1736605138
DKIM signature
pass
Download raw message
Patch: +9 -5
Signed-off-by: Rosie K Languet <rkl@rosiesworkshop.net>
---
This updates the flexible literal promotion algorithm to match current harec 
behavior in promoting signed flexible literals to unsigned integer types.

 language/expressions.tex | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/language/expressions.tex b/language/expressions.tex
index 0d47f53..dcbc110 100644
--- a/language/expressions.tex
+++ b/language/expressions.tex
@@ -2809,11 +2809,15 @@ which shall be the result of the promotion.

\specsubitem
If one operand is a flexible integer and the other is a non-flexible type, the
promotion shall succeed only if the non-flexible type is an integer type, and
the minimum and maximum value fields of the flexible integer are representable
within the non-flexible integer type without any data loss. If the promotion
succeeds, the flexible integer shall be lowered to the non-flexible integer
type, which shall be the result of the promotion.
promotion shall succeed only if the non-flexible type is an integer type and if
the maximum value field of the flexible integer is representable within the
integer type without any data loss. If the integer type is signed, the promotion
shall succeed only if the minimum value field is also so representable. If the
integer type is unsigned and the flexible integer is negative, it shall be first
promoted to the corresponding (equal-width) signed integer type, and then
bit-cast to the unsigned type. If the promotion succeeds, the flexible integer
shall be lowered to the non-flexible integer type, which shall be the result of
the promotion.

\specsubitem
If one operand is a flexible rune, the promotion shall succeed if the other type
-- 
2.47.1
Details
Message ID
<453b443803dfc56ab9e6185d5a92f9d082cf6dd2@rosiesworkshop.net>
In-Reply-To
<20250111192018.4415-3-rkl@rosiesworkshop.net> (view parent)
Sender timestamp
1736635845
DKIM signature
pass
Download raw message
I think Assignability rules also doesn't describe the current situation vis-à-vis
negative values and unsigned types... Am I missing something?

January 11, 2025 at 2:18 PM, "Rosie K Languet" <rkl@rosiesworkshop.net> wrote:
> 
> Signed-off-by: Rosie K Languet <rkl@rosiesworkshop.net>
> 
> ---
> 
> This updates the flexible literal promotion algorithm to match current harec 
> 
> behavior in promoting signed flexible literals to unsigned integer types.
> 
>  language/expressions.tex | 14 +++++++++-----
> 
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/language/expressions.tex b/language/expressions.tex
> 
> index 0d47f53..dcbc110 100644
> 
> --- a/language/expressions.tex
> 
> +++ b/language/expressions.tex
> 
> @@ -2809,11 +2809,15 @@ which shall be the result of the promotion.
> 
>  
> 
>  \specsubitem
> 
>  If one operand is a flexible integer and the other is a non-flexible type, the
> 
> -promotion shall succeed only if the non-flexible type is an integer type, and
> 
> -the minimum and maximum value fields of the flexible integer are representable
> 
> -within the non-flexible integer type without any data loss. If the promotion
> 
> -succeeds, the flexible integer shall be lowered to the non-flexible integer
> 
> -type, which shall be the result of the promotion.
> 
> +promotion shall succeed only if the non-flexible type is an integer type and if
> 
> +the maximum value field of the flexible integer is representable within the
> 
> +integer type without any data loss. If the integer type is signed, the promotion
> 
> +shall succeed only if the minimum value field is also so representable. If the
> 
> +integer type is unsigned and the flexible integer is negative, it shall be first
> 
> +promoted to the corresponding (equal-width) signed integer type, and then
> 
> +bit-cast to the unsigned type. If the promotion succeeds, the flexible integer
> 
> +shall be lowered to the non-flexible integer type, which shall be the result of
> 
> +the promotion.
> 
>  
> 
>  \specsubitem
> 
>  If one operand is a flexible rune, the promotion shall succeed if the other type
> 
> -- 
> 
> 2.47.1
>
Details
Message ID
<D6ZO2QFMO4ZB.1TCR285GCMYR3@turminal.net>
In-Reply-To
<20250111192018.4415-3-rkl@rosiesworkshop.net> (view parent)
Sender timestamp
1736645219
DKIM signature
pass
Download raw message
This patch is malformed.

> diff --git a/language/expressions.tex b/language/expressions.tex
> index 0d47f53..dcbc110 100644
> --- a/language/expressions.tex
> +++ b/language/expressions.tex
> @@ -2809,11 +2809,15 @@ which shall be the result of the promotion.
>  
>  \specsubitem
>  If one operand is a flexible integer and the other is a non-flexible type, the
> -promotion shall succeed only if the non-flexible type is an integer type, and
> -the minimum and maximum value fields of the flexible integer are representable
> -within the non-flexible integer type without any data loss. If the promotion
> -succeeds, the flexible integer shall be lowered to the non-flexible integer
> -type, which shall be the result of 
> the promotion.

 I suspect a - is missing in front of this line.
Details
Message ID
<60df3fae92bdce7686ede04a8941bcec3b4b5d29@rosiesworkshop.net>
In-Reply-To
<D6ZO2QFMO4ZB.1TCR285GCMYR3@turminal.net> (view parent)
Sender timestamp
1736649903
DKIM signature
pass
Download raw message
> This patch is malformed.
Applies fine for me. *shrug* I'll resend. :)
Reply to thread Export thread (mbox)