New lint `manual_split_once`
This is a WIP because it still needs to recognize more patterns. Currently handles:
```rust
s.splitn(2, ' ').next();
s.splitn(2, ' ').nth(0)
s.splitn(2, ' ').nth(1);
s.splitn(2, ' ').skip(0).next();
s.splitn(2, ' ').skip(1).next();
s.splitn(2, ' ').next_tuple(); // from itertools
// as well as `unwrap()` and `?` forms
```
Still to do:
```rust
let mut iter = s.splitn(2, ' ');
(iter.next().unwrap(), iter.next()?)
let mut iter = s.splitn(2, ' ');
let key = iter.next().unwrap();
let value = iter.next()?;
```
Suggestions on other patterns to check for would be useful. I've done a search on github for uses of `splitn`. Still have yet to actually look through the results.
There's also the question of whether the lint shouold trigger on all uses of `splitn` with two values, or only on recognized usages. The former could have false positives where it couldn't be replaced, but I'm not sure how common that would be.
changelog: Add lint `manual_split_once`
Update lint documentation to use markdown headlines
This PR updates all lint documentation to use markdown headlines. It additionally removed the *Known problems* section for lints without any problems. I've double-checked all automatic replacements, but a second pair of eyes is definitely appreciated!
I wasn't sure when you wanted to switch to the new metadata collection tomorrow, I therefore prepared this PR today. And that's it this is a standalone PR to keep the other related PRs reviewable.
changelog: none
r? `@flip1995`
cc: #7172
Note: This should be merged with the other metadata collection related PRs.
Switch CI to new metadata collection
r? `@xFrednet`
Things we have to keep in mind:
- This removes the template files and the scripts used for deployment from the checkout. This was added in #5517. I don't think we ever needed those there. Not sure though.
- ~~As a result, we can't remove the python scripts yet. We have to wait until this hits a stable Clippy release.~~ I'll just break the next stable deploy and do it by hand once.
- This should be merged together with #7279. Me and `@xFrednet` will coordinate the switch
- ...?
I still have to try out some things:
- [x] Is it worth caching? Yes
- [x] ~~Is it worth to do a release build?~~ Nope
- [x] Does it actually work? With a few changes, yes
- [ ] ...?
changelog: Clippy now uses a lint to generate its documentation 🎉
Changes included:
- Minimum adaption to the new `lints.json` format
- Fixing filtering for the new `lints.json` format; hardcoding the
lint groups in the index
- Recreating the original doc styling for the new format
- Fixed sytax highlighting for rust,ignore code blocks
- Fixed markdown table extraction in the metadata collector and
fixed lint level output
- Adding the additional information row for lints
- Changed the website title to Clippy's lint list
- Flexing the website for mobile users
- Added (?) references for lint levels and groups
- Making deprecated lints look dead
- Removed JS code block language extraction in favor of a rust
implementation `rust-clippy#7352`
- Added the suspicious lint group to the lint list
- Remove trailing whitespaces from index.html
- Fix code highlighting
- Use default value if the docVersion is empty
Co-authored-by: Philipp Krones <hello@philkrones.com>
This updates all the deploy scripts and the deploy workflow.
The deploy workflow now runs the metadata collector to collect the lint
documentation. It also changes the files that are checked out in the
deploy workflow from master and adds an explanation why we have to do
this.
New lint: `disallowed_script_idents`
This PR implements a new lint to restrict locales that can be used in the code,
as proposed in #7376.
Current concerns / unresolved questions:
- ~~Mixed usage of `script` (as a Unicode term) and `locale` (as something that is easier to understand for the broad audience). I'm not sure whether these terms are fully interchangeable and whether in the current form it is more confusing than helpful.~~ `script` is now used everywhere.
- ~~Having to mostly copy-paste `AllowedScript`. Probably it's not a big problem, as the list of scripts is standardized and is unlikely to change, and even if we'd stick to the `unicode_script::Script`, we'll still have to implement custom deserialization, and I don't think that it will be shorter in terms of the amount of LoC.~~ `unicode::Script` is used together with a filtering deserialize function.
- Should we stick to the list of "recommended scripts" from [UAX #31](http://www.unicode.org/reports/tr31/#Table_Recommended_Scripts) in the configuration?
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: ``[`disallowed_script_idents`]``
r? `@Manishearth`
Add macro_braces lint to check for irregular brace use in certain macros
The name is a bit long but this sounds good as `#[allow(unconventional_macro_braces)]` and it seems more clear that we are talking about the macro call not macro definitions, any feedback let me know. Thanks!
fixes#7278
changelog: Add ``[`unconventional_macro_braces`]`` lint that checks for uncommon brace usage with macros.
Rename unconventional -> nonstandard, add config field
Add standard_macro_braces fields so users can specify macro names and
brace combinations to lint for in the clippy.toml file.
Fix errors caused by nonstandard_macro_braces in other lint tests
Fix users ability to override the default nonstandard macro braces
Add type position macros impl `check_ty`
Add disallowed_type lint, this adds a field to the conf struct
Fixes#7277
changelog: Add ``[`disallowed_type`]`` a lint that can enforce banning types specified in the config.
StructField -> FieldDef ("field definition")
Field -> ExprField ("expression field", not "field expression")
FieldPat -> PatField ("pattern field", not "field pattern")
Also rename visiting and other methods working on them.
