rustdoc: Add missing src links for generic impls on trait pages
`implementor2item` would return `None` for generic impls so instead this clones the entire `clean::Item` into the `implementors` map which simplifies some code.
rustc: use {U,I}size instead of {U,I}s shorthands.
`Us`/`Is` come from a time when `us` and `is` were the literal suffixes that are now `usize` / `isize`.
r? @nikomatsakis
Issue 46976
ICE is due to an empty path segments, so I set the path to be the same as the in band ty params symbol. (I think this is how regular generics end up being handled?)
Pinging @cramertj, this is your code I'm editing here.
Restore working debuginfo tests by trimming comments from non-header directive lines
I noticed when adding a debuginfo test that nothing I did caused the test to fail. Tracing back this seems to have been caused by 3e6c83de1d which broke parsing of the command/check lines, leaving all tests passing without any checking. This commit provides a basic (although still not very robust) restoration of tests and a should-fail test which checks the parser is running
Allow non-alphabetic underscores in camel case
Certain identifiers, such as `X86_64`, cannot currently be unambiguously represented in camel case (`X8664`, `X86_64`, `X8_664`, etc. are all transformed to the same identifier). This change relaxes the rules so that underscores are permitted between two non-alphabetic characters under `#[forbid(non_camel_case_types)]`. Fixes#34633 and fixes#41621.
Force appropriate extension when converting from int to ptr #43291Fixes#43291.
Looking for feedback if I've missed something and/or need to add more tests.
@eddyb @retep998 @nagisa @oli-obk
Reword reason for move note
On move errors, when encountering an enum variant, be more ambiguous and do not refer to the type on the cause note, to avoid referring to `(maybe as std::prelude::v1::Some).0`, and instead refer to `the value`.
Sidesteps part of the problem with #41962:
```
error[E0382]: use of partially moved value: `maybe`
--> file.rs:5:30
|
5 | if let Some(thing) = maybe {
| ----- ^^^^^ value used here after move
| |
| value moved here
= note: move occurs because the value has type `std::vec::Vec<bool>`, which does not implement the `Copy` trait
error[E0382]: use of moved value: `(maybe as std::prelude::v1::Some).0`
--> file.rs:5:21
|
5 | if let Some(thing) = maybe {
| ^^^^^ value moved here in previous iteration of loop
= note: move occurs because the value has type `std::vec::Vec<bool>`, which does not implement the `Copy` trait
error: aborting due to 2 previous errors
```
Previous discussion: #44360
r? @arielb1
NLL fixes
First, introduce pre-statement effects to dataflow to fix#46875. Edge dataflow effects might make that redundant, but I'm not sure of the best way to integrate them with liveness etc., and if this is a hack, this is one of the cleanest hacks I've seen.
And I want a small fix to avoid the torrent of bug reports.
Second, fix linking of projections to fix#46974
r? @pnkfelix
First cut at getting some part of the test suite working for CloudABI
I am currently working on creating a Docker container for automated CI for CloudABI. Here are some of the trivial changes that need to land to make tests pass.
It looks like many of these tests are already disabled on emscripten,
which also doesn't seem to support environment variables and subprocess
spawning. Just add a similar tag for CloudABI. While there, sort some of
the lists of operating systems alphabetically.
Check all repr hints together when checking for mis-applied attributes
Fixes#47094
Besides fixing that bug, this change has a user-visible effect on the spans in the "incompatible repr hints" warning and another error: they now point at `foo` and/or `bar` in `repr(foo, bar)` instead of the whole attribute. This is sometimes more precise (e.g., `#[repr(C, packed)]` on an enum points at the `packed`) but sometimes not. I moved a compile-fail test to a ui test to illustrate how it now looks in the common case of only one attribute.
Fixes#47094
Besides fixing that bug, this change has a user-visible effect on the spans in the "incompatible repr hints" warning and another error: they now point at `foo` and/or `bar` in `repr(foo, bar)` instead of the whole attribute. This is sometimes more precise (e.g., `#[repr(C, packed)]` on an enum points at the `packed`) but sometimes not. I moved a compile-fail test to a ui test to illustrate how it now looks in the common case of only one attribute.
Add compiler docs testing to CI.
Fixes#47025.
I don't know if `x86_64-gnu` is the right builder for this, but there seems to be time left on [Travis](https://travis-ci.org/rust-lang/rust/jobs/307488864).
Remaining problems blocking this PR:
- [x] broken links caused by rustdoc issues:
- [x] `pub use self::Enum::...`: #46766 and #46767 (fixed by #47050, thanks @ollie27!)
- [x] `impl Deref for DerefToStdType`: #32129 (ignored in linkchecker)
- [x] `#[feature(decl_macro)]` and `use std::vec`: #47038 (ignored in linkchecker)
- [x] `rustc_data_structures::sync::{Lrc, RwLock}` aliases `std` types: #32130 (ignored in linkchecker)
- [x] markdown differences, in rust repository and in external crates, now failing the build with #46880 merged (all fixed)
- [x] multiple crate updates needed: `rand`, `log`, `parking_lot_core`, `flate2`
- [x] submodule updates needed to deduplicate dependencies: `rust-installer`, ~`cargo`~ (done by #47052)
- [x] #44953 test broken by `log` update (removed, this can be controversial)
- [x] Waiting `x86_64-gnu` build results ([done](https://travis-ci.org/rust-lang/rust/builds/323451069))
See individual commits for more details.
It tested #44953.
`log` macros in newer versions are no longer recursive, so these duplicated
error messages (about unstable feature uses) previously occurring at each
level of recursion are no longer possible, even with the fix by #45540.
Furthermore this test breaks when multiple versions of `log` are in the
sysroot (`log 0.3.9` depends on`log 0.4.1`)
Reword trying to operate in immutable fields
The previous message ("cannot assign/mutably borrow immutable field")
when trying to modify a field of an immutable binding gave the
(incorrect) impression that fields can be mutable independently of their
ADT's binding. Slightly reword the message to read "cannot
assign/mutably borrow field of immutable binding".
Re #35937.
Allow lifetimes in macros
This is a resurrection of PR #41927 which was a resurrection of #33135, which is intended to fix#34303.
In short, this allows macros_rules! to use :lifetime as a matcher to match 'lifetimes.
Still to do:
- [x] Feature gate
Add a tidy check for missing or too many trailing newlines.
I've noticed recently there are lots of review comments requesting to fix trailing newlines. If this is going to be an official style here, it's better to let the CI do this repetitive check.
The previous message ("cannot assign/mutably borrow immutable field")
when trying to modify a field of an immutable binding gave the
(incorrect) impression that fields can be mutable independently of their
ADT's binding. Slightly reword the message to read "cannot
assign/mutably borrow field of immutable binding".
It's unnecessary to print the linker options if there is no linker installed.
Currently, for libraries, the output is still printed, see #46998 for
discussion
in which leading zeroes on tuple-struct accesses are abjured
Resolves#47073. If accepted, a point in the compatibility section of the release notes is warranted.
