Since rustc-ap-* v659 we now need to set CFG_RELEASE for
rustc-ap-rustc_attr for `#[cfg(version(...))]` to work.
Co-authored-by: Eric Huss <ehuss@users.noreply.github.com>
Pass more `Copy` types by value.
There are a lot of locations where we pass `&T where T: Copy` by reference,
which should both be slightly less performant and less readable IMO.
This PR currently consists of three fairly self contained commits:
- passes `ty::Predicate` by value and stops depending on `AsRef<ty::Predicate>`.
- changes `<&List<_>>::into_iter` to iterate over the elements by value. This would break `List`s
of non copy types. But as the only list constructor requires `T` to be copy anyways, I think
the improved readability is worth this potential future restriction.
- passes `mir::PlaceElem` by value. Mir currently has quite a few copy types which are passed by reference, e.g. `Local`. As I don't have a lot of experience working with MIR, I mostly did this to get some feedback from people who use MIR more frequently
- tries to reuse `ty::Predicate` in case it did not change in some places, which should hopefully
fix the regression caused by #72055
r? @nikomatsakis for the first commit, which continues the work of #72055 and makes adding `PredicateKind::ForAll` slightly more pleasant. Feel free to reassign though
perf: Revert accidental inclusion of a part of #69218
This was accidentally included in #69464 after a rebase and given
how much `inflate` and `keccak` stresses the obligation forest seems
like a likely culprit to the regression in those benchmarks.
(It is necessary in #69218 as obligation forest needs to accurately
track the root variables or unifications will get lost)
Extend useless conversion
This PR extends `useless_conversion` lint with `TryFrom` and `TryInto`
fixes: #5344
changelog: Extend `useless_conversion` with `TryFrom` and `TryInto`
Add remark regarding DoubleEndedIterator
While reviewing 14293bd18f (diff-2c16d2ada06ad2fd1fc754679646d471), I realized that a `DoubleEndedIterator` may yield different elements depending on whether it is traversed forwards or backwards. (Not only the *order*, but possibly also the yielded values.)
I found this remarkable, but could not find anything in the current docs, so I thought it may be worth mentioning this explicitly.
Unfortunately, I could not test these changes locally (`rustdoc` complains about `unresolved import`). Sorry if this causes headache.
If I should change something, please let me know. If it seems too trivial, feel free to just close this PR.
Remove font-display settings
Since for the moment, the result isn't as expected since #72092 when not using docs locally, let's revert them.
r? @Dylan-DPC
Add test for old compiler ICE when using `Borrow`
The original issue was caused by implementing `Borrow` on a local type and using the tokio-reactor crate which had this impl: https://github.com/tokio-rs/tokio/blob/tokio-0.1.4/tokio-reactor/src/poll_evented.rs#L547-L577
This causes an ICE on Rust 1.27.0:
```console
$ RUSTUP_TOOLCHAIN=1.27.0 rustc src/test/ui/issues/issue-50687-ice-on-borrow.rs
error: internal compiler error: librustc/traits/structural_impls.rs:180: impossible case reached
thread 'main' panicked at 'Box<Any>', librustc_errors/lib.rs:554:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: aborting due to previous error
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.27.0 (3eda71b00 2018-06-19) running on x86_64-apple-darwin
```
Closes#50687
Resolve UB in Arc/Weak interaction (2)
Use raw pointers to avoid making any assertions about the data field.
Follow up from #72479, see that PR for more detail on the motivation.
@RalfJung I was able to avoid a lot of the changes to `Weak`, by making a helper type (`WeakInner`) - because of auto-deref and because the fields have the same name, the rest of the code continues to compile.
Register redundant_field_names and non_expressive_names as early passes
Similar names was moved to a pre-expansion pass to solve #2927, so I'm avoiding linting on code from expansion, which makes the dogfood (mostly, see below) pass.
I had to change new_without_default though, and although I understand why it was not triggering before, TBH I don't see why the binding inside the nested `if_chain` is being linted now. Any ideas? (it seems legit though as the code can be changed by the user)
changelog: Register redundant_field_names and non_expressive_names as early passes
Fixes#5356Fixes#5521
Update books
## reference
7 commits in 892b928b565e35d25b6f9c47faee03b94bc41489..becdca9477c9eafa96a4eea5156fe7a2730d9dd2
2020-05-11 11:13:51 -0700 to 2020-05-21 21:08:02 +0100
- Update tuple index token. (rust-lang-nursery/reference#814)
- Fixes minor errors (rust-lang-nursery/reference#818)
- Update that macros can be deprecated. (rust-lang-nursery/reference#813)
- work on char/str descriptions (rust-lang-nursery/reference#809)
- cfg_attr needs a valid predicate (rust-lang-nursery/reference#812)
- Account for removal of UB in float-to-int casts (rust-lang-nursery/reference#810)
- Fix stray plus signs. (rust-lang-nursery/reference#811)
## book
6 commits in 6247be15a7f7509559f7981ee2209b9e0cc121df..e8a4714a9d8a6136a59b8e63544e149683876e36
2020-05-03 10:55:09 -0500 to 2020-05-25 10:29:27 -0500
- code is 1024 now, not 512
- Clean up install a bit
- We don't need build.sh anymore
- Fix CI status in README
- Port to github actions (rust-lang/book#2337)
- operating system -> allocator
## rust-by-example
5 commits in ab072b14393cbd9e8a1d1d75879bf51e27217bbb..7aa82129aa23e7e181efbeb8da03a2a897ef6afc
2020-05-09 08:46:39 -0300 to 2020-05-25 14:54:26 -0300
- Person of age 0 is alive (rust-lang/rust-by-example#1348)
- Gramatical fix in std/rc.md (rust-lang/rust-by-example#1347)
- Capture example should use String (rust-lang/rust-by-example#1331)
- Fix empty bound examples (rust-lang/rust-by-example#1343)
- Fix an inline comment in macros/repeat.md (rust-lang/rust-by-example#1344)
## edition-guide
1 commits in 49270740c7a4bff2763e6bc730b191d45b7d5167..0a8ab5046829733eb03df0738c4fafaa9b36b348
2020-05-11 08:50:29 -0500 to 2020-05-18 08:34:23 -0500
- Changes for Rust 1.32 & setup for edition-next (rust-lang-nursery/edition-guide#213)
## embedded-book
3 commits in 366c50a03bed928589771eba8a6f18e0c0c01d23..5555a97f04ad7974ac6fb8fb47c267c4274adf4a
2020-05-07 09:04:42 +0000 to 2020-05-25 18:00:51 +0000
- Remove reference to const-fn feature of cortex-m. Closesrust-embedded/book#242. (rust-embedded/book#243)
- Spelling: Appplication -> Application (rust-embedded/book#241)
- QEMU debugging updates (rust-embedded/book#239)
Warn about unused crate deps
Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`.
Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`.
If a crate has multiple aliases (eg using `foo = { package = "bar" }` in `Cargo.toml`), then it will warn about each unused alias.
This does not consider crate added by some other means than `--extern`, including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this).
Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates, causing spurious warnings. As a result, this lint is "allow" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.
JS cleanup
The goal here is just to improve the source code a bit. I recommend to review one commit at a time, otherwise it might not make much sense. :)
The biggest commit is the second one: to prevent to have "global" variables declared in `main.js` (and thus prevent name conflict or overwriting), I moved such code into anonymous functions.
r? @kinnison
cc @rust-lang/rustdoc
add a lint against references to packed fields
Creating a reference to an insufficiently aligned packed field is UB and should be disallowed, both inside and outside of `unsafe` blocks. However, currently there is no stable alternative (https://github.com/rust-lang/rust/issues/64490) so all we do right now is have a future incompatibility warning when doing this outside `unsafe` (https://github.com/rust-lang/rust/issues/46043).
This adds an allow-by-default lint. @retep998 suggested this can help early adopters avoid issues. It also means we can then do a crater run where this is deny-by-default as suggested by @joshtriplett.
I guess the main thing to bikeshed is the lint name. I am not particularly happy with "packed_references" as it sounds like the packed field has reference type. I chose this because it is similar to "safe_packed_borrows". What about "reference_to_packed" or "unaligned_reference" or so?
Export ZERO_AR_DATE for macos linker invocations
This commit attempts to improve reproducibility of builds on macOS by
exporting the `ZERO_AR_DATE=1` environment variable for all invocations
of the linker. While it looks like this env var is targeted at just the
`ar` command (which does actually read this) it appears that recent-ish
versions of the linker *also* read this environment variable. This
env var forces the linker to set a deterministic zero value for the
mtime in the N_OSO field of the object file.
Currently it's believe that older versions of the linker will simply
ignore this env var, while newer versions will read it and produce a
deterministic output for compilations with debuginfo.
Closes#47086Closes#66568
Make empty_line_after_outer_attr an early lint
Fixes#5567
Unfortunately I couldn't find a way to reproduce the issue without syn/quote. Considering that most real-world macros use syn and/or quote, I think it's okay to pull them in anyway.
changelog: Fix false positive in [`empty_line_after_outer_attr`]
This commit attempts to improve reproducibility of builds on macOS by
exporting the `ZERO_AR_DATE=1` environment variable for all invocations
of the linker. While it looks like this env var is targeted at just the
`ar` command (which does actually read this) it appears that recent-ish
versions of the linker *also* read this environment variable. This
env var forces the linker to set a deterministic zero value for the
mtime in the N_OSO field of the object file.
Currently it's believe that older versions of the linker will simply
ignore this env var, while newer versions will read it and produce a
deterministic output for compilations with debuginfo.
Closes#47086Closes#66568
flip1995
Igor Matuszewski
bors
Matthias Krüger
Dylan DPC
Eduardo Broto
Sora Morimoto
Chris Simpkins
philipp
ThibsG
Philipp Hansch
Alex Crichton
Guillaume Gomez