Rollup of 8 pull requests
Successful merges:
- #54564 (Add 1.29.1 release notes)
- #54567 (Include path in stamp hash for debuginfo tests)
- #54577 (rustdoc: give proc-macros their own pages)
- #54590 (std: Don't let `rust_panic` get inlined)
- #54598 (Remove useless lifetimes from `Pin` `impl`s.)
- #54604 (Added help message for `self_in_typedefs` feature gate)
- #54635 (Improve docs for std::io::Seek)
- #54645 (Compute Android gdb version in compiletest)
Revert most of MaybeUninit, except for the new API itself
This reverts most of https://github.com/rust-lang/rust/pull/53508/ for perf reasons (first commit reverts that entire PR), except for the new API itself (added back in 2nd commit).
rustdoc: give proc-macros their own pages
related to https://github.com/rust-lang/rust/issues/49553 but i don't think it'll fix it
Currently, rustdoc doesn't expose proc-macros all that well. In the source crate, only their definition function is exposed, but when re-exported, they're treated as a macro! This is an awkward situation in all accounts. This PR checks functions to see whether they have any of `#[proc_macro]`, `#[proc_macro_attribute]`, or `#[proc_macro_derive]`, and exposes them as macros instead. In addition, attributes and derives are exposed differently than other macros, getting their own item-type, CSS class, and module heading.
Function-like proc-macros are lumped in with `macro_rules!` macros, but they get a different declaration block (i'm open to tweaking this, it's just what i thought of given how function-proc-macros operate):
Proc-macro attributes and derives get their own pages, with a representative declaration block. Derive macros also show off their helper attributes:
There's one wrinkle which this PR doesn't address, which is why i didn't mark this as fixing the linked issue. Currently, proc-macros don't expose their attributes or source span across crates, so while rustdoc knows they exist, that's about all the information it gets. This leads to an "inlined" macro that has absolutely no docs on it, and no `[src]` link to show you where it was declared.
The way i got around it was to keep proc-macro re-export disabled, since we do get enough information across crates to properly link to the source page:
Until we can get a proc-macro's docs (and ideally also its source span) across crates, i believe this is the best way forward.
Compute Android gdb version in compiletest
compiletest has special code for running gdb for Android targets. In
particular it computes a different path to gdb. However, this gdb is
not used for the version test, which results in some tests being run
when they should not be. You can see this in #54004.
This patch moves the special case to analyze_gdb and a new helper
function to decide whether the case applies. This causes the version
check to work properly.
Note that the bulk of the runtest.rs change is just reindentation
caused by moving from a "match" to an "if" -- but there is a (small)
change buried in there.
std: Don't let `rust_panic` get inlined
It's meant for breakpoints, so if it gets inlined we can't set a
breakpoint on it easily!
Will hopefully help fix at least one aspect of https://github.com/rust-lang/rust/issues/49013
Because `call_once` is generic, but `is_completed` is not, we need
`#[inline]` annotation to allow LLVM to inline `is_completed` into
`call_once` in downstream crates.
ignore {std,fast,vector,this}call on non-x86 windows
MSVC ignores these keywords for C/C++ and uses the standard system
calling convention. Rust should do so as well.
Fixes#54569.
Include path in stamp hash for debuginfo tests
The debuginfo tests are exposed to the environment in a couple of
ways: the path to the gdb executable matters, as does the Python path
used when loading lldb.
This patch incorporates these paths into the hash that is written to
the stamp file, so that changing the path will cause the tests to be
re-run.
rustc: keep a Span for each predicate in ty::GenericPredicates.
This should allow finer-grained diagnostics, including migration suggestions for #54090.
(Note that I haven't changed most of the users of `predicates_of` to use the new spans)
r? @nikomatsakis
compiletest has special code for running gdb for Android targets. In
particular it computes a different path to gdb. However, this gdb is
not used for the version test, which results in some tests being run
when they should not be. You can see this in #54004.
This patch moves the special case to analyze_gdb and a new helper
function to decide whether the case applies. This causes the version
check to work properly.
Note that the bulk of the runtest.rs change is just reindentation
caused by moving from a "match" to an "if" -- but there is a (small)
change buried in there.
Emit used rustc invocation in the save-analysis file
Blocked on https://github.com/nrc/rls-data/pull/19. (I'm guessing it won't pass CI due to an out-of-tree git dependency)
This should allow RLS to recreate a Rust compilation build plan from the save-analysis files alone, which should be useful when fetching those from external build systems, most notably Buck now.
Also this includes some more potentially useful compilation-specific options (e.g. sysroot or the actual path to extern crates) but that's not required for the build plan bits.
cc @jsgf @alexcrichton
r? @nrc
Before this patch running the following command would generate the given output:
$ rustc +stage1 src/test/ui/liveness/liveness-move-in-while.rs -Zborrowck=mir -Ztwo-phase-borrows
error[E0382]: borrow of moved value: `y`
--> src/main.rs:8:24
|
8 | println!("{}", y); //~ ERROR use of moved value: `y`
| ^ value borrowed here after move
9 | while true { while true { while true { x = y; x.clone(); } } }
| - value moved here
|
= note: move occurs because `y` has type `std::boxed::Box<isize>`, which does not implement the `Copy` trait
We want to give the user more hint by telling them that the value was moved in the previous iteration of the
loop. After this patch, the error message adds the phrase "in previous iteration of loop" and in totality
looks like this:
$ rustc +stage1 src/test/ui/liveness/liveness-move-in-while.rs -Zborrowck=mir -Ztwo-phase-borrows
error[E0382]: borrow of moved value: `y`
--> src/test/ui/liveness/liveness-move-in-while.rs:17:24
|
17 | println!("{}", y); //~ ERROR use of moved value: `y`
| ^ value borrowed here after move
18 | while true { while true { while true { x = y; x.clone(); } } }
| - value moved here, in previous iteration of loop
|
= note: move occurs because `y` has type `std::boxed::Box<isize>`, which does not implement the `Copy` trait
codegen_llvm: check inline assembly constraints with LLVM
---%<---
Hey all,
As issue #54130 highlights, constraints are not checked and passing bad constraints to LLVM can crash it since a `Verify()` call is placed inside an assertion (see: `src/llvm/lib/IR/InlineAsm.cpp:39`).
As this is my first PR to the Rust compiler (woot! 🎉), there might be better ways of achieving this result. In particular, I am not too happy about generating an error in codegen; it would be much nicer if we did it earlier. However, @rkruppe [noted on IRC](https://botbot.me/mozilla/rustc/2018-09-25/?msg=104791581&page=1) that this should be fine for an unstable feature and a much better solution than the _status quo_, which is an ICE.
Thanks!
--->%---
LLVM provides a way of checking whether the constraints and the actual
inline assembly make sense. This commit introduces a check before
emitting code for the inline assembly. If LLVM rejects the inline
assembly (or its constraints), then the compiler emits an error E0668
("malformed inline assembly").
Fixes: #54130
Signed-off-by: Levente Kurusa \<lkurusa@acm.org\>
Use full name to identify a macro in a `FileName`.
Before this two macros with same name would be indistinguishable inside a `FileName`. This caused a bug in incremental compilation (see #53097) since two different macros would map out to the same `StableFilemapId`.
Fixes#53097.
r? @nrc
RFC 2093 (tracking issue #44493) lets us leave off
commonsensically inferable `T: 'a` outlives requirements. (A separate
feature-gate was split off for the case of 'static lifetimes, for
which questions still remain.) Detecting these was requested as an
idioms-2018 lint.
It turns out that issuing a correct, autofixable suggestion here is
somewhat subtle in the presence of other bounds and generic
parameters. Basically, we want to handle these three cases:
• One outlives-bound. We want to drop the bound altogether, including
the colon—
MyStruct<'a, T: 'a>
^^^^ help: remove this bound
• An outlives bound first, followed by a trait bound. We want to
delete the outlives bound and the following plus sign (and
hopefully get the whitespace right, too)—
MyStruct<'a, T: 'a + MyTrait>
^^^^^ help: remove this bound
• An outlives bound after a trait bound. We want to delete the
outlives lifetime and the preceding plus sign—
MyStruct<'a, T: MyTrait + 'a>
^^^^^ help: remove this bound
This gets (slightly) even more complicated in the case of where
clauses, where we want to drop the where clause altogether if there's
just the one bound. Hopefully the comments are enough to explain
what's going on!
A script (in Python, sorry) was used to generate the
hopefully-sufficiently-exhaustive UI test input. Some of these are
split off into a different file because rust-lang-nursery/rustfix#141
(and, causally upstream of that, #53934) prevents them from being
`run-rustfix`-tested.
We also make sure to include a UI test of a case (copied from RFC
2093) where the outlives-bound can't be inferred. Special thanks to
Niko Matsakis for pointing out the `inferred_outlives_of` query,
rather than blindly stripping outlives requirements as if we weren't a
production compiler and didn't care.
This concerns #52042.
This function isn't strictly tied to LLVM (it's more of a utility) and
it's now near an analogous, almost identical `filename_for_input` (for
rlibs and so forth).
Also this means not depending on the backend when one wants to know the
accurate .rmeta output filename.
Migrate `src/test/ui/run-pass/*` back to `src/test/run-pass/`.
Moves all the tests from `src/test/ui/run-pass/**` back to `src/test/run-pass/`.
This should have no impact on our overall testing completeness due to PR #54223Fix#54047
