Print space after formal generic params in fn type
Follow-up to #92238 fixing one of the FIXMEs.
```rust
macro_rules! repro {
($ty:ty) => {
stringify!($ty)
};
}
fn main() {
println!("{}", repro!(for<'a> fn(&'a u8)));
}
```
Before: `for<'a>fn(&'a u8)`
After: `for<'a> fn(&'a u8)`
The pretty printer's `print_formal_generic_params` already prints formal generic params correctly with a space, we just need to call it when printing BareFn types instead of reimplementing the printing incorrectly without a space.
83b15bfe1c/compiler/rustc_ast_pretty/src/pprust/state.rs (L1394-L1400)
Visit expressions in-order when resolving pattern bindings
[edited:] Visit the pattern's sub-expressions before defining any bindings.
Otherwise, we might get into a case where a Lit/Range expression in a pattern has a qpath pointing to a Ident pattern that is defined after it, causing an ICE when lowering to HIR. I have a more detailed explanation in the issue linked.
Fixes#92100
Parse and suggest moving where clauses after equals for type aliases
~Mostly the same as #90076, but doesn't make any syntax changes.~ Whether or not we want to land the syntax changes, we should parse the invalid where clause position and suggest moving.
r? `@nikomatsakis`
cc `@petrochenkov` you might have thoughts on implementation
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).
r? `@camelid`
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.
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.
Limit the ``[`identity_op`]`` lint to integral operands.
changelog: limit ``[`identity_op`]`` to integral operands
In the ``[`identity_op`]`` lint, if the operands are non-integers, then the lint is likely
wrong.
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`
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 (⬆️ rust-analyzer)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
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.
Fixes#92324
r? `@cjgillot`
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.
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.
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.
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,
}
enum Something {
CCall,
CCreate,
CCryogenize,
}
```
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)
`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
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
Readme: note that config changes don't apply to already compiled code
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: added a note to the Readme that config changes don't apply to already compiled code
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: added a note to the Readme that config changes don't apply to already compiled code
