Ensure configure creates doc/guides directory
Fix configure makefile and tests
Remove old guides dir and configure option, convert testing to guide
Remove ignored files
Fix submodule issue
prepend dir in makefile so that bor knows how to build the docs
S to uppercase
If the main closure failed, then the `exit_code` variable would still be `None`,
and the `unwrap()` was failing (triggering a process abort). This changes the
`unwrap()` to an `unwrap_or()` in order to prevent process abort and detect when
the native task failed.
This is causing maybe_get_doc to fail when called at the top level of
the metadata and doesn't appear to be needed anymore.
A try build succeeded so this should be okay.
- don't check for an hardcoded copyright claim year, check the 2 surrounding strings instead
- logic: if either the `//` or `#`-style copyright patterns are found, don't invalidate
- cleanup hardcoded content and streamline the few files with different line breaks
r? @brson
This removes the feature where newtype structs can be dereferenced like pointers, and likewise where certain enums can be dereferenced (which I imagine nobody realized still existed). This ad-hoc behavior is to be replaced by a more general overloadable dereference trait in the future.
I've been nursing this patch for two months and think it's about rebased up to master.
@nikomatsakis this makes a bunch of your type checking code noticeably uglier.
If there is a lot of data in thread-local storage some implementations
of pthreads (e.g. glibc) fail if you don't request a stack large enough
-- by adjusting for the minimum size we guarantee that our stacks are
always large enough. Issue #6233.
LLVM appears to generate calls to exp10 on ARM and bionic does not define it.
This makes code that links to libextra (which I guess does some exponentiation on the stat module) link correctly.
In a multi-host build the mklldeps.py tool is getting called before
all the llvm-configs are built. I am not actually sure the cause. I
had convinced myself that DEF_LLVM_RULES needed to be called before
the llvmdeps.rs rule, but now looking at it again I can't see why.
Here's the error: http://buildbot.rust-lang.org/builders/dist2-linux/builds/11/steps/compile/logs/stdio
r? @alexcrichton
Previously this was an `rtabort!`, indicating a runtime bug. Promote
this to a more intentional abort and print a (slightly) more
informative error message.
Can't test this sense our test suite can't handle an abort exit.
I consider this to close#910, and that we should open another issue about implementing less conservative semantics here.
After writing some benchmarks for ebml::reader::vuint_at() I noticed that LLVM doesn't seem to inline the from_be32 function even though it only does a call to the bswap32 intrinsic in the x86_64 case. Marking the functions with #[inline(always)] fixes that and seems to me a reasonable thing to do. I got the following measurements in my vuint_at() benchmarks:
- Before
test ebml::bench::vuint_at_A_aligned ... bench: 1075 ns/iter (+/- 58)
test ebml::bench::vuint_at_A_unaligned ... bench: 1073 ns/iter (+/- 5)
test ebml::bench::vuint_at_D_aligned ... bench: 1150 ns/iter (+/- 5)
test ebml::bench::vuint_at_D_unaligned ... bench: 1151 ns/iter (+/- 6)
- Inline from_be32
test ebml::bench::vuint_at_A_aligned ... bench: 769 ns/iter (+/- 9)
test ebml::bench::vuint_at_A_unaligned ... bench: 795 ns/iter (+/- 6)
test ebml::bench::vuint_at_D_aligned ... bench: 758 ns/iter (+/- 8)
test ebml::bench::vuint_at_D_unaligned ... bench: 759 ns/iter (+/- 8)
- Using vuint_at_slow()
test ebml::bench::vuint_at_A_aligned ... bench: 646 ns/iter (+/- 7)
test ebml::bench::vuint_at_A_unaligned ... bench: 645 ns/iter (+/- 3)
test ebml::bench::vuint_at_D_aligned ... bench: 907 ns/iter (+/- 4)
test ebml::bench::vuint_at_D_unaligned ... bench: 1085 ns/iter (+/- 16)
As expected inlining from_be32() gave a considerable speedup.
I also tried how the "slow" version fared against the optimized version and noticed that it's
actually a bit faster for small A class integers (using only two bytes) but slower for big D class integers (using four bytes)
If there is a lot of data in thread-local storage some implementations
of pthreads (e.g. glibc) fail if you don't request a stack large enough
-- by adjusting for the minimum size we guarantee that our stacks are
always large enough. Issue #6233.
In a multi-host build the mklldeps.py tool is getting called before
all the llvm-configs are built. I am not actually sure the cause. I
had convinced myself that DEF_LLVM_RULES needed to be called before
the llvmdeps.rs rule, but now looking at it again I can't see why.
Alan Andrade