LLVM gets overwhelmed when presented with a zeroinitializer for a large
type. In unoptimised builds, it generates a long sequence of stores to
memory. In optmised builds, it manages to generate a standard memset of
zero values, but takes a long time doing so.
Call out to the `llvm.memset` function to zero out the memory instead.
This is a [breaking-change] since `std::dynamic_lib::dl` is now
private.
When `LoadLibraryW()` fails, original code called `errno()` to get error
code. However, there was local allocation of `Vec` before
`LoadLibraryW()`, and it drops before `errno()`, and the drop
(deallocation) changed `errno`! Therefore `dynamic_lib::open()` thought
it always succeeded.
This commit fixes the issue.
This commit also sets Windows error mode during `LoadLibrary()` to
prevent "dll load failed" dialog.
* add `Token::AndAnd` (double borrow)
* add `Token::DotDot` (range notation)
* remove `Token::Pound` and `Token::At`
This fixes a syntax error when parsing `fn f() -> RangeTo<i32> { return ..1; }`.
Also, remove `fn_expr_lookahead`.
It's from the `fn~` days and seems to no longer be necessary.
This fixes the issues mentioned in https://github.com/rust-lang/rust/pull/21236, as well as the one https://github.com/rust-lang/rust/issues/21230 where `CFG_BOOTSTRAP_KEY` was being set to simply 'N'. It changes the build such that `RUSTC_BOOTSTRAP_KEY` is only exported on -beta and -stable, so that the behavior of the -dev, -nightly, and snapshot compilers is the same everywhere.
Haven't run it completely through 'make check' yet, but the I have verified that the aforementioned issues are fixed.
r? @alexcrichton cc @eddyb
Please review carefully. Contains unsafe and is my first commit to Rust.
Uses ptr::copy_nonoverlapping_memory. Attempts to handle zero-size types correctly.
Increases the delay of the search box to 500ms after key up. I tried
adding a three character minimum for setting the delay, but didn't find
it very useful.
Should close#20095
File cannot be written, for example, if directory does not exist.
Before this commit:
```
% rustc -o nonexistent/program program.rs
error: could not write output: No such file or directory
```
With this commit:
```
% rustc -o nonexistent/program program.rs
error: could not write output to nonexistent/program.0.o: No such file or directory
```
This is useful when full rust command is not displayed, or when last
error is preceded by thousands of warnings.
rust.nanorc provides syntax highlighting for Rust. An attempt has been made to
make the syntax highlighting look good on both dark and light terminals.
Issue #21286.
Brings the rustdoc man page in sync with the options specified in
src/librustdoc/lib.rs. The text was taken verbatim, but I tweaked the
order to be (what I think is) somewhat logical.
The script is intended as a tool for doing every sort of verifications
amenable to Rustdoc's HTML output. For example, link checkers would go
to this script. It already parses HTML into a document tree form (with
a slight caveat), so future tests can make use of it.
As an example, relevant `rustdoc-*` run-make tests have been updated
to use `htmldocck.py` and got their `verify.sh` removed. In the future
they may go to a dedicated directory with htmldocck running by default.
The detailed explanation of test scripts is provided as a docstring of
htmldocck.
cc #19723
"Idiomatic code should not use extra whitespace in the middle of a line to provide alignment."
http://aturon.github.io/style/whitespace.html
I realize the linked page still needs an RFC, but the docs should be written in accordance with the guidelines nevertheless.
In accordance with [collections reform part 2][rfc] this macro has been moved to
an external [bitflags crate][crate] which is [available though
crates.io][cratesio]. Inside the standard distribution the macro has been moved
to a crate called `rustc_bitflags` for current users to continue using.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0509-collections-reform-part-2.md
[crate]: https://github.com/rust-lang/bitflags
[cratesio]: http://crates.io/crates/bitflags
The major user of `bitflags!` in terms of a public-facing possibly-stable API
today is the `FilePermissions` structure inside of `std::io`. This user,
however, will likely no longer use `bitflags!` after I/O reform has landed. To
prevent breaking APIs today, this structure remains as-is.
Current users of the `bitflags!` macro should add this to their `Cargo.toml`:
bitflags = "0.1"
and this to their crate root:
#[macro_use] extern crate bitflags;
Due to the removal of a public macro, this is a:
[breaking-change]
