This works by adding this directory to GCC include search path before mingw system headers directories,
so we can intercept their inclusions and add missing definitions without having to modify files in mingw/include.
In #8185 cross-crate condition handlers were fixed by ensuring that globals
didn't start appearing in different crates with different addressed. An
unfortunate side effect of that pull request is that constants weren't inlined
across crates (uint::bits is unknown to everything but libstd).
This commit fixes this inlining by using the `available_eternally` linkage
provided by LLVM. It partially reverts #8185, and then adds support for this
linkage type. The main caveat is that not all statics could be inlined into
other crates. Before this patch, all statics were considered "inlineable items",
but an unfortunate side effect of how we deal with `&static` and `&[static]`
means that these two cases cannot be inlined across crates. The translation of
constants was modified to propogate this condition of whether a constant
should be considered inlineable into other crates.
Closes#9036
std: remove unneeded field from RequestData struct
std: rt::uv::file - map us_fs_stat & start refactoring calls into FsRequest
std: stubbing out stat calls from the top-down into uvio
std: us_fs_* operations are now by-val self methods on FsRequest
std: post-rebase cleanup
std: add uv_fs_mkdir|rmdir + tests & minor test cleanup in rt::uv::file
WORKING: fleshing out FileStat and FileInfo + tests
std: reverting test files..
refactoring back and cleanup...
Fix uint overflow bugs in std::{at_vec, vec, str}
Closes#8742
Fix issue #8742, which summarized is: unsafe code in vec and str did assume
that a reservation for `X + Y` elements always succeeded, and didn't overflow.
Introduce the method `Vec::reserve_additional(n)` to make it easy to check for
overflow in `Vec::push` and `Vec::push_all`.
In std::str, simplify and remove a lot of the unsafe code and use `push_str`
instead. With improvements to `.push_str` and the new function
`vec::bytes::push_bytes`, it looks like this change has either no or positive
impact on performance.
I believe there are many places still where `v.reserve(A + B)` still can overflow.
This by itself is not an issue unless followed by (unsafe) code that steps aside
boundary checks.
This constrains the span to the appropriate argument, so you know which
one caused the problem. Instead of
foo.rs:2:4: 2:21 error: Too large integer literal in bytes!
foo.rs:2 bytes!(1, 256, 2)
^~~~~~~~~~~~~~~~~
it will say
foo.rs:2:14 2:17 error: Too large integer literal in bytes!
foo.rs:2 bytes!(1, 256, 2)
^~~
Now rustdoc_ng will be built as both a binary and a library (using the same
rules as all the other binaries that rust has). Furthermore, this will also
start building rustdoc_ng unit tests (and running them).
also removes the unused `FastInvoke` wrapper, as it's never actually
going to be used (we can't *partially* switch to `fastcc`, and this is
only used for Rust functions)
Closes#9221.
"rustpkg test" isn't implemented yet, so it shouldn't be in the manpage. Referring interested parties to the manual is probably
the right thing for now; eventually, these documents should merge.
This module was removed a while ago, but the tasks tutorial wasn't
updated, and the old docs page for pipes was never deleted so the link
confusingly still worked!
The `noalias` attributes were being set only on function definitions,
not on all declarations. This is harmless for `noalias`, but prevented
some optimization opportunities and is *not* harmless for other
attributes like `sret` with ABI implications.
Closes#9104
`push_bytes` is implemented with `ptr::copy_memory` here since this
function is intended to be used to implement `.push_str()` for str, so
we want to avoid the overhead.
Issue #8742
Add the method `.reserve_additional(n: uint)`: Check for overflow in
self.len() + n, and reserve that many elements (rounded up to next power
of two). Does nothing if self.len() + n < self.capacity() already.
It now uses `{"type": VariantName, "fields": [...]}`, which, according to
@Seldaek, since all enums will have the same "shape" rather than being a weird
ad-hoc array, will optimize better in javascript JITs. It also looks prettier,
and makes more sense.
