Check all files in `src/test` for `borrowck_graphviz_postflow`
This attribute causes DOT files to be generated in the top-level directory. It is intended to be used only temporarily and should never appear on master. This also tells git to ignore DOT files in the root or the `mir_dump` directory, which `-Z dump-mir` uses by default.
This will prevent #65071 from occurring again. It needs to be merged after #65629, otherwise `tidy` will start failing.
r? @Mark-Simulacrum
Rollup of 8 pull requests
Successful merges:
- #65314 (rustdoc: forward -Z options to rustc)
- #65592 (clarify const_prop ICE protection comment)
- #65603 (Avoid ICE when include! is used by stdin crate)
- #65614 (Improve error message for APIT with explicit generic arguments)
- #65629 (Remove `borrowck_graphviz_postflow` from test)
- #65633 (Remove leading :: from paths in doc examples)
- #65638 (Rename the default argument 'def' to 'default')
- #65639 (Fix parameter name in documentation)
Failed merges:
r? @ghost
Remove leading :: from paths in doc examples
Noted some pre-2018 path syntax in the doc examples, for example:
https://doc.rust-lang.org/std/process/fn.exit.html
```rust
fn main() {
::std::process::exit(match run_app() {
Ok(_) => 0,
...
```
Couldn't find an existing issue on this (then again, "::" makes for an annoying thing to search for) so if there is already something fixing this and/or there's a reason to not fix it, just close this PR.
(Also fixed indentation in the `process::exit()` docs)
Remove `borrowck_graphviz_postflow` from test
Resolves#65071 (again).
Sorry. I've added a commit hook to prevent this from happening in the future.
r? @petrochenkov
Avoid ICE when include! is used by stdin crate
This should hopefully also eliminate the ICE when using `include_bytes!`, `include_str!` and `#[doc(include = "...")]` with a stdio input.
I couldn't see a clear way to write a compile-fail test using compiletest with a stdio input, so I haven't written any tests for this change.
Fixes#63900
clarify const_prop ICE protection comment
This is based on discussion at https://github.com/rust-lang/rust/pull/64890/files#r334555787.
That said, why are function arguments the only unsized locals that could remain uninitialized? Couldn't we also fail to initialize some local but still go on with const_prop, and then hit a line that takes a reference to that? Cc @wesleywiser @oli-obk ; I don't know enough about const-prop to understand why this can happen only for function arguments.
~~The PR includes https://github.com/rust-lang/rust/pull/64890; the only new commit is 05e4e6ba0d5.~~
rustdoc: forward -Z options to rustc
Currently rustdoc does not forward `-Z` options to rustc when building
test executables. This makes impossible to use rustdoc to run test
samples when crate under test is instrumented with one of sanitizers
`-Zsanitizer=...`, since the final linking step will not include
sanitizer runtime library.
Forward `-Z` options to rustc to solve the issue.
Helps with #43031.
Remove unreachable unit tuple compare binop codegen
Closes#63906Fixes#63551
This is based on #63906 by @luigishat, who had trouble with rebasing his PR.
Avoid unnecessary arena allocations in `expand_pattern()`.
`expand_pattern()` has two callsites. One of them needs arena
allocation, but the other does not.
This commit moves the arena allocation out of the function. This avoids
the allocation of many 4 KiB page arena chunks that only hold a single
small allocation. It reduces the number of bytes allocated by up to 2%
for various benchmarks, albeit without only a very small improvement in
runtime.
This attribute causes DOT files to be generated in the top-level
directory. It is intended to be used only temporarily and should never
appear on master.
This will prevent #65071 from occurring again.
Remove unneeded `ref` from docs
Will reduce confusion like in https://users.rust-lang.org/t/help-understanding-the-ref-t-syntax/33779 since match ergonomics means you (almost) never have to say `ref` anymore!
There might be more like this, but I don't have a checkout on my computer right this second and I'm on slow wifi and GitHub search isn't powerful enough and that's my story.
add test for calling non-const fn
The good news is that there is an error. But I expected to see [this error](9578272d68/src/librustc_mir/const_eval.rs (L346)) surface. @oli-obk any idea why that message is not shown anywhere?
r? @oli-obk
Avoid realloc in `CString::new`
If `&[u8]` or `&str` is given, `CString::new` allocates a new `Vec` with the exact capacity, and then `CString::from_vec_unchecked` calls `.reserve_exact(1)` for nul byte. This PR avoids the reallocation by allocationg `len + 1` bytes beforehand. In microbenchmark this PR speeds up `CString::new(&[u8])` by 30%.
Inline `ptr::null(_mut)` even in debug builds
I think we should treat `ptr::null(_mut)` as a constant. As It may help reduce code size
in debug build.
See godbolt link: https://godbolt.org/z/b9YMtD
Avoid injecting sanitizer runtimes into staticlibs (#64629).
This fixes the remaining issue in `creader.rs` and also fixes the expected test failure. I have explicitly turned the `$(CC)` call into a negative check with the `!` to ensure that this command is really failing (if it is not, then either the runtime is attached to the lib or the lib has not been instrumented and both would be an error).
I've also borrowed `program.rs` and the additional `rustc` invocation from @tmiasko 's PR since he pointed out that using `-fsanitize=address` with `$(CC)` for linking could fail if the sanitizer runtimes on the system are incompatible.
With this toolchain I was able to compile Firefox locally without any linker errors. I am still seeing races with Rust in TSan but I assume that is because I did not build with `-Z build-std`.
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
