- Don't print the newline on its own to avoid the possibility of
printing it out of order due to `stdout` locking.
- Modify wording of `concat!()` with non-literals to not mislead into
believing that only `&str` literals are accepted.
- Add test for `concat!()` with non-literals.
sync::Once use release-acquire access modes
Nothing here makes a case distinction like "this happened before OR after that". All we need is to get happens-before edges whenever we see that the state/signal has been changed. Release-acquire is good enough for that.
RFC 2008 non-exhaustive enums/structs: Rustdoc
Part of #44109. Not sure how those who maintain rustdoc primarily would prefer this addition look or where it should be placed, happy to make any changes required.
r? @QuietMisdreavus (not sure if this is the right person, just guessing)
overhaul exit codes for rustc and rustdoc
This commit changes the exit status of rustc to 1 in the presence of
compilation errors. In the event of an unexpected panic (ICE) the
standard panic error exit status of 101 remains.
A run-make test is added to ensure that the exit code does not regress,
and compiletest is updated to check for an exit status of 1 or 101,
depending on the mode and suite.
This is a breaking change for custom drivers.
Note that while changes were made to the rustdoc binary, there is no
intended behavior change. rustdoc errors (i.e., failed lints) will still
report 101. While this could *also* hide potential ICEs, I will leave
that work to a future PR.
Fixes#51971.
Rollup of 13 pull requests
Successful merges:
- #51628 (use checked write in `LineWriter` example)
- #52116 (Handle array manually in str case conversion methods)
- #52218 (Amend option.take examples)
- #52418 (Do not use desugared ident when suggesting adding a type)
- #52439 (Revert some changes from #51917 to fix custom libdir)
- #52455 (Fix doc comment: use `?` instead of `.unwrap()`)
- #52458 (rustc: Fix a suggestion for the `proc_macro` feature)
- #52464 (Allow clippy to be installed with make install)
- #52472 (rustc: Enable `use_extern_macros` in 2018 edition)
- #52477 (Clarify short-circuiting behvaior of Iterator::zip.)
- #52480 (Cleanup #24958)
- #52487 (Don't build twice the sanitizers on Linux)
- #52510 (rustdoc: remove FIXME about macro redirects)
Failed merges:
r? @ghost
update compiler-builtins for openbsd
import rust-lang-nursery/compiler-builtins/pull/249 in rust main line.
it solves an issue on OpenBSD with building of `librsvg`.
rustdoc: remove FIXME about macro redirects
Based on the discussion in #35705, the rustdoc team has determined that macro redirects are here to stay.
Closes#35705
use checked write in `LineWriter` example
The example was wrong because it didn't check the return value of
`write()`, and it didn't flush the buffer before comparing the contents
of the file.
Fixes#51621.
Don't build twice the sanitizers on Linux
This commit is an attempted fix at #50887. It was noticed that on that issue
we're building both x86_64 and i386 versions of libraries, but we only actually
need the x86_64 versions! This hopes that the build race condition exhibited
in #50887 is connected to building both architectures and/or building a lot of
libraries, so this should help us build precisely what we need and no more.
This commit is an attempted fix at #50887. It was noticed that on that issue
we're building both x86_64 and i386 versions of libraries, but we only actually
need the x86_64 versions! This hopes that the build race condition exhibited
in #50887 is connected to building both architectures and/or building a lot of
libraries, so this should help us build precisely what we need and no more.
rustc: Enable `use_extern_macros` in 2018 edition
This was previously enabled via `proc_macro`, but since `proc_macro` is now
stable this is no longer the case. Explicitly include it in the 2018 edition
here.
Allow clippy to be installed with make install
After #51122 clippy is available as a component but doesn't install when building from source.
This PR allows to install clippy with extended tools.
rustc: Fix a suggestion for the `proc_macro` feature
This feature is stable, we shouldn't suggest it any more! Instead suggest the
real feature, `use_extern_macros`.
Amend option.take examples
It wasn't abundantly clear to me what `.take` returned. Perhaps this is a slightly frivolous change, but I think it's an improvement. =)
Apologies if I'm not following proper procedures.
Handle array manually in str case conversion methods
Avoiding the overhead incurred from `String.extend(char.to_lowercase())` showed a notable performance improvement when I benchmarked it.
I tested on these strings:
```rust
ALL_LOWER: "loremipsumdolorsitametduosensibusmnesarchumabcdefgh"
ALL_UPPER: "LOREMIPSUMDOLORSITAMETDUOSENSIBUSMNESARCHUMABCDEFGH"
REALISTIC_UPPER: "LOREM IPSUM DOLOR SIT AMET, DUO SENSIBUS MNESARCHUM"
SIGMAS: "ΣΣΣΣΣ ΣΣΣΣΣ ΣΣΣΣΣ ΣΣΣ ΣΣΣΣ, ΣΣΣ ΣΣΣΣΣΣΣΣ ΣΣΣΣΣΣΣΣΣΣ"
WORD_UPPER: "Lorem Ipsum Dolor Sit Amet, Duo Sensibus Mnesarchum"
```
the performance improvements of `to_lowercase()` were
```
running 10 tests
test tests::all_lower ... bench: 1,752 ns/iter (+/- 49)
test tests::all_lower_new ... bench: 1,266 ns/iter (+/- 15) -28%
test tests::all_upper ... bench: 1,832 ns/iter (+/- 39)
test tests::all_upper_new ... bench: 1,337 ns/iter (+/- 18) -27%
test tests::realistic_upper ... bench: 1,993 ns/iter (+/- 14)
test tests::realistic_upper_new ... bench: 1,445 ns/iter (+/- 22) -27%
test tests::sigmas ... bench: 1,342 ns/iter (+/- 39)
test tests::sigmas_new ... bench: 1,226 ns/iter (+/- 16) -9%
test tests::word_upper ... bench: 1,899 ns/iter (+/- 12)
test tests::word_upper_new ... bench: 1,381 ns/iter (+/- 26) -27%
```
and of `to_uppercase()`
```
running 10 tests
test tests::all_lower ... bench: 1,813 ns/iter (+/- 20)
test tests::all_lower_new ... bench: 1,321 ns/iter (+/- 16) -27%
test tests::all_upper ... bench: 1,629 ns/iter (+/- 22)
test tests::all_upper_new ... bench: 1,241 ns/iter (+/- 9) -24%
test tests::realistic_upper ... bench: 1,670 ns/iter (+/- 24)
test tests::realistic_upper_new ... bench: 1,241 ns/iter (+/- 17) -26%
test tests::sigmas ... bench: 2,053 ns/iter (+/- 20)
test tests::sigmas_new ... bench: 1,753 ns/iter (+/- 23) -15%
test tests::word_upper ... bench: 1,873 ns/iter (+/- 30)
test tests::word_upper_new ... bench: 1,412 ns/iter (+/- 25) -25%
```
I gave up on the more advanced method from #52061 as it wasn't always a clear improvement and would help in even less cases if this PR was merged.
Enable default inlining in platform intrinsics
Since [#28273](https://github.com/rust-lang/rust/issues/28273) has been fixed for quite some time, it might be a good idea to return to default inlining in platform intrinsics.
