Incorrect warning: nonexistent __x variable is shadowed #476

New Issue

2023-08-02T21:04:36+09:00

zxq9 commented

2023-08-02 21:04:36 +09:00

(Migrated from gitlab.com)

Created by: brainiacfive

I get a compiler warning

The definition of `__x` shadows an older definition at (builtin location).

I am not using __x in my source. Tried to eliminate the String include from it, only Option left, but it throws the same warning; so it would not be include conflict. No other includes.

Looks like a compiler issue to me. Will provided a minimal source example later. Maybe you have an idea already from this stub notice.

*Created by: brainiacfive* I get a compiler warning The definition of `__x` shadows an older definition at (builtin location). I am not using __x in my source. Tried to eliminate the String include from it, only Option left, but it throws the same warning; so it would not be include conflict. No other includes. Looks like a compiler issue to me. Will provided a minimal source example later. Maybe you have an idea already from this stub notice.

zxq9 commented

2023-08-02 21:05:14 +09:00

(Migrated from gitlab.com)

Created by: brainiacfive

(builtin location)

is verbatim the warning, not a placeholder I inserted.

*Created by: brainiacfive* (builtin location) is verbatim the warning, not a placeholder I inserted.

zxq9 commented

2023-08-02 21:15:13 +09:00

(Migrated from gitlab.com)

Created by: marc0olo

@brainiacfive this is happening in a (currently) private contract, right?

if you can't provide a minimal example right now you could maybe invite @ghallak and/or @radrow to the repo to check with the contract where the compiler currently produces this warning

*Created by: marc0olo* @brainiacfive this is happening in a (currently) private contract, right? if you can't provide a minimal example right now you could maybe invite @ghallak and/or @radrow to the repo to check with the contract where the compiler currently produces this warning

zxq9 commented

2023-08-03 17:47:19 +09:00

(Migrated from gitlab.com)

Created by: hanssv

I think the compiler uses the variable __x when it desugars some of the Map-syntax - could be something 'interesting' going on there.

*Created by: hanssv* I think the compiler uses the variable `__x` when it desugars some of the Map-syntax - could be something 'interesting' going on there.

zxq9 commented

2023-08-03 18:15:47 +09:00

(Migrated from gitlab.com)

Created by: hanssv

contract C =
  record r1 = { f : bool, g : bool }
  record state = { m : map(int, r1) }

  let default1 = { f = false, g = false }

  entrypoint init() = {m = {}}

  stateful entrypoint f(the1 : int) =
    put(state{ m[the1 = default1].f = true })

is a small example capturing the same problem - the compiled code is correct in this case, but that might be luck (cc @radrow and @ghallak )

*Created by: hanssv* ``` contract C = record r1 = { f : bool, g : bool } record state = { m : map(int, r1) } let default1 = { f = false, g = false } entrypoint init() = {m = {}} stateful entrypoint f(the1 : int) = put(state{ m[the1 = default1].f = true }) ``` is a small example capturing the same problem - the compiled code is correct in this case, but that might be luck (cc @radrow and @ghallak )

zxq9 commented

2023-08-04 01:20:15 +09:00

(Migrated from gitlab.com)

Created by: brainiacfive

Much appreciated. I saw more warnings using __x meanwhile; in folds.

Do you know which variable in your example is the first use of __x that would get shadowed by which other variable that is the second use? I'd be checking for patterns of that in the contract source to make sure it is harmless.

*Created by: brainiacfive* Much appreciated. I saw more warnings using `__x` meanwhile; in folds. Do you know which variable in your example is the first use of `__x` that would get shadowed by which other variable that is the second use? I'd be checking for patterns of that in the contract source to make sure it is harmless.

zxq9 commented

2023-08-04 01:37:39 +09:00

(Migrated from gitlab.com)

Created by: radrow

It's a bug caused by running code analysis on desugared code. Nothing to worry about. We'll take a look and fix it soon.

*Created by: radrow* It's a bug caused by running code analysis on desugared code. Nothing to worry about. We'll take a look and fix it soon.

zxq9 commented

2023-08-04 01:44:37 +09:00

(Migrated from gitlab.com)

Created by: radrow

If you are worried though, or if it may impact something serious, you can use aesophia_cli with pp_asm to check if the function is compiled correctly. The assembler should be fairly readable.

*Created by: radrow* If you are worried though, or if it may impact something serious, you can use `aesophia_cli` with `pp_asm` to check if the function is compiled correctly. The assembler should be fairly readable.

zxq9 commented

2023-08-04 01:45:32 +09:00

(Migrated from gitlab.com)

Created by: brainiacfive

Thank you, will do!

*Created by: brainiacfive* Thank you, will do!

zxq9 commented

2023-08-04 13:33:05 +09:00

(Migrated from gitlab.com)

Created by: brainiacfive

The asm code is fascinating but not something to crack on the fly. Can you @radrow @hanssv share what sugar is causing the use of __x so I can change the code to avoid it? I assume a nesting of scopes is a prerequisite for the effect to happen. So I should be able to eliminate the select places this could be happening. I'd rather have this evened out, thanks!

*Created by: brainiacfive* The asm code is fascinating but not something to crack on the fly. Can you @radrow @hanssv share what sugar is causing the use of `__x` so I can change the code to avoid it? I assume a nesting of scopes is a prerequisite for the effect to happen. So I should be able to eliminate the select places this could be happening. I'd rather have this evened out, thanks!

zxq9 commented

2023-08-04 19:13:45 +09:00

(Migrated from gitlab.com)

Created by: brainiacfive

Tried with replacing

put(state{ used[account = unused].abstraction = true })

with

let u = used[account = unused]{ abstraction  = true }
put(state{  used[account] = u })

On @hanssv recommendation, but so far no luck.

*Created by: brainiacfive* Tried with replacing put(state{ used[account = unused].abstraction = true }) with let u = used[account = unused]{ abstraction = true } put(state{ used[account] = u }) On @hanssv recommendation, but so far no luck.

zxq9 commented

2023-08-04 19:30:47 +09:00

(Migrated from gitlab.com)

Created by: hanssv

You need to change all five of them, and indeed it does workaround the problem.

*Created by: hanssv* You need to change all five of them, and indeed it does workaround the problem.

zxq9 commented

2023-08-04 20:12:17 +09:00

(Migrated from gitlab.com)

Created by: hanssv

I think the concrete issue has been worked around - as for the compiler, I think using __x everywhere might be a bit too simplistic 🙈 - and it should be fixed eventually.

*Created by: hanssv* I think the concrete issue has been worked around - as for the compiler, I think using `__x` everywhere might be a bit too simplistic 🙈 - and it should be fixed eventually.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QPQ-AG/sophia#476