* Re-run rustdoc tests if rustdoc or htmldocck.py was updated.
* Put stamp files in the correct subdirectories to avoid clashes when
the file names match but the subdirectory doesn't.
The previous code would parse the TestProps, and then parse them
again with a revision set, adding some elements (like aux_builds)
a second time to the existing TestProps.
Prefer libproc_macro APIs to libsyntax ones in the quasi-quoter.
The shift to using `proc_macro`'s own APIs in `proc_macro::quote`, both in the implementation of the quasi-quoter and the Rust code it generates to build `TokenStream`s at runtime, greatly reduces the dependency on `libsyntax`, with the generated runtime code being completely free of it.
This is a prerequirement for introducing more abstraction/indirection between `proc_macro` and compiler implementation details (mainly those from `libsyntax`), which I want to attempt.
cc @alexcrichton @jseyfried @nrc
Right now ThinLTO is generating bad dwarf which is tracked by #45511, but this
is causing issues on OSX (#45768) where `dsymutil` is segfaulting and failing to
produce output.
Closes#45768
... rather than being gated by -Z saturating-float-casts.
There are several reasons for this:
1. Const eval already implements this behavior.
2. Unlike with float->int casts, this behavior is uncontroversially the
right behavior and it is not as performance critical. Thus there is no
particular need to make the bug fix for u128->f32 casts opt-in.
3. Having two orthogonal features under one flag is silly, and never
should have happened in the first place.
4. Benchmarking float->int casts with the -Z flag should not pick up
performance changes due to the u128->f32 casts (assuming there are any).
Fixes#41799
Allow a trailling comma in assert_eq/ne macro
From Rust beginners IRC:
<???> It sure does annoy me that assert_eq!() does not accept a trailing comma after the last argument.
<???> ???: File an issue against https://github.com/rust-lang/rust and CC @rust-lang/libs
Figured that might as well submit it. Will become insta-stable after merging (danger zone).
cc @rust-lang/libs
get() example should use get() not get_mut()
I'm really new to Rust, this is the first thing I've ever actually pushed to github in a rust project, so please double check that it's correct. I noticed that the in-doc example for the string's get() function was referring to get_mut(). Looks like a copy/paste issue.
```rust
fn main() {
let v = String::from("🗻∈🌏");
assert_eq!(Some("🗻"), v.get(0..4));
// indices not on UTF-8 sequence boundaries
assert!(v.get(1..).is_none());
assert!(v.get(..8).is_none());
// out of bounds
assert!(v.get(..42).is_none());
}
```
results in:
```
jhford-work:~/rust/redish $ cat get-example.rs
fn main() {
let v = String::from("🗻∈🌏");
assert_eq!(Some("🗻"), v.get(0..4));
// indices not on UTF-8 sequence boundaries
assert!(v.get(1..).is_none());
assert!(v.get(..8).is_none());
// out of bounds
assert!(v.get(..42).is_none());
}
jhford-work:~/rust/redish $ rustc get-example.rs
jhford-work:~/rust/redish $ ./get-example ; echo $?
0
```
I did not build an entire rust toolchain as I'm not totally sure how to do that.
Fix help for duplicated names: `extern crate (...) as (...)`
On the case of duplicated names caused by an `extern crate` statement
with a rename, don't include the inline suggestion, instead using a span
label with only the text to avoid incorrect rust code output.
Fix#45829.
Miscellaneous changes for CI, Docker and compiletest.
This PR contains 7 independent commits that improves interaction with CI, Docker and compiletest.
1. a4e5c91cb8 — Forces a newline every 100 dots when testing in quiet mode. Prevents spurious timeouts when abusing the CI to test Android jobs.
2. 1b5aaf22e8 — Use vault.centos.org for dist-powerpc64le-linux, see #45744.
3. 33400fbbcd — Modify `src/ci/docker/run.sh` so that the docker images can be run from Docker Toolbox for Windows on Windows 7. I haven't checked the behavior of the newer Docker for Windows on Windows 10. Also, "can run" does not mean all the test can pass successfully (the UDP tests failed last time I checked)
4. d517668a08 — Don't emit a real warning the linker segfault, which affects UI tests like https://github.com/rust-lang/rust/pull/45489#issuecomment-340134944. Log it instead.
5. 51e2247948 — During run-pass, trim the output if stdout/stderr exceeds 416 KB (top 160 KB + bottom 256 KB). This is an attempt to avoid spurious failures like https://github.com/rust-lang/rust/pull/45384#issuecomment-341755788
6. 9cfdabaf3c — Force `gem update --system` before deploy. This is an attempt to prevent spurious error #44159.
7. eee10cc482 — Tries to print the crash log on macOS on failure. This is an attempt to debug #45230.
Add error for `...` in expressions
Follow-up to https://github.com/rust-lang/rust/pull/44709
Tracking issue: https://github.com/rust-lang/rust/issues/28237
* Using `...` in expressions was a warning, now it's an error
* The error message suggests using `..` or `..=` instead, and explains the difference
* Updated remaining occurrences of `...` to `..=`
r? petrochenkov
Normalizing method signatures can unify inference variables, which can
cause receiver unification to fail. Unify the receivers first to avoid
that.
Fixes#36701.
Fixes#45801.
Fixes#45855.
Working towards a libc-less (wasm32) libstd
This is a series of commits I was able to extract from prepare to comiple libstd on a "bare libc-less" target, notably wasm32. The actual wasm32 bits I intend to send in a PR later, this is just some internal refactorings required for libstd to work with a `libc` that's empty and a few other assorted refactorings.
No functional change should be included in this PR for users of libstd, this is intended to just be internal refactorings.
This commit removes usage of the `libc` crate in "portable" modules like
those at the top level and `sys_common`. Instead common types like `*mut
u8` or `u32` are used instead of `*mut c_void` or `c_int` as well as
switching to platform-specific functions like `sys::strlen` instead of
`libc::strlen`.
Refactor internal suggestion API
~~The only functional change is that whitespace, which is suggested to be added, also gets `^^^^` under it. An example is shown in the tests (the only test that changed).~~
Continuation of #41876
r? @nagisa
the changes are probably best viewed [without whitespace](https://github.com/rust-lang/rust/pull/45741/files?w=1)
This commit moves the `f32::cmath` and `f64::cmath` modules into the
`sys` module. Note that these are not publicly exported modules, simply
implementation details. These modules are already platform-specific with
shims on MSVC and this is mostly just a reflection of that reality. This
should also help cut down on `#[cfg]` traffic if platforms are brought on
which don't directly support these functions.
This commit removes the reexport of `EBADF_ERR` as a constant from
libstd's portability facade, instead opting for a platform-specific
function that specifically queries an `io::Error`. Not all platforms may
have a constant for this, so it makes the intent a little more clear
that a code need not be supplied, just an answer to a query.
This commit removes the `rand` crate from the standard library facade as
well as the `__rand` module in the standard library. Neither of these
were used in any meaningful way in the standard library itself. The only
need for randomness in libstd is to initialize the thread-local keys of
a `HashMap`, and that unconditionally used `OsRng` defined in the
standard library anyway.
The cruft of the `rand` crate and the extra `rand` support in the
standard library makes libstd slightly more difficult to port to new
platforms, namely WebAssembly which doesn't have any randomness at all
(without interfacing with JS). The purpose of this commit is to clarify
and streamline randomness in libstd, focusing on how it's only required
in one location, hashmap seeds.
Note that the `rand` crate out of tree has almost always been a drop-in
replacement for the `rand` crate in-tree, so any usage (accidental or
purposeful) of the crate in-tree should switch to the `rand` crate on
crates.io. This then also has the further benefit of avoiding
duplication (mostly) between the two crates!
