start adding MEMDEBUG2 mode for flisp, which will allocate every object
explicitly with malloc.
get flisp MEMDEBUG2 working reasonably well
Merge branch 'master' of github.com:JuliaLang/julia into jb/flisp-memdebug2
Merge branch 'master' of github.com:JuliaLang/julia into jb/flisp-memdebug2
add GC to MEMDEBUG2 mode
Merge branch 'master' of github.com:JuliaLang/julia into jb/flisp-memdebug2
allow semicolon at end of import and using statements. fixes #4130
Merge branch 'jb/flisp-memdebug2' of github.com:JuliaLang/julia into jb/flisp-memdebug2
Merge branch 'master' of github.com:JuliaLang/julia into jb/flisp-memdebug2
Fix doc typo
Merge pull request #4889 from magistere/fixes

Fix typo in complex number docs
Merge branch 'master' of github.com:JuliaLang/julia
start adding '.. doctest::' directives to manual
some doc/manual fixes found by doctest
Fix a memory error in Stat. Thanks ASAN
parseint: code cleanup.
Base.checked_{add,sub,mul}: checked versions of +, - and *.

We've had the intrinsics for checked arithmetic for a rather long time,
we just haven't used it anywhere. This defines checked +, - and * the
same way that we define +, - and *. I had a previous version in which
these worked like +, - and * with promotion and all, but realized that
wasn't actually desirable. When you're doing checked arithmetic, you
want strictly same-type arguments and you want to make sure that they
don't result in an overflowed result for that exact integer type.

Note that there may be an LLVM bug for checked 8-bit multiply: the
overflow flag ends up set no matter what two values you multiply. I
worked around this by defining 8-bit checked multiply without LLVM's
intrinsic, but it would be good to look into this further.
parseint: basic implementation of overflow-detection [fixes #4874]
parseint: allow automatic base detection via 0[box] prefixes.
parseint: speed up parsing by avoiding checks in main paring loop.

The trick here is that we know that we can't possibly overflow until
we reach a fairly large value for each type. In particular, we can't
possibly overflow while n <= div(typemax(T)-base+1,base). After that
we can have one or two decoding cycles left, which actually have to
be checked for overflow. The "naïve" version was 2x+ slower than the
unchecked version, while this version is only around 15% slower.