bors [Sun, 17 Nov 2019 07:45:00 +0000 (07:45 +0000)]
Auto merge of #66336 - ehuss:update-cargo-books, r=Mark-Simulacrum
Update Cargo, books
## cargo
12 commits in 5da4b4d47963868d9878480197581ccbbdaece74..8280633db680dec5bfe1de25156d1a1d53e6d190
2019-10-28 21:53:41 +0000 to 2019-11-11 23:17:05 +0000
- Don't panic when parsing `/proc/stat` (rust-lang/cargo#7580)
- Fix unused configuration key warning for a few keys under `build`. (rust-lang/cargo#7575)
- Add back support for `BROWSER` envvar in `cargo doc --open`. (rust-lang/cargo#7576)
- Only include "already existing ..." comment in gitignore on conflict (rust-lang/cargo#7570)
- Add VS Code user dir to .gitignore (rust-lang/cargo#7578)
- Added aliases to subcommand typo suggestions. (rust-lang/cargo#7486)
- Use multiple requirement syntax consistently (rust-lang/cargo#7573)
- Update verison to 0.42 (rust-lang/cargo#7568)
- Expand documentation on build scripts. (rust-lang/cargo#7565)
- Update crossbeam-utils requirement from 0.6 to 0.7 (rust-lang/cargo#7566)
- don't download std-docs on CI (rust-lang/cargo#7513)
- Change my-buddy to github-handle (rust-lang/cargo#7553)
7 commits in 4b21b646669e0af49fae7cae301898dc4bfaa1f0..45558c464fb458affbcdcb34323946da45c8a117
2019-10-27 22:33:11 +0100 to 2019-11-08 14:47:35 +0100
- Audit code blocks. (rust-lang-nursery/reference#715)
- Update coherence and orphan rules documentation to match RFC 2451 (rust-lang-nursery/reference#703)
- Update organization name (rust-lang-nursery/reference#713)
- State that no_implicit_prelude also applies to nested modules (rust-lang-nursery/reference#707)
- expand Copy docs (rust-lang-nursery/reference#711)
- github action doesn't use the nursery (rust-lang-nursery/reference#706)
- Migrate to GitHub Actions. (rust-lang-nursery/reference#705)
Yuki Okushi [Sun, 17 Nov 2019 04:36:25 +0000 (13:36 +0900)]
Rollup merge of #66477 - ALSchwalm:clarify-transmute-copy, r=Centril
Clarify transmute_copy documentation example
Currently the documentation for `transmute_copy` implies that the function accepts a slice due to the variable name chosen in the example. This is misleading as `foo_slice` is actually an array and `transmute_copy` cannot take an unsized type anyway.
This PR just clarifies things by renaming the variable used in the example.
Yuki Okushi [Sun, 17 Nov 2019 04:36:22 +0000 (13:36 +0900)]
Rollup merge of #66469 - CosineP:fix/field-lint, r=petrochenkov
Use "field is never read" instead of "field is never used"
this is my first PR here so please let me know if i am doing it wrong
closes #64465
i will be referencing this with a book PR that updates the same language
Yuki Okushi [Sun, 17 Nov 2019 04:36:18 +0000 (13:36 +0900)]
Rollup merge of #66456 - Centril:driver-codes, r=Mark-Simulacrum
Move `DIAGNOSTICS` usage to `rustc_driver`
Remove `rustc_interface`'s dependency on `rustc_error_codes` and centralize all usages of `DIAGNOSTICS` in `rustc_driver`. Once we remove all references to `rustc_error_codes` in all other crates but `rustc_driver`, this should allow for incremental recompilation of the compiler to be smoother when tweaking error codes. This works towards https://github.com/rust-lang/rust/issues/66210#issuecomment-551862528.
Yuki Okushi [Sun, 17 Nov 2019 04:36:16 +0000 (13:36 +0900)]
Rollup merge of #66395 - jplatte:centralize-panic-docs, r=Dylan-DPC
Centralize panic macro documentation
This is just the main commit from #61511 (which got closed because the author didn't reply) cherry-picked on the current master. Building `core` and `std` on this branch in stage 1 succeeded, which I thinks means the issues from the previous PR should be gone (but let's see what CI says).
The preferred replacement is to use `register_tool` ([tracking issue](https://github.com/rust-lang/rust/issues/66079)).
```rust
#![register_tool(servo)]
#[servo::must_root]
struct S;
```
The more direct replacement is `register_attribute` ([tracking issue](https://github.com/rust-lang/rust/issues/66080))
```rust
#![register_attr(must_root)]
#[must_root]
struct S;
```
, but it requires registering each attribute individually rather than registering the tool once, and is more likely to be removed rather than stabilized.
Yuki Okushi [Sun, 17 Nov 2019 04:36:12 +0000 (13:36 +0900)]
Rollup merge of #66271 - petrochenkov:abism, r=Centril
syntax: Keep string literals in ABIs and `asm!` more precisely
As a result we don't lose spans when `extern` functions or blocks are passed to proc macros, and also escape all string literals consistently.
Continuation of https://github.com/rust-lang/rust/pull/60679, which did a similar thing with all literals besides those in ABIs and `asm!`.
Yuki Okushi [Sun, 17 Nov 2019 04:36:10 +0000 (13:36 +0900)]
Rollup merge of #65739 - mqudsi:vec_split_off_docs, r=dtolnay
Improve documentation of `Vec::split_off(...)`
The previous ordering of the sentences kept switching between the return
value and the value of `self` after execution, making it hard to follow.
Additionally, as rendered in the browser, the period in "`Self`. `self`"
was difficult to make out as being a sentence separator and not one code
block.
Esteban Küber [Wed, 16 Oct 2019 01:42:27 +0000 (18:42 -0700)]
Suggest borrowing when it would satisfy an unmet trait bound
When there are multiple implementors for the same trait that is present
in an unmet binding, modify the E0277 error to refer to the parent
obligation and verify whether borrowing the argument being passed in
would satisfy the unmet bound. If it would, suggest it.
Mahmoud Al-Qudsi [Wed, 23 Oct 2019 21:32:16 +0000 (16:32 -0500)]
Improve documentation of `Vec::split_off(...)`
The previous ordering of the sentences kept switching between the return
value and the value of `self` after execution, making it hard to follow.
Additionally, as rendered in the browser, the period in "`Self`. `self`"
was difficult to make out as being a sentence separator and not one code
block.
bors [Sat, 16 Nov 2019 19:50:48 +0000 (19:50 +0000)]
Auto merge of #64694 - petrochenkov:reshelp, r=matthewjasper
Fully integrate derive helpers into name resolution
```rust
#[derive(Foo)]
#[foo_helper] // already goes through name resolution
struct S {
#[foo_helper] // goes through name resolution after this PR
field: u8
}
```
How name resolution normally works:
- We have an identifier we need to resolve, take its location (in some sense) and look what names are in scope in that location.
How derive helper attributes are "resolved" (before this PR):
- After resolving the derive `Foo` we visit the derive's input (`struct S { ... } `) as a piece of AST and mark attributes textually matching one of the derive's helper attributes (`foo_helper`) as "known", so they never go through name resolution.
This PR changes the rules for derive helpers, so they are not proactively marked as known (which is a big hack ignoring any ambiguities or hygiene), but go through regular name resolution instead.
This change was previously blocked by attributes not being resolved in some positions at all (fixed in https://github.com/rust-lang/rust/pull/63468).
"Where exactly are derive helpers in scope?" is an interesting question, and I need some feedback from proc macro authors to answer it, see the post below (https://github.com/rust-lang/rust/pull/64694#issuecomment-533925160).
Nadrieril [Sat, 16 Nov 2019 16:05:32 +0000 (16:05 +0000)]
Introduce new FixedLenSlice constructor
It is used in the case where a variable-length slice pattern is used to
match on an array of known size. This allows considering only those
entries in the array that are captured by one of the patterns.
As a side-effect, diagnostics improve a bit for those cases.
These helpers are resolved before their respective derives through a kind of look ahead into future expansions.
Some of these will migrate to proper resolution, others will be deprecated.
bors [Sat, 16 Nov 2019 07:26:57 +0000 (07:26 +0000)]
Auto merge of #66255 - ehuss:update-cc, r=alexcrichton
Update cc, git2, num_cpus.
This updates the `cc` crate, bringing in better parallel building support. Also updates `git2` which enables the parallel feature. (Note: I don't expect it will have a significant impact on build time, but seems good to update anyways.)
The main thorn is that `cc` gained knowledge about RISC-V architectures (https://github.com/alexcrichton/cc-rs/pull/428, https://github.com/alexcrichton/cc-rs/pull/429, https://github.com/alexcrichton/cc-rs/pull/430), but the builders on CI do not have the riscv C compiler installed. This means that bootstraps' cc detection was finding a C compiler that isn't installed, and fails.
The solution here is to override the cc detection to `false`. The C compiler isn't actually used on riscv platforms. AFAIK, the only location would be compiler_builtins, and it currently forces C support off (https://github.com/rust-lang/compiler-builtins/blob/a533ae9c5aa325db209659679535fe1f186eae81/build.rs#L49-L55).
Other possible solutions:
- Add the override in cc_detect for riscv (or any "no-C" platform like wasm32 and nvptx)
- Install and use the appropriate c compiler. I tried this the `g++-riscv64-linux-gnu` package, but it failed missing some header file.
bors [Sat, 16 Nov 2019 02:40:52 +0000 (02:40 +0000)]
Auto merge of #66453 - Centril:rollup-w1ohzxs, r=Centril
Rollup of 5 pull requests
Successful merges:
- #66350 (protect creation of destructors by a mutex)
- #66407 (Add more tests for fixed ICEs)
- #66415 (Add --force-run-in-process unstable option to libtest)
- #66427 (Move the JSON error emitter to librustc_errors)
- #66441 (libpanic_unwind for Miri: make sure we have the SEH lang items when needed)
bors [Fri, 15 Nov 2019 23:28:50 +0000 (23:28 +0000)]
Auto merge of #66326 - Nadrieril:refactor-intrange, r=varkor
Refactor integer range handling in the usefulness algorithm
Integer range handling had accumulated a lot of debt. This cleans up a lot of it.
In particular this:
- removes unnecessary conversions between `Const` and `u128`, and between `Constructor` and `IntRange`
- clearly distinguishes between on the one hand ranges of integers that may or may not be matched exhaustively, and on the other hand ranges of non-integers that are never matched exhaustively and are compared using Const-based shenanigans
- cleans up some overly complicated code paths
- generally tries to be more idiomatic.
As a nice side-effect, I measured a 10% perf increase on `unicode_normalization`.
There's one thing that I feel remains to clean up: the [overlapping range check](https://github.com/rust-lang/rust/pull/64007), which is currently quite ad-hoc. But that is intricate enough that I'm leaving it out of this PR.
There's also one little thing I'm not sure I understand: can `try_eval_bits` fail for an integer constant value in that code ? What would that mean, and how do I construct a test case for this possibility ?
Dylan MacKenzie [Mon, 28 Oct 2019 17:26:16 +0000 (10:26 -0700)]
Use new const-checker for `mir_const_qualif`
Now `mir_const_qualif` must be called for `static`s and `const fn`s as
well as `const`s since it is responsible for const-checking. We return
the qualifs in the return place for everything, even though they will
only be used for `const`s.
Dylan MacKenzie [Wed, 30 Oct 2019 00:19:58 +0000 (17:19 -0700)]
Enable standalone const-checking with `Validator`
Unlike the original pass, we check *every* non-cleanup basic block
instead of stopping at `SwitchInt`. We use the `is_cfg_cyclic` function
to check for loops unlike the original checker which could not differentiate
between true cycles and basic blocks with more than two predecessors.
The last three functions are all copied verbatim from `qualify_consts`.
libpanic_unwind for Miri: make sure we have the SEH lang items when needed
r? @oli-obk @alexcrichton This is required to fix the Miri toolstate. Turns out rustc complains when doing codegen for MSVC and these lang items do not exist. For now `cfg(miri)` needs to still be able to codegen (we [plan to change that](https://github.com/rust-lang/miri/pull/1048#issuecomment-554108470) but that's a larger project requiring improvements to xargo and maybe also cargo; that should not block fixing the toolstate). Yes, this is a hack, but it is inside `cfg(miri)` so I hope this is okay.
Rollup merge of #66427 - Mark-Simulacrum:errors-json, r=Centril
Move the JSON error emitter to librustc_errors
This is done both as a cleanup (it makes little sense for this emitter to be in libsyntax), but also as part of broader work to decouple Session from librustc itself.
Along the way, this also moves SourceMap to syntax_pos, which is also nice for the above reasons, as well as allowing dropping the SourceMapper trait from code. This had the unfortunate side-effect of moving `FatalError` to rustc_data_structures (it's needed in syntax_pos, due to SourceMap, but putting it there feels somehow worse).
Rollup merge of #66415 - tmandry:force-test-in-process, r=alexcrichton
Add --force-run-in-process unstable option to libtest
When running tests with `-Zpanic_abort_tests`, it's sometimes desirable to fall back to the old behavior of only running tests in-process. This comes in handy if the system process launcher is unavailable, or the test code somehow expects all tests to be run in the same process.
For example, in Fuchsia we have unit tests that actually test the process launcher itself, in which case we can't use the process launcher to run the tests :).
Nadrieril [Sat, 9 Nov 2019 21:46:46 +0000 (21:46 +0000)]
Remove fishy condition
That condition was leftover from a refactor, and was probably not
intended. In fact it can't trigger: it would require a ConstantValue of
an integral type for which `try_eval_bits` fails. But since we only
apply `subtract_ctors` to the output of `all_ctors`, this won't happen.