Received a "error parsing text property list: missing ; in dictionary .." error
when opening an Xcode project saved encoded by the package.
Found the root cause to be a dictionary value containing an apostrophe, e.g. "JSON's".
Added this character to the bitmap containing quotable chars.

Fixes https://github.com/DHowett/go-plist/issues/65.

This commit also adds a benchmark for array unmarshaling. The difference
is staggering.

name                   old time/op    new time/op    delta
LargeArrayUnmarshal-4    23.4µs ± 2%     0.4µs ± 2%  -98.49%  (p=0.000 n=9+9)

name                   old alloc/op   new alloc/op   delta
LargeArrayUnmarshal-4     96.0B ± 0%    128.0B ± 0%  +33.33%  (p=0.000 n=10+10)

name                   old allocs/op  new allocs/op  delta
LargeArrayUnmarshal-4      3.00 ± 0%      4.00 ± 0%  +33.33%  (p=0.000 n=10+10)

Fixes https://github.com/DHowett/go-plist/issues/61

`go test -tags dump` will produce a directory containing all of plist's
test collateral.

GNUStep is very lax when it comes to parsing these. Closing quotes
aren't required (as pointed out by @Artoria2e5, and held up by empirical
validation), so all we need to do is strip a closing " even if we don't
detect an opening one.

This commit also fleshes out the invalid test cases for <* and reworks
some of the error-handling logic to make the errors clearer.  Type
checks have been lifted up to the head of the ext. val. parser and the
emptiness check has been tidied up a bit.

Co-authored-by: Mingye Wang <arthur200126@gmail.com>

Closes https://github.com/DHowett/go-plist/pull/51.

Mingye Wang authored Apr 19, 2020 and Dustin L. Howett committed Apr 19, 2020

GNUStep parses <[xxx]> as a base64-encoded NSData using
NSDataBase64DecodingIgnoreUnknownCharacters. It's fairly robust.

Co-authored-by: Dustin L. Howett <dustin@howett.net>

Coauthor notes:
I elevated the base64 string Map filter to a tabled character set and
added characterSet.Map() so that it could plug into strings.Map.

I've also gone ahead and added some failure case tests and a couple
extra tests for data that doesn't contain base64 characters.

References https://github.com/DHowett/go-plist/pull/51.

Squashed commit of the following (from Mingye)

commit 767da5373da65ab45885d84aa4cec6f3a8d65f0c
    Add test case for GNUstep base64 parsing
commit 748f6fc4e0afe16daa34534b7b02ca61676355b6
    Update text_parser.go: lowercase strings
commit 9d912f71f6e86967e2a110db789c8e43b152997c
    text_parser: add gnustep base64 parsing

Right now, it only runs for Go 1.13.

Although Apple's NSKeyedArchiver does not want to encode to things that are neither XML nor binary, GNUstep's version has no such limitation. On GNUstep they do what Apple does for XML for the text format too.

The proposed change consolidates the packing into one place.

Closes https://github.com/DHowett/go-plist/issues/53.

[skip ci]

This change introduces a difference in parsing from the reference
parser: the reference parser will always choose the _first_ value seen
associated with a key, while we will always choose the _last_.

This is not regarded as a compatibility issue, as there is no way to
provide a useful and re-serializable value in the presence of duplicate
keys.

Fixes https://github.com/DHowett/go-plist/issues/37.

This commit intoduces a mostly hand-rolled XML encoder inspired by
xml.Encoder. Since plist is a simple format that doesn't require
attributes, only has one data type with encodeable input and is
otherwise constrained, we don't need the full power of encoding/xml.

The encoder's speed, memory requirements and number of allocations are
all improved.

In addition, we can now emit self-closing tags for empty elements
(<key></key> -> <key/>).

Fixes https://github.com/DHowett/go-plist/issues/34.

name                    old time/op    new time/op    delta
XMLEncode-4               25.9µs ± 3%    14.9µs ± 1%   -42.66%
BigXMLGenerate-4          47.3ms ± 1%    23.7ms ± 1%   -49.91%
BigPrettyXMLGenerate-4    55.0ms ± 1%    30.0ms ± 1%   -45.42%
XMLGenerate-4             16.0µs ± 1%     5.8µs ± 1%   -63.81%

name                    old alloc/op   new alloc/op   delta
XMLEncode-4               8.71kB ± 0%    6.42kB ± 0%   -26.26%
BigXMLGenerate-4          2.62MB ± 0%    1.60MB ± 0%   -39.02%
BigPrettyXMLGenerate-4    2.62MB ± 0%    1.60MB ± 0%   -39.02%
XMLGenerate-4             5.83kB ± 0%    4.50kB ± 0%   -22.77%

name                    old allocs/op  new allocs/op  delta
XMLEncode-4                 88.0 ± 0%      63.0 ± 0%   -28.41%
BigXMLGenerate-4           86.7k ± 0%     72.6k ± 0%   -16.24%
BigPrettyXMLGenerate-4     86.7k ± 0%     72.6k ± 0%   -16.24%
XMLGenerate-4               54.0 ± 0%      31.0 ± 0%   -42.59%

A number of our hand-crafted binary plists had a sortVersion > 0x00,
and the "strange characters" text tests were hex-encoded for some
reason.

This fixes a long-standing bug where we would serialize unsigned 64-bit
integers >= 0x8000000000000000 in violation of the bplist00 spec. The
spec tells us that _all_ 64-bit values are signed. Those high-half
64-bit integers are meant to be stored as signed 128-bit integers with a
high half of 0x0000000000000000.

Tests have been updated to reflect this.

This commit builds on @gumpyoung's work in
https://github.com/DHowett/go-plist/pull/35.

Fixes https://github.com/DHowett/go-plist/issues/36.
Fixes https://gitlab.howett.net/DHowett/plist/issues/32.

Refs #22.

This commit moves all of the text tests into the common tests, the
invalid tests out of the common tests (since the test fixtures had to
have a lot of logic to handle "expected fail" tests, and it wasn't a
good idea anyway), and moves all formats into their own subtests.

TestData's members have been renamed to make them less naive.

This commit overhauls the text property list parser, reducing the cost
in time and memory and overall sanity required to parse text property
list documents.

Herein, support is also added for:
* UTF-16 text property lists (#26)
* Proper scanning of UTF-8 codepoints
* Encoding conversion (UTF-16{BE,LE) +- BOM -> UTF-8)
* Empty data values, <>
* Error messages that include line and column info (#25)
* Legacy strings file format (dictionary without { }) (#27)
* Shortcut strings file format (dictionaries without values) (#27)
* Short hex/unicode/octal escapes (\x2, \u33, \0)
* Empty documents parsing as empty dictionaries
* Detection of garbage after the end of a document

The character tables have been augmented with their own characterSet
type, which allows them to report on their own residence. All characters
outside the 0-255 range will be considered "not in set" for now.

In the benchmarks below, *Step(Parse|Decode) operate on a relatively
small synthetic property list that contains every property list type.
BigParse operates on a ~700kb binary property list created by converting
the iTunes software update catalog from XML to GNUStep or OpenStep.
Pretty benchmarks include whitespace.

benchmark                             old ns/op     new ns/op     delta
BenchmarkBigGNUStepParse-4            125008990     33544860      -73.17%
BenchmarkBigPrettyGNUStepParse-4      54869160      38049063      -30.65%
BenchmarkBigOpenStepParse-4           124436480     31491614      -74.69%
BenchmarkBigPrettyOpenStepParse-4     54080760      34542446      -36.13%
BenchmarkOpenStepParse-4              20177         13894         -31.14%
BenchmarkGNUStepParse-4               18742         15087         -19.50%

benchmark                             old allocs     new allocs     delta
BenchmarkBigGNUStepParse-4            2248154        120655         -94.63%
BenchmarkBigPrettyGNUStepParse-4      969515         120655         -87.56%
BenchmarkBigOpenStepParse-4           2251448        120655         -94.64%
BenchmarkBigPrettyOpenStepParse-4     969541         120655         -87.56%
BenchmarkOpenStepParse-4              234            44             -81.20%
BenchmarkGNUStepParse-4               186            47             -74.73%

benchmark                             old bytes     new bytes     delta
BenchmarkBigGNUStepParse-4            67633657      24006777      -64.50%
BenchmarkBigPrettyGNUStepParse-4      30100843      24006784      -20.25%
BenchmarkBigOpenStepParse-4           67657126      24023625      -64.49%
BenchmarkBigPrettyOpenStepParse-4     30101001      24023619      -20.19%
BenchmarkOpenStepParse-4              15376         10192         -33.71%
BenchmarkGNUStepParse-4               14992         10320         -31.16%

Fixes #25
Fixes #26
Fixes #27

Empty data plists, <>, are no longer invalid.