Upgrade GCC to 8.3.0, glibc to 1.17.0 and crosstool-ng to 1.24.0 for dist-armv7-linux
#62896 was caused by the usage of the GCC 5.2.0 toolchain, which was released back in 2015 and may have bugs affecting LLVM 9.
This PR upgrade GCC to 8.3.0 from 5.2.0, glibc from 1.16.0 to 1.17.0 and crosstool-ng to 1.24.0 only for dist-armv7-linux.
Fixes#62896
r? @alexcrichton
Prefer statx on linux if available
This PR make `metadata`-related functions try to invoke `statx` first on Linux if available,
making `std::fs::Metadata::created` work on Linux with `statx` supported.
It follows the discussion in #61386 , and will fix#59743
The implementation of this PR is simply converting `struct statx` into `struct stat64` with
extra fields for `btime` if `statx` succeeds, since other fields are not currently used.
---
I also did a separated benchmark for `fs::metadata`, `stat64`, `statx`, and `statx` with conversion to `stat64`.
It shows that `statx` with conversion is even more faster than pure `statx`.
I think it's due to `sizeof stat64 == 114` but `sizeof statx == 256`.
Anyway, the bare implementation of `statx` with conversion is only about 0.2% slower than the original impl (`stat64`-family).
With heap-allocation counted (~8.5% of total cost), the difference between `stat` and `statx` (with or without conversion) is just nothing.
Therefore, I think it is not urgent to use bare `struct statx` as underlying representation now.
There is no need to break `std::os::linux::fs::MetadataExt::as_raw_stat` (https://github.com/rust-lang/rust/pull/61386#issuecomment-538074018)
[Separated bare benchmarks](https://gist.github.com/oxalica/c4073ecb202c599fe41b7f15f86dc79c):
```
metadata_ok time: [529.41 ns 529.77 ns 530.19 ns]
metadata_err time: [538.71 ns 539.39 ns 540.35 ns]
stat64_ok time: [484.32 ns 484.53 ns 484.75 ns]
stat64_err time: [481.77 ns 482.00 ns 482.24 ns]
statx_ok time: [488.07 ns 488.35 ns 488.62 ns]
statx_err time: [487.74 ns 488.00 ns 488.27 ns]
statx_cvt_ok time: [485.05 ns 485.28 ns 485.53 ns]
statx_cvt_err time: [485.23 ns 485.45 ns 485.67 ns]
```
r? @alexcrichton
Rc: value -> allocation
See https://github.com/rust-lang/rust/issues/64484. This does not yet edit `Arc` as I first wanted to be sure we agree on the terminology the way it actually ends up. "value" as a term appears a lot in this file, and sometimes it refers to the value stored inside the `RcBox` while sometimes it refers to the `RcBox` itself. I tried to properly tease these apart but may have made some mistakes. The former should now always be called "inner value" and the latter "allocation".
One area where I was very unsure of which terminology is dropping: the `value` field of the `RcBox` will get dropped *earlier* than the `RcBox` itself if there are weak references. I decided that "dropping the value stored in the allocation" refers to dropping the value field, while "destroying the allocation" refers to actually freeing its backing memory.
r? @Centril
BTreeSet symmetric_difference & union optimized
No scalability changes, but:
- Grew the cmp_opt function (shared by symmetric_difference & union) into a MergeIter, with less memory overhead than the pairs of Peekable iterators now, speeding up ~20% on my machine (not so clear on Travis though, I actually switched it off there because it wasn't consistent about identical code). Mainly meant to improve readability by sharing code, though it does end up using more lines of code. Extending and reusing the MergeIter in btree_map might be better, but I'm not sure that's possible or desirable. This MergeIter probably pretends to be more generic than it is, yet doesn't declare to be an iterator because there's no need to, it's only there to help construct genuine iterators SymmetricDifference & Union.
- Compact the code of #64820 by moving if/else into match guards.
r? @bluss
Use structured suggestion for restricting bounds
When a trait bound is not met and restricting a type parameter would
make the restriction hold, use a structured suggestion pointing at an
appropriate place (type param in param list or `where` clause).
Account for opaque parameters where instead of suggesting extending
the `where` clause, we suggest appending the new restriction:
`fn foo(impl Trait + UnmetTrait)`. Fix#64565, fix#41817, fix#24354,
cc #26026, cc #37808, cc #24159, fix#37138, fix#24354, cc #20671.
Don't add `argc` and `argv` arguments to `main` on WASI.
Add a target setting to allow targets to specify whether the generated
`main` function should be passed `argc` and `argv` arguments. Set it
to false on wasm32-wasi, since WASI's `args::args()` calls into the
WASI APIs itself. This will allow the WASI toolchain to avoid linking
and running command-line argument initialization code when the arguments
aren't actually needed.
More symbol cleanups
Some minor improvements, mostly aimed at reducing unimportant differences between `Symbol` and `InternedString`. Helps a little with #60869.
r? @petrochenkov
Suppress ICE when validators disagree on `LiveDrop`s in presence of `&mut`
Resolves#65394.
This hack disables the validator mismatch ICE in cases where a `MutBorrow` error has been emitted by both validators, but they don't agree on the number of `LiveDrop` errors.
The new validator is more conservative about whether a value is moved from in the presence of mutable borrows. For example, the new validator will emit a `LiveDrop` error on the following code.
```rust
const _: Vec<i32> = {
let mut x = Vec::new();
let px = &mut x as *mut _;
let y = x;
unsafe { ptr::write(px, Vec::new()); }
y
};
```
This code is not UB AFAIK (it passes MIRI at least). The current validator does not emit a `LiveDrop` error for `x` upon exit from the initializer. `x` is not actually dropped, so I think this is correct? A proper fix for this would require a new `MaybeInitializedLocals` dataflow analysis or maybe a relaxation of the existing `IndirectlyMutableLocals` one.
r? @RalfJung
expand: Simplify expansion of derives
And make it more uniform with other macros.
This is done by merging placeholders for future derives' outputs into the derive container's output fragment early (addressing FIXMEs from https://github.com/rust-lang/rust/pull/63667).
Also, macros with names starting with `_` are no longer reported as unused, in accordance with the usual behavior of `unused` lints.
r? @matthewjasper or @mark-i-m
Rollup of 19 pull requests
Successful merges:
- #65016 (Always inline `mem::{size_of,align_of}` in debug builds)
- #65197 (Prepare `MutVisitor`s to handle interned projections)
- #65201 (Disable Go and OCaml bindings when building LLVM)
- #65334 (Add long error explanation for E0575)
- #65364 (Collect occurrences of empty blocks for mismatched braces diagnostic)
- #65455 (Avoid unnecessary `TokenTree` to `TokenStream` conversions)
- #65472 (Use a sharded dep node to dep node index map)
- #65480 (Speed up `LexicalResolve::expansion()`)
- #65493 (Add long error explanation for E0584)
- #65496 (properly document panics in div_euclid and rem_euclid)
- #65498 (Plugins deprecation: don’t suggest simply removing the attribute)
- #65508 (add option to ping llvm ice-breakers to triagebot)
- #65511 (save-analysis: Nest tables when processing impl block definitions)
- #65513 (reorder fmt docs for more clarity)
- #65532 (doc: make BitSet intro more short)
- #65535 (rustc: arena-allocate the slice in `ty::GenericsPredicate`, not the whole struct.)
- #65540 (show up some extra info when t!() fails)
- #65549 (Fix left/right shift typo in wrapping rotate docs)
- #65552 (Clarify diagnostics when using `~` as a unary op)
Failed merges:
- #65390 (Add long error explanation for E0576)
- #65434 (Add long error explanation for E0577)
- #65471 (Add long error explanation for E0578)
r? @ghost
