Create subdirectory t/opbasic. Move 5 test files there. t/opbasic will hold files formerly held in t/op but which, unlike the vast majority of tests in the latter directory, are ineligible to use t/test.pl as a source of test functions. Affected files: arith.t cmp.t concat.t magic_phase.t qq.t This commit does nothing more than create the new subdirectory and move the files into it. For: RT #115838
Fix up \cX for 5.14 Throughout 5.13 there was temporary code to deprecate and forbid certain values of X following a \c in qq strings. This patch fixes this to the final 5.14 semantics. These are: 1) a utf8 non-ASCII character will croak. This is the same behavior as pre-5.13, but it gives a correct error message, rather than the malformed utf8 message previously. 2) \c{ and \cX where X is above ASCII will generate a deprecated message. The intent is to remove these capabilities in 5.16. The original agreement was to croak on above ASCII, but that does violate our stability policy, so I'm deprecating it instead. 3) A non-deprecated warning is generated for all other \cX; this is the same as throughout the 5.13 series. I did not have the tuits to use \c{} as I had planned in 5.14, but \N{} can be used instead.
Add \o{} escape This commit adds the new construct \o{} to express a character constant by its octal ordinal value, along with ancillary tests and documentation. A function to handle this is added to util.c, and it is called from the 3 parsing places it could occur. The function is a candidate for in-lining, though I doubt that it will ever be used frequently.
PATCH: [perl #75138] "\c`" -> " " Attached is a patch for some of this issue. I took Nicholas' advice, and if the result of \cX isn't a word character, the output message will precede it with a backslash, so the message in the example would be "\c`" more clearly written simply as "\ " at -e line 1. I think that message is true. I also added tests. There is a test that guarantees that we won't ship 5.14 with things as they are now in it. I added wording to the comments next to that test to be sure to verify with this email thread if we should remove the deprecation, and mentioned that in the explanatory wording in the pod. I support removing the deprecation, but for now I'm not touching that, to see what other issues may yet arise before 5.14.
Deal with "\c{", and its kin make regen is needed This patch forbids non-ascii following the "\c". It also terminates for "\c{" with a message to contact p5p if there is need for continuing its current definition. And if the character following the "\c" causes the result to not be a control character, a warning is issued. This is currently 'deprecated', which by default is turned on. This can easily be changed later. This patch is the initial patch. It does not do any fancy showing the context where the problematic construct occurs. This can be added later. It gathers the 3 occurrences of evaluating \c and puts them in one common routine.