Matthias Krüger [Wed, 29 Dec 2021 09:17:08 +0000 (10:17 +0100)]
Rollup merge of #92075 - jyn514:resolve-cleanup, r=camelid
rustdoc: Only special case struct fields for intra-doc links, not enum variants
Variants are already handled by `resolve_str_path_error`, rustdoc doesn't need to consider them separately. Thanks `@camelid` for catching this!
Eventually I'd like to fix the "combine this with `variant_field`" comment but that needs `resolve_field` to take a `ty_res` parameter to avoid it being super hacky (cc https://github.com/rust-lang/rust/issues/83761#issuecomment-813026026).
bors [Wed, 29 Dec 2021 02:49:34 +0000 (02:49 +0000)]
Auto merge of #92283 - vacuus:print-generic-bounds, r=camelid,GuillaumeGomez
rustdoc: Remove `String` allocation in iteration in `print_generic_bounds`
(I realized only after making the commit that maybe I shouldn't refer to iteration as looping, but it's close enough)
The string representation of a `clean::GenericBound` instance (evaluated [here](https://github.com/rust-lang/rust/blob/master/src/librustdoc/html/format.rs#L397)) is deterministic for a given `self` (the instance), `cx` and `f`, and since `cx` and `f` are constant (as far as I can tell) for a given invocation of `print_generic_bounds`, `self` is the determining factor. Therefore, using the data in `self` shouldn't differ in effect from using its string representation.
Given the totality of the function calls needed to evaluate the string representation as well as the actual allocation, at the very least, this shouldn't negatively affect performance.
Noah Lev [Tue, 28 Dec 2021 21:15:02 +0000 (13:15 -0800)]
Add regression test for #59502
This issue was fixed using a hacky recursion "fuel" argument, but the
issue was never minimized nor was a regression test added. The
underlying bug is still unfixed, so this test should help with fixing it
and removing the `recurse` hack.
bors [Tue, 28 Dec 2021 17:11:40 +0000 (17:11 +0000)]
Auto merge of #8187 - ApamNapat:fix_7651, r=llogiq
Fixed issues with to_radians and to_degrees lints
fixes #7651
I fixed the original problem as described in the issue, but the bug remains for complex expressions (the commented out TC I added is an example). I would also love some feedback on how to cleanup my code and reduce duplication. I hope it's not a problem that the issue has been claimed by someone else - that was over two months ago.
changelog: ``[`suboptimal_flops`]`` no longer proposes broken code with `to_radians` and `to_degrees`
bors [Tue, 28 Dec 2021 16:59:56 +0000 (16:59 +0000)]
Auto merge of #92352 - matthiaskrgr:rollup-19fbq7u, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #92076 (Ignore other `PredicateKind`s in rustdoc auto trait finder)
- #92219 (Remove VCVARS_BAT)
- #92238 (Add a test suite for stringify macro)
- #92330 (Add myself to .mailmap)
- #92333 (Tighten span when suggesting lifetime on path)
- #92335 (Document units for `std::column`)
- #92344 (:arrow_up: rust-analyzer)
Matthias Krüger [Tue, 28 Dec 2021 12:59:25 +0000 (13:59 +0100)]
Rollup merge of #92333 - compiler-errors:elided-lifetime-spans, r=cjgillot
Tighten span when suggesting lifetime on path
This is kind of a hack.
Really the issue here is that we want to suggest the segment's span if the path resolves to something defined outside of the macro, and the macro's span if it resolves to something defined within.. I'll look into seeing if we can do something like that.
Matthias Krüger [Tue, 28 Dec 2021 12:59:24 +0000 (13:59 +0100)]
Rollup merge of #92238 - dtolnay:stringifytest, r=Mark-Simulacrum
Add a test suite for stringify macro
This attempts to cover the behavior of `stringify!` on various interpolated syntax tree nodes.
The pretty printer has a history of unsightly whitespace (double spaces, missing spaces, spaces where there shouldn't be spaces) — #91437, #91562, #91568. There are several such issues left; the test cases that I consider to be currently behaving incorrectly are marked with `// FIXME` in the PR.
Matthias Krüger [Tue, 28 Dec 2021 12:59:23 +0000 (13:59 +0100)]
Rollup merge of #92219 - ehuss:remove-vcvars, r=Mark-Simulacrum
Remove VCVARS_BAT
This environment variable is no longer used. It was used in the original Azure Pipelines configuration (#60777). When GitHub Actions were added (#70190), it was no longer used, and I suspect it was just an oversight while transitioning the configuration.
Matthias Krüger [Tue, 28 Dec 2021 12:59:22 +0000 (13:59 +0100)]
Rollup merge of #92076 - Aaron1011:rustdoc-auto-trait-ignore, r=cjgillot
Ignore other `PredicateKind`s in rustdoc auto trait finder
Fixes #92073
There's not really anything we can do with them, and they're
causing ICEs. I'm not using a wildcard match, as we should check
that any new `PredicateKind`s are handled properly by rustdoc.
bors [Tue, 28 Dec 2021 12:01:21 +0000 (12:01 +0000)]
Auto merge of #8127 - dswij:8090, r=xFrednet
Fix `enum_variants` FP on prefixes that are not camel-case
closes #8090
Fix FP on `enum_variants` when prefixes are only a substring of a camel-case word. Also adds some util helpers on `str_utils` to help parsing camel-case strings.
This changes how the lint behaves:
1. previously if the Prefix is only a length of 1, it's going to get ignored, i.e. these were previously ignored and now is warned
```rust
enum Foo {
cFoo,
cBar,
cBaz,
}
2. non-ascii characters that doesn't have casing will not be split,
```rust
enum NonCaps {
PrefixXXX,
PrefixTea,
PrefixCake,
}
```
will be considered as `PrefixXXX`, `Prefix`, `Prefix`, so this won't lint as opposed to fired previously.
changelog: [`enum_variant_names`] Fix FP when first prefix are only a substring of a camel-case word.
---
(Edited by `@xFrednet` removed some non ascii characters)
bors [Tue, 28 Dec 2021 11:15:53 +0000 (11:15 +0000)]
Auto merge of #8185 - dswij:8177, r=llogiq
`needless_return` suggest return unit type on void returns
closes #8177
previously, `needless_return` suggests an empty block `{}` to replace void `return` on match arms, this PR improve the suggestion by suggesting a unit instead.
changelog: `needless_return` suggests `()` instead of `{}` on match arms
bors [Tue, 28 Dec 2021 11:15:53 +0000 (11:15 +0000)]
`needless_return` suggest return unit type on void returns
closes #8177
previously, `needless_return` suggests an empty block `{}` to replace void `return` on match arms, this PR improve the suggestion by suggesting a unit instead.
changelog: `needless_return` suggests `()` instead of `{}` on match arms
bors [Tue, 28 Dec 2021 05:50:20 +0000 (05:50 +0000)]
Auto merge of #8182 - rust-lang:cache-test-items, r=giraffate
cache test item names
This avoids quadratic behavior (collecting all test item names for each `eq_op` instance within the module). However, it invests a good deal of memory to buy this speedup. If that becomes a problem, I may need to change the cache to only store the chain of last visited modules.
bors [Tue, 28 Dec 2021 04:19:01 +0000 (04:19 +0000)]
Auto merge of #92088 - camelid:intra-doc-cleanup, r=Manishearth
intra-doc: Use an enum to represent URL fragments
This is a step in the direction of computing the links more lazily,
which I think will simplify the implementation of intra-doc links.
This will also make it easier to eventually use the actual `Res` for
associated items, enum variants, and fields, rather than their HTML
page's `Res`.
Noah Lev [Tue, 28 Dec 2021 02:59:27 +0000 (18:59 -0800)]
Make `search_index` functions private where possible
Now the only two crate-public items are `build_index` and
`get_index_search_type` (because for some reason the latter is also used
in `formats::cache`).
Noah Lev [Tue, 28 Dec 2021 02:57:07 +0000 (18:57 -0800)]
Move `ExternalLocation` to `clean::types`
It was previously defined in `render::search_index` but wasn't used at
all there. `clean::types` seems like a better fit since that's where
`ExternalCrate` is defined.
Noah Lev [Tue, 28 Dec 2021 02:53:00 +0000 (18:53 -0800)]
rustdoc: Remove some unnecessary `cache` parameters
Based on
https://github.com/rust-lang/rust/pull/80883#issuecomment-774437832.
The `tcx` parameters do seem to be used though, so I only removed the
`cache` parameters.
Noah Lev [Sat, 18 Dec 2021 21:33:01 +0000 (13:33 -0800)]
intra-doc: Use an enum to represent URL fragments
This is a step in the direction of computing the links more lazily,
which I think will simplify the implementation of intra-doc links.
This will also make it easier to eventually use the actual `Res` for
associated items, enum variants, and fields, rather than their HTML
page's `Res`.
bors [Mon, 27 Dec 2021 21:55:52 +0000 (21:55 +0000)]
Auto merge of #92329 - matthiaskrgr:rollup-l3b4fl1, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #90586 (Relax priv-in-pub lint on generic bounds and where clauses of trait impls.)
- #92112 (Fix the error of checking `base_expr` twice in type_changing_struct_update)
- #92147 (rustc_builtin_macros: make asm mod public for rustfmt)
- #92161 (resolve: Minor miscellaneous cleanups from #89059)
- #92264 (Remove `maybe_uninit_extra` feature from Vec docs)
- #92303 (Add test cases for issue #26186)
- #92307 (Fix minor typos)
Matthias Krüger [Mon, 27 Dec 2021 20:42:29 +0000 (21:42 +0100)]
Rollup merge of #92303 - Patrick-Poitras:issue-26186, r=jackh726
Add test cases for issue #26186
Closes #26186
It seems that issue #26186 has been solved at some point since the issue has been last updated. I've merged together the examples that were supplied by `@Osspial,` `@Mark-Simulacrum,` `@Diggsey,` `@eefriedman` and `@shepmaster,` so that we can add this to the testing suite and prevent these issues from re-occurring.
Matthias Krüger [Mon, 27 Dec 2021 20:42:25 +0000 (21:42 +0100)]
Rollup merge of #90586 - jswrenn:relax-privacy-lints, r=petrochenkov
Relax priv-in-pub lint on generic bounds and where clauses of trait impls.
The priv-in-pub lint is a legacy mechanism of the compiler, supplanted by a reachability-based [type privacy](https://github.com/rust-lang/rfcs/blob/master/text/2145-type-privacy.md) analysis. This PR does **not** relax type privacy; it only relaxes the lint (as proposed by the type privacy RFC) in the case of trait impls.
## Current Behavior
On public trait impls, it's currently an **error** to have a `where` bound constraining a private type with a trait:
```rust
pub trait Trait {}
pub struct Type {}
struct Priv {}
impl Trait for Priv {}
impl Trait for Type
where
Priv: Trait // ERROR
{}
```
...and it's a **warning** to have have a public type constrained by a private trait:
```rust
pub trait Trait {}
pub struct Type {}
impl Trait for Type
where
Pub: Priv // WARNING
{}
```
This lint applies to `where` clauses in other contexts, too; e.g. on free functions:
```rust
struct Priv<T>(T);
pub trait Pub {}
impl<T: Pub> Pub for Priv<T> {}
pub fn function<T>()
where
Priv<T>: Pub // WARNING
{}
```
**These constraints could be relaxed without issue.**
## New Behavior
This lint is relaxed for `where` clauses on trait impls, such that it's okay to have a `where` bound constraining a private type with a trait:
```rust
pub trait Trait {}
pub struct Type {}
struct Priv {}
impl Trait for Priv {}
impl Trait for Type
where
Priv: Trait // OK
{}
```
...and it's okay to have a public type constrained by a private trait:
```rust
pub trait Trait {}
pub struct Type {}
## Rationale
While the priv-in-pub lint is not essential for soundness, it *can* help programmers avoid pitfalls that would make their libraries difficult to use by others. For instance, such a lint *is* useful for free functions; e.g. if a downstream crate tries to call the `function` in the previous snippet in a generic context:
```rust
fn callsite<T>()
where
Priv<T>: Pub // ERROR: omitting this bound is a compile error, but including it is too
{
function::<T>()
}
```
...it cannot do so without repeating `function`'s `where` bound, which we cannot do because `Priv` is out-of-scope. A lint for this case is arguably helpful.
However, this same reasoning **doesn't** hold for trait impls. To call an unconstrained method on a public trait impl with private bounds, you don't need to forward those private bounds, you can forward the public trait:
```rust
mod upstream {
pub trait Trait {
fn method(&self) {}
}
pub struct Type<T>(T);
impl<T> Trait for Type<T>
where
Pub<T>: Priv // WARNING
{}
}
mod downstream {
use super::upstream::*;
fn function<T>(value: Type<T>)
where
Type<T>: Trait // <- no private deets!
{
value.method();
}
}
```
**This PR only eliminates the lint on trait impls.** It leaves it intact for all other contexts, including trait definitions, inherent impls, and function definitions. It doesn't need to exist in those cases either, but I figured I'd first target a case where it's mostly pointless.
## Other Notes
- See discussion [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/relax.20priv-in-pub.20lint.20for.20trait.20impl.20.60where.60.20bounds/near/222458397).
- This PR effectively reverts #79291.
bors [Sat, 25 Dec 2021 14:47:12 +0000 (14:47 +0000)]
Auto merge of #92227 - Kobzol:rustdoc-doc-hidden, r=jyn514
Rustdoc: use `is_doc_hidden` method on more places
While profiling `rustdoc`, I noticed that finding out if some item is marked with `#[doc(hidden)]` is relatively hot, so I tried to optimize it.
I noticed that there is already a method called `is_doc_hidden` on `TyCtxt`, but it wasn't used much, so I replaced the manual calls to `attrs(...).has_word(...)` with this method. Just by doing that, perf. was improved locally, although I'm not sure if the semantics of the previous calls and this method are the same?
As another step, I tried to querify `is_doc_hidden`, but I didn't include that here until we see the perf. results from the first commit and until I find whether this change is OK at all :)
projects / rust.git / log