<commit_before>=========================
Duktape 1.4 release notes
=========================

Release overview
================

This release provides small feature and performance improvements (see
RELEASES.rst for full details):

* Error handling improvements: better error messages for e.g. property
  operations and function calls; improved .fileName and .lineNumber
  attribution; directly writable .fileName, .lineNumber, and .stack
  properties.

* Stronger finalizer guarantees: a finalizer is called exactly once, unless
  the object is rescued in which case the finalizer is called exactly once
  per rescue cycle.

* Typed array constructors now accept a plain buffer with the same semantics
  as a Duktape.Buffer argument.

* Debugger improvements: Throw notify for error about to be thrown;
  option for automatically pausing on an uncaught error; Detaching notify;
  correct line number for "debugger" statement.

* Initial support for using C++ exceptions instead of setjmp()/longjmp() for
  internal long control transfers.  This change is minimally functional but
  still a work in progress.

* Support indentation and JX/JC formats in the JSON.stringify() fast path.
  The fast path should now, when enabled, cover a much larger set of use
  cases.

* Performance improvements affecting call handling, string handling, reference
  counting, hex and base64 encoding and decoding, JSON.stringify() fast and
  slow paths, and more.

* Combined duktape.c without #line directives into the dist package.

* Minor API improvements, bug fixes, and compilation warning fixes.

Upgrading from Duktape 1.3.x
============================

No action (other than recompiling) should be needed for most users to upgrade
from Duktape v1.3.x.  Note the following:

* Typed array constructors (like Uint16Array) now accept a plain buffer, with
  behavior matching a Duktape.Buffer argument: the argument is treated as an
  array of initialization values.

There are bug fixes and other minor behavioral changes which may affect some
applications, see ``RELEASES.rst`` for details.

Known issues
============

This release has the following known issues worth noting.

Ecmascript features
-------------------

* Non-compliant behavior for array indices near 2G or 4G elements.

* RegExp parser is strict and won't accept some real world RegExps which
  are technically not compliant with Ecmascript E5/E5.1 specification.

* Final mantissa bit rounding issues in the internal number-to-string
  conversion.

Portability and platforms
-------------------------

* On some older clang/llvm versions (e.g. Clang 3.3 on FreeBSD 10):
  when ``-m32`` is used, Duktape will end up using the 8-byte packed value
  representation but clang will generate incorrect code for union assignment
  (see ``misc/clang_aliasing.c``).  The issue can be detected by defining
  ``DUK_OPT_SELF_TESTS``.  A workaround is to avoid packed types in this
  case by defining ``DUK_OPT_NO_PACKED_TVAL``.

* On some older clang/llvm versions (e.g. Clang 3.3 on FreeBSD 10):
  compilation may produce a warning "generic selections are a C11-specific
  feature".  The warning should be harmless.

* On some older clang/llvm versions (e.g. Clang 3.3 on FreeBSD 10):
  harmless compilation warning for "duk_repl_isinf" being unused.

* On some GCC versions and compilation options you may get a warning
  "variable idx_func might be clobbered by longjmp or vfork [-Wclobbered]".
  This warning seems spurious and causes no known problems.

* GCC ``-O4`` may produce a warning "assuming signed overflow does not occur
  when assuming that (X - c) > X is always false" for some assertions.  This
  warning seems spurious and causes no known problems.

* GCC ``-pedantic`` without ``-std=c99`` causes the ``unsigned long long``
  type to be used by Duktape, and an associated warning about the type.
  This is harmless and most easily fixed by simply using ``-std=c99``.

* MSVC ``/Wp64`` produces harmless warnings when compiling for x86.  The
  warnings are caused by 64-bit incompatible code enabled for 32-bit targets;
  when you actually compile for a 64-bit target, those code paths are not
  used so the warnings are irrelevant.
<commit_msg>Document a few compiler warnings in release notes<commit_after>=========================
Duktape 1.4 release notes
=========================

Release overview
================

This release provides small feature and performance improvements (see
RELEASES.rst for full details):

* Error handling improvements: better error messages for e.g. property
  operations and function calls; improved .fileName and .lineNumber
  attribution; directly writable .fileName, .lineNumber, and .stack
  properties.

* Stronger finalizer guarantees: a finalizer is called exactly once, unless
  the object is rescued in which case the finalizer is called exactly once
  per rescue cycle.

* Typed array constructors now accept a plain buffer with the same semantics
  as a Duktape.Buffer argument.

* Debugger improvements: Throw notify for error about to be thrown;
  option for automatically pausing on an uncaught error; Detaching notify;
  correct line number for "debugger" statement.

* Initial support for using C++ exceptions instead of setjmp()/longjmp() for
  internal long control transfers.  This change is minimally functional but
  still a work in progress.

* Support indentation and JX/JC formats in the JSON.stringify() fast path.
  The fast path should now, when enabled, cover a much larger set of use
  cases.

* Performance improvements affecting call handling, string handling, reference
  counting, hex and base64 encoding and decoding, JSON.stringify() fast and
  slow paths, and more.

* Combined duktape.c without #line directives into the dist package.

* Minor API improvements, bug fixes, and compilation warning fixes.

Upgrading from Duktape 1.3.x
============================

No action (other than recompiling) should be needed for most users to upgrade
from Duktape v1.3.x.  Note the following:

* Typed array constructors (like Uint16Array) now accept a plain buffer, with
  behavior matching a Duktape.Buffer argument: the argument is treated as an
  array of initialization values.

There are bug fixes and other minor behavioral changes which may affect some
applications, see ``RELEASES.rst`` for details.

Known issues
============

This release has the following known issues worth noting.

Ecmascript features
-------------------

* Non-compliant behavior for array indices near 2G or 4G elements.

* RegExp parser is strict and won't accept some real world RegExps which
  are technically not compliant with Ecmascript E5/E5.1 specification.

* Final mantissa bit rounding issues in the internal number-to-string
  conversion.

Portability and platforms
-------------------------

* On some older clang/llvm versions (e.g. Clang 3.3 on FreeBSD 10):
  when ``-m32`` is used, Duktape will end up using the 8-byte packed value
  representation but clang will generate incorrect code for union assignment
  (see ``misc/clang_aliasing.c``).  The issue can be detected by defining
  ``DUK_OPT_SELF_TESTS``.  A workaround is to avoid packed types in this
  case by defining ``DUK_OPT_NO_PACKED_TVAL``.

* On some older clang/llvm versions (e.g. Clang 3.3 on FreeBSD 10):
  compilation may produce a warning "generic selections are a C11-specific
  feature".  The warning should be harmless.

* On some older clang/llvm versions (e.g. Clang 3.3 on FreeBSD 10):
  harmless compilation warning for "duk_repl_isinf" being unused.

* On some GCC versions and compilation options you may get a warning
  "variable idx_func might be clobbered by longjmp or vfork [-Wclobbered]".
  This warning seems spurious and causes no known problems.

* GCC ``-O4`` may produce a warning "assuming signed overflow does not occur
  when assuming that (X - c) > X is always false" for some assertions.  This
  warning seems spurious and causes no known problems.

* GCC ``-pedantic`` without ``-std=c99`` causes the ``unsigned long long``
  type to be used by Duktape, and an associated warning about the type.
  This is harmless and most easily fixed by simply using ``-std=c99``.

* MSVC ``/Wp64`` produces harmless warnings when compiling for x86.  The
  warnings are caused by 64-bit incompatible code enabled for 32-bit targets;
  when you actually compile for a 64-bit target, those code paths are not
  used so the warnings are irrelevant.

* MSVC ``/W4`` produces a harmless "conditional expression is constant"
  warning caused by a sizeof() comparison.

* MinGW produces harmless "visibility attribute not supported in this
  configuration" warnings when compiling from separate sources.

* An older mixed endian ARM toolchain (based on gcc-3.x) produces
  "xxx declared inline after being called" warnings.

{'fraction_non_alphanumeric': 0.08800543662928983, 'fraction_numerical': 0.010873258579680599, 'mean_word_length': 4.104046242774566, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 5, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6783983', 'n_tokens_mistral': 2416, 'n_tokens_neox': 2292, 'n_words': 1185}