Ticket #1207 (closed deprecation: fixed)

Opened 5 years ago

Last modified 4 years ago

Non-existent lexical throws exception

Reported by: pmichaud Owned by: Paul C. Anagnostopoulos
Priority: normal Milestone: 2.5
Component: core Version: 1.7.0
Severity: medium Keywords:
Cc: Language:
Patch status: applied Platform:

Description

If we use the find_lex opcode on a symbol that hasn't been defined in any outer scope, it generates an exception with

Lexical '$foo' not found

For consistency with the other "symbol lookup" ops such as get_global and hash lookups, the find_lex opcode should probably return PMCNULL if the given symbol is not found.

Or, the find_lex opcode could throw an exception only when PARROT_ERRORS_GLOBALS_FLAG (or a similar flag) is set. But the default behavior should probably match the behavior of the other symbol lookup ops.

Thanks!

Pm

This was originally tracked at  http://rt.perl.org/rt3/Ticket/Display.html?id=47894

Attachments

PCA-patch-006.patch Download (2.5 KB) - added by Paul C. Anagnostopoulos 4 years ago.

Change History

Changed 5 years ago by dukeleto

  • owner set to allison

Changed 5 years ago by dukeleto

I just verified that this behavior still occurs on trunk r42259

parrot_shell 0> $P0 = find_lex '$foo'
.
Error: child exited with value 1
Time: 0.0275583 wallclock secs 
Output:
Lexical '$foo' not found
current instr.: 'main' pc 0 (/var/folders/B3/B3qJ-edQFWKuziEWXxoYbU+++TI/-Tmp-/t_K9QpKJe7:3)

Changed 5 years ago by bacek

  • type changed from RFC to deprecation
  • milestone set to 2.4

Added this ticket into deprecation.

Changed 5 years ago by coke

  • reporter changed from dukeleto to pmichaud

(updating reporter to reflect original requestor from RT; dukeleto++ for copying this over.)

Changed 5 years ago by gerd

  • milestone changed from 2.4 to 2.5

Changed 4 years ago by Paul C. Anagnostopoulos

  • owner changed from allison to Paul C. Anagnostopoulos
  • status changed from new to assigned

PARROT_ERRORS_GLOBALS_FLAG is not used anywhere in the system. So it seems that find_lex should be made consistent with the other opcodes.

Should we deprecate the flag? At least we should document that it is unused.

Changed 4 years ago by Paul C. Anagnostopoulos

We're going to document the flag as unused and add to DEPRECATED.pod. This per conversation with bacek.

Changed 4 years ago by Paul C. Anagnostopoulos

Changed 4 years ago by Paul C. Anagnostopoulos

  • patch set to new

PARROT_ERRORS_GLOBALS_FLAG has been deprecated in a previous patch. The find-lex operation now returns PMCNULL if the name is undefined, rather than throwing an error. The deprecation notice has been removed; it was eligible in 2.4.

The test for this in lexicals.t has been updated.

Changed 4 years ago by Paul C. Anagnostopoulos

This patch is waiting for an upgrade path description. I'll add it when I return from vacation.

Changed 4 years ago by Paul C. Anagnostopoulos

I have edited the ParrotDeprecations and ParrotDeprecationFor2.9 pages to describe the upgrade path. I think we can commit this patch now.

Changed 4 years ago by cotto

After applying the patch and running bootstrap-ops, I get the following new test failures. Unfortunately I don't have time to dig into them right now.

Test Summary Report


t/src/extend.t (Wstat: 256 Tests: 18 Failed: 1)

Failed test: 13 Non-zero exit status: 1

t/dynoplibs/debug.t (Wstat: 256 Tests: 8 Failed: 1)

Failed test: 4 Non-zero exit status: 1

Files=355, Tests=12422, 209 wallclock secs ( 3.84 usr 1.03 sys + 149.42 cusr 21.34 csys = 175.63 CPU) Result: FAIL make: *** [test_core] Error 1

Changed 4 years ago by Paul C. Anagnostopoulos

My fault for not seeing those test failures. I will deal with them when I return from vacation.

Changed 4 years ago by Paul C. Anagnostopoulos

The test failures were corrected and the patch committed in r48721.

Changed 4 years ago by Paul C. Anagnostopoulos

  • status changed from assigned to closed
  • resolution set to fixed
  • patch changed from new to applied
Note: See TracTickets for help on using tickets.