There're a lot of changes and fixes in 1.8 regarding IP stack,
incompatible with previous Zephyr versions, so supporting them
doesn't make sense.
This is the last commit which should build with Zephyr 1.7.
Tests for an issue with line continuation failing in paste mode due to the
lexer only checking for \n in the "following" character position, before
next_char() has had a chance to convert \r and \r\n to \n.
This ensures that mpy-cross is automatically built (and is up-to-date) for
ports that use frozen bytecode. It also makes sure that .mpy files are
re-built if mpy-cross is changed.
VfsFat no longer has the listdir() method. Rather, if listdir()
functionality is needed then one should use uos.listdir() which will call
VfsFat.ilistdir().
Now consistently uses the EOL processing ("\r" and "\r\n" convert to "\n")
and EOF processing (ensure "\n" before EOF) provided by next_char().
In particular the lexer can now correctly handle input that starts with CR.
Prior to this patch only 'q' and 'Q' type arrays could store big-int
values. With this patch any big int that is stored to an array is handled
by the big-int implementation, regardless of the typecode of the array.
This allows arrays to work with all type sizes on all architectures.
This will lead to crash like:
FATAL: uncaught NLR 80a5420
On x86_32, the minimum heap size is smaller, but not 2 times, so just
use value which works for x86_64.
This patch allows mounting of VFS objects right at the root directory, eg
os.mount(vfs, '/'). It still allows VFS's to be mounted at a path within
the root, eg os.mount(vfs, '/flash'), and such mount points will override
any paths within a VFS that is mounted at the root.
Versions prior to v14.0 have a bug in parsing item functions when used
within a condition: https://github.com/Microsoft/msbuild/issues/368.
Since commit [db9c2e3] this results in an error when building MicroPython
with for example VS2013.
Fix this by creating an intermediate property.
fmode.c should only be included for builds targetting 'pure' windows, i.e.
msvc or mingw builds but not when using msys or cygwin's gcc (see #2298).
Just checking if the OS is windows and UNAME doesn't have msys stil leaves
the gate open for builds with cygwin's gcc since UNAME there is e.g.
CYGWIN_NT-6.1-WOW.
Fix this by checking for 'mingw' explicitly in the compiler version; both
gcc and clang have the -dumpmachine flag so the check should be ok for
all platforms.
