Guillaume Gomez [Mon, 8 Nov 2021 14:15:24 +0000 (15:15 +0100)]
Rollup merge of #90657 - GuillaumeGomez:one-char-last-line-removed, r=jyn514
Fix bug with `#[doc]` string single-character last lines
Fixes #90618.
This is because `.iter().all(|c| c == '*')` returns `true` if there is no character checked. And in case the last line has only one character, it simply returns `true`, making the last line behind removed.
bors [Mon, 8 Nov 2021 08:21:51 +0000 (08:21 +0000)]
Auto merge of #90675 - camelid:cleanup-impl, r=jyn514
rustdoc: Cleanup `clean::Impl` and other parts of `clean`
This PR cleans up and reduces the size of `clean::Impl`, makes some other small performance improvements, and removes some Clean impls that are either unnecessary or potentially confusing.
bors [Sun, 7 Nov 2021 23:03:55 +0000 (23:03 +0000)]
Auto merge of #88368 - jyn514:metadata-error, r=petrochenkov
Improve error when an .rlib can't be parsed
This usually describes either an error in the compiler itself or some
sort of IO error. Either way, we should report it to the user rather
than just saying "crate not found".
This only gives an error if the crate couldn't be loaded at all - if the
compiler finds another .rlib or .rmeta file which was valid, it will
continue to compile the crate.
Example output:
```
error[E0785]: found invalid metadata files for crate `foo`
--> bar.rs:3:24
|
3 | println!("{}", foo::FOO_11_49[0]);
| ^^^
|
= warning: failed to parse rlib '/home/joshua/test-rustdoc/libfoo.rlib': Invalid archive extended name offset
```
Noah Lev [Sun, 7 Nov 2021 06:10:01 +0000 (23:10 -0700)]
rustdoc: Refactor `Impl.{synthetic,blanket_impl}` into enum
This change has two advantages:
1. It makes the possible states clearer, and it makes it impossible to
construct invalid states, such as a blanket impl that is also an auto
trait impl.
2. It shrinks the size of `Impl` a bit, since now there is only one
field, rather than two.
Joshua Nelson [Thu, 26 Aug 2021 18:37:44 +0000 (18:37 +0000)]
Improve error when an .rlib can't be parsed
This usually describes either an error in the compiler itself or some
sort of IO error. Either way, we should report it to the user rather
than just saying "crate not found".
This only gives an error if the crate couldn't be loaded at all - if the
compiler finds another .rlib or .rmeta file which was valid, it will
continue to compile the crate.
Example output:
```
error[E0785]: found invalid metadata files for crate `foo`
--> bar.rs:3:24
|
3 | println!("{}", foo::FOO_11_49[0]);
| ^^^
|
= warning: failed to parse rlib '/home/joshua/test-rustdoc/libfoo.rlib': Invalid archive extended name offset
```
bors [Sun, 7 Nov 2021 11:53:25 +0000 (11:53 +0000)]
Auto merge of #89310 - joshtriplett:available-concurrency-affinity, r=m-ou-se
Make `std::thread::available_concurrency` support process-limited number of CPUs
Use `libc::sched_getaffinity` and count the number of CPUs in the returned mask. This handles cases where the process doesn't have access to all CPUs, such as when limited via `taskset` or similar.
bors [Sun, 7 Nov 2021 04:59:42 +0000 (04:59 +0000)]
Auto merge of #90348 - Amanieu:asm_feature_gates, r=joshtriplett
Add features gates for experimental asm features
This PR splits off parts of `asm!` into separate features because they are not ready for stabilization.
Specifically this adds:
- `asm_const` for `const` operands.
- `asm_sym` for `sym` operands.
- `asm_experimental_arch` for architectures other than x86, x86_64, arm, aarch64 and riscv.
bors [Sat, 6 Nov 2021 22:55:37 +0000 (22:55 +0000)]
Auto merge of #90661 - matthiaskrgr:rollup-1umbdlx, r=matthiaskrgr
Rollup of 6 pull requests
Successful merges:
- #90487 (Add a chapter on reading Rustdoc output)
- #90508 (Apply adjustments for field expression even if inaccessible)
- #90627 (Suggest dereference of `Box` when inner type is expected)
- #90642 (use matches!() macro in more places)
- #90646 (type error go brrrrrrrr)
- #90649 (Run reveal_all on MIR when inlining is activated.)
Matthias Krüger [Sat, 6 Nov 2021 22:12:06 +0000 (23:12 +0100)]
Rollup merge of #90649 - cjgillot:reveal-all-2, r=lcnr
Run reveal_all on MIR when inlining is activated.
Fix logic error in https://github.com/rust-lang/rust/pull/85254 which prevented the pass from running when needed.
Fixes https://github.com/rust-lang/rust/issues/78442
r? ``@lcnr``
Matthias Krüger [Sat, 6 Nov 2021 22:12:06 +0000 (23:12 +0100)]
Rollup merge of #90646 - BoxyUwU:funky_ice, r=estebank
type error go brrrrrrrr
Fixes #90444
when we relate something like:
`fn(fn((), (), u32))` with `fn(fn((), (), ()))`
we relate the inner fn ptrs:
`fn((), (), u32)` with `fn((), (), ())`
yielding a `TypeError::ArgumentSorts(_, 2)` which we then use as the `TypeError` for the `fn(fn(..))` which later causes the ICE as the `2` does not correspond to any input or output types in `fn(_)`
bors [Sat, 6 Nov 2021 09:55:50 +0000 (09:55 +0000)]
Auto merge of #90617 - tmiasko:time-trace-threads, r=wesleywiser
Initialize LLVM time trace profiler on each code generation thread
In https://reviews.llvm.org/D71059 LLVM 11, the time trace profiler was
extended to support multiple threads.
`timeTraceProfilerInitialize` creates a thread local profiler instance.
When a thread finishes `timeTraceProfilerFinishThread` moves a thread
local instance into a global collection of instances. Finally when all
codegen work is complete `timeTraceProfilerWrite` writes data from the
current thread local instance and the instances in global collection
of instances.
Previously, the profiler was intialized on a single thread only. Since
this thread performs no code generation on its own, the resulting
profile was empty.
Update LLVM codegen to initialize & finish time trace profiler on each
code generation thread.
Notice that the `10` are actually integer tokens if you were to reparse them, not float tokens.
This diff updates `Literal::f32_unsuffixed` and `Literal::f64_unsuffixed` to produce tokens that unambiguously parse as a float. This matches longstanding behavior of the proc-macro2 crate's implementation of these APIs dating back at least 3.5 years, so it's likely an unobjectionable behavior.
bors [Sat, 6 Nov 2021 04:15:22 +0000 (04:15 +0000)]
Auto merge of #89970 - jackh726:gats_diagnostics, r=nikomatsakis
Implementation of GATs outlives lint
See #87479 for background. Closes #87479
The basic premise of this lint/error is to require the user to write where clauses on a GAT when those bounds can be implied or proven from any function on the trait returning that GAT.
## Intuitive Explanation (Attempt) ##
Let's take this trait definition as an example:
```rust
trait Iterable {
type Item<'x>;
fn iter<'a>(&'a self) -> Self::Item<'a>;
}
```
Let's focus on the `iter` function. The first thing to realize is that we know that `Self: 'a` because of `&'a self`. If an impl wants `Self::Item` to contain any data with references, then those references must be derived from `&'a self`. Thus, they must live only as long as `'a`. Furthermore, because of the `Self: 'a` implied bound, they must live only as long as `Self`. Since it's `'a` is used in place of `'x`, it is reasonable to assume that any value of `Self::Item<'x>`, and thus `'x`, will only be able to live as long as `Self`. Therefore, we require this bound on `Item` in the trait.
As another example:
```rust
trait Deserializer<T> {
type Out<'x>;
fn deserialize<'a>(&self, input: &'a T) -> Self::Out<'a>;
}
```
The intuition is similar here, except rather than a `Self: 'a` implied bound, we have a `T: 'a` implied bound. Thus, the data on `Self::Out<'a>` is derived from `&'a T`, and thus it is reasonable to expect that the lifetime `'x` will always be less than `T`.
## Implementation Algorithm ##
* Given a GAT `<P0 as Trait<P1..Pi>>::G<Pi...Pn>` declared as `trait T<A1..Ai> for A0 { type G<Ai...An>; }` used in return type of one associated function `F`
* Given env `E` (including implied bounds) for `F`
* For each lifetime parameter `'a` in `P0...Pn`:
* For each other type parameter `Pi != 'a` in `P0...Pn`: // FIXME: this include of lifetime parameters too
* If `E => (P: 'a)`:
* Require where clause `Ai: 'a`
## Follow-up questions ##
* What should we do when we don't pass params exactly?
For this example:
```rust
trait Des {
type Out<'x, D>;
fn des<'z, T>(&self, data: &'z Wrap<T>) -> Self::Out<'z, Wrap<T>>;
}
```
Should we be requiring a `D: 'x` clause? We pass `Wrap<T>` as `D` and `'z` as `'x`, and should be able to prove that `Wrap<T>: 'z`.
bors [Fri, 5 Nov 2021 22:12:31 +0000 (22:12 +0000)]
Auto merge of #90631 - matthiaskrgr:rollup-a5tzjh3, r=matthiaskrgr
Rollup of 5 pull requests
Successful merges:
- #89942 (Reorder `widening_impl`s to make the doc clearer)
- #90569 (Fix tests using `only-i686` to use the correct `only-x86` directive)
- #90597 (Warn for variables that are no longer captured)
- #90623 (Remove more checks for LLVM < 12)
- #90626 (Properly register text_direction_codepoint_in_comment lint.)
bors [Fri, 5 Nov 2021 19:05:36 +0000 (19:05 +0000)]
Auto merge of #90583 - willcrichton:example-analyzer, r=jyn514
Fix ICE when rustdoc is scraping examples inside of a proc macro
This PR provides a clearer semantics for how --scrape-examples interacts with macros. If an expression's span AND it's enclosing item's span both are not `from_expansion`, then the example will be scraped. The added test case `rustdoc-scrape-examples-macros` shows a variety of situations.
* A macro-rules macro that takes a function call as input: good
* A macro-rules macro that generates a function call as output: bad
* A proc-macro that generates a function call as output: bad
* An attribute macro that generates a function call as output: bad
* An attribute macro that takes a function call as input: good, if the proc macro is designed to propagate the input spans
I ran this updated rustdoc on pyo3 and confirmed that it successfully scrapes examples from inside a proc macro, eg
Tomasz Miąsko [Fri, 5 Nov 2021 00:00:00 +0000 (00:00 +0000)]
Initialize LLVM time trace profiler on each code generation thread
In https://reviews.llvm.org/D71059 LLVM 11, the time trace profiler was
extended to support multiple threads.
`timeTraceProfilerInitialize` creates a thread local profiler instance.
When a thread finishes `timeTraceProfilerFinishThread` moves a thread
local instance into a global collection of instances. Finally when all
codegen work is complete `timeTraceProfilerWrite` writes data from the
current thread local instance and the instances in global collection
of instances.
Previously, the profiler was intialized on a single thread only. Since
this thread performs no code generation on its own, the resulting
profile was empty.
Update LLVM codegen to initialize & finish time trace profiler on each
code generation thread.
bors [Fri, 5 Nov 2021 04:35:13 +0000 (04:35 +0000)]
Auto merge of #90598 - JohnTitor:rollup-kz1qioz, r=JohnTitor
Rollup of 9 pull requests
Successful merges:
- #90507 (Suggest `extern crate alloc` when using undeclared module `alloc`)
- #90530 (Simplify js tester a bit)
- #90533 (Add note about x86 instruction prefixes in asm! to unstable book)
- #90537 (Update aarch64 `target_feature` list for LLVM 12.)
- #90544 (Demote metadata load warning to "info".)
- #90554 (Clean up some `-Z unstable-options` in tests.)
- #90556 (Add more text and examples to `carrying_{add|mul}`)
- #90563 (rustbot allow labels)
- #90571 (Fix missing bottom border for headings in sidebar)
Yuki Okushi [Fri, 5 Nov 2021 01:32:47 +0000 (10:32 +0900)]
Rollup merge of #90563 - joshtriplett:rustbot-allow-labels, r=Mark-Simulacrum
rustbot allow labels
`relnotes` was inspired by https://github.com/rust-lang/rust/pull/90521 , and by the various `must_use` PRs; in all of those cases, the submitter of the PR could know that `relnotes` applied, but couldn't apply it themselves.
For `needs-fcp`, I think people should be able to help triage by observing that a change needs an FCP before we can apply it.
Yuki Okushi [Fri, 5 Nov 2021 01:32:44 +0000 (10:32 +0900)]
Rollup merge of #90544 - ehuss:demote-locator-warn, r=petrochenkov
Demote metadata load warning to "info".
There is a warn log message for whenever the crate loader fails to load metadata from a candidate file. I think this warning is too aggressive, as there are several situations where metadata information might not be found in a candidate file, which is normal. Also, this warning is somewhat confusing, and non-actionable in most cases for a user (most users will not know what it means).
If the crate loader ultimately does not find a valid crate, then an error will be reported (and hopefully #88368 will improve that error message).
If a rustc developer wants to debug a loader problem, they can still use `RUSTC_LOG=rustc_metadata=debug` and get the details.
There is more discussion of this particular warning at https://github.com/rust-lang/rust/issues/89795#issuecomment-940798190.
Yuki Okushi [Fri, 5 Nov 2021 01:32:41 +0000 (10:32 +0900)]
Rollup merge of #90533 - Smittyvb:patch-1, r=joshtriplett
Add note about x86 instruction prefixes in asm! to unstable book
Since rustc doesn't do the assembly parsing itself, it is unable to detect when inline assembly ends with an instruction prefix, which doesn't make sense since it would apply to instructions from the compiler. This fixes #82314 by mentioning that x86 instruction prefixes must not be used in inline assembly. AFAICT x86 is the only instruction set with instruction prefixes.