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

Uninitialized $_ and weird blowage (<a b c>[$_ xx 2] with 1) #1212

Closed
AlexDaniel opened this Issue Oct 25, 2017 · 2 comments

Comments

Projects
None yet
3 participants
@AlexDaniel
Member

AlexDaniel commented Oct 25, 2017

Let's say you want to achieve something like this:

say <a b c>[1 xx 2] # OUTPUT: «(b b)␤»

But using $_:

<a b c>[$_ xx 2] with 1
Use of Nil in string context
  in block  at -e line 1
Unable to call postcircumfix [ (Any) ] with a type object
Indexing requires a defined object
  in block <unit> at -e line 1

So not only $_ is unitialized, but it is also trying to stringify something? Weird.

@AlexDaniel AlexDaniel changed the title from Unititialized $_ and weird blowage (<a b c>[$_ xx 2] with 1) to Unitialized $_ and weird blowage (<a b c>[$_ xx 2] with 1) Oct 25, 2017

@AlexDaniel AlexDaniel changed the title from Unitialized $_ and weird blowage (<a b c>[$_ xx 2] with 1) to Uninitialized $_ and weird blowage (<a b c>[$_ xx 2] with 1) Oct 25, 2017

@TisonKun

This comment has been minimized.

Contributor

TisonKun commented Dec 15, 2017

FWIW

with 1 { say <1 2 3>[$_ xx 2] } # OUTPUT (2 2)

@zoffixznet zoffixznet self-assigned this Jan 23, 2018

zoffixznet added a commit that referenced this issue Jan 26, 2018

Fix block migration in thunk gen; skids++ for the assist
Phixes #1212
Fixes RT#130575: https://rt.perl.org/Ticket/Display.html?id=130575
Fixes RT#132337: https://rt.perl.org/Ticket/Display.html?id=132337
Fixes RT#131548: https://rt.perl.org/Ticket/Display.html?id=131548
Fixes RT#132211: https://rt.perl.org/Ticket/Display.html?id=132211
Fixes RT#126569: https://rt.perl.org/Ticket/Display.html?id=126569
Fixes RT#128054: https://rt.perl.org/Ticket/Display.html?id=128054
Fixes RT#126413: https://rt.perl.org/Ticket/Display.html?id=126413
Fixes RT#126984: https://rt.perl.org/Ticket/Display.html?id=126984
Fixes RT#132172: https://rt.perl.org/Ticket/Display.html?id=132172

All of the bugs in the tickets are caused by mis-scoped blocks
resulting in p6capturelex failing to set outers correctly, and thus
resulting in issues with updating of values in lexicals. The
mis-scoping occurs during migration of blocks when we're generating
thunks with causes being one or several of:

1) WhateverCode QAST missing `statement_id` annotation, resuling in
  migration predicate being false, and thus not migrating the QAST
2) andthen/notandthen/orelse thunks being nested into one another
  instead of being alongside each other, as these operators aren't
  chained and instead are called with all the thunks present in
  a single operator call
3) Missing truthy `in_stmt_mod` annotation on first argument of the
  andthen/notandthen/orelse calls. These aren't thunked for the
  operator call, but they can have thunks due to other constructs
  present in them, so they need the annotation for proper migration
4) Present truthy `in_stmt_mod` annotation on non-first arguments
  of the andthen/notandthen/orelse calls. This occurs when we
  have one of these operators as a conditional in one of the
  statement modifiers. Mis-migration occurs because despite being
  in non-first argument of the operator, the migrator still thinks
  we're directly in statement modifier code
5) We can have sub-staments within our thunks that get an increased
  statement ID, but the migrator only migrates blocks with the same
  statement ID as the thunk itself, missing substatements

Fix all the issues with:

- Add `statement_id` annotation to WhateverCode QAST
- Annotate andthen/notandthen/orelse thunks and make migrator skip
  them, which avoids unwanted nesting
- Specially annotate first argument of andthen/notandthen/orelse
  ops with `in_stmt_mod_andnotelse` annotation to ensure we
  migrate any thunks inside appropriately. We can't just re-use
  `in_stmt_mod` annotation here, since we need to address cause
  (4) above as well, so we have two separate annotations and a
  somewhat convoluted migrator condition that covers all the cases
- Look for statement IDs equal to *or greater* than our thunk.
  This ensures all substatement inside our thunk get migrated right,
  as only blocks that have greater ID than us at this point in time
  would all be from within our thunk.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment