Add categories to Cargo.toml

[shepmaster]

Hi! crates.io now supports categories, which are a curated list
of topics aimed at helping an end-user coming to crates.io looking for
"a crate to do ______".

We're sending pull requests to selected crates to add categories in order to help
populate the categories and seed their usefulness. We've made a guess at the best
category/categories for this crate; if it doesn't fit, please feel free to take
a look at all the available categories and their descriptions and
the slug values that should be specified in your Cargo.toml and pick
different ones. If you have a category in mind that isn't available, you can
send a PR to this file on crates.io to propose additional
categories.

Crates can have up to 5 categories, and uploading categories to crates.io
currently requires publishing a new version with a cargo nightly from 2017-01-18
or later (it needs to contain this PR).

We've published a blog post with further details about categories.
The blog post also talks about the new crates.io support for CI badges, which
you may be interested in adding as well.

Please let me know if you have any questions!

[mcarton]

@shepmaster Thanks!

---

@oli-obk why do I get different behavior of cargo fmt on travis and locally? Fresh install of rustfmt

% cargo fmt -- --version
0.7.1 ()

It wants

-use utils::{is_adjusted, match_path, match_trait_method, match_type, remove_blocks, paths, snippet, span_help_and_lint,
-            walk_ptrs_ty, walk_ptrs_ty_depth, iter_input_pats};
+use utils::{is_adjusted, match_path, match_trait_method, match_type, remove_blocks, paths, snippet,
+            span_help_and_lint, walk_ptrs_ty, walk_ptrs_ty_depth, iter_input_pats};

on travis, but does the opposite locally!

[mcarton]

@shepmaster by the way, why what it chosen to have to explicitly specify both repos for badges, while most Cargo.toml already have package.repository from which that could be inferred?

[oli-obk]

@mcarton you need to update our rustfmt, most likely by clearing the travis caches

[mcarton]

🎉 https://crates.io/categories/development-tools

And now I realize it should also be in the development-tools::cargo-plugins subcategory, and maybe development-tools::testing too?

[shepmaster]

development-tools::cargo-plugins

That makes sense for cargo-clippy, I'd think, not just clippy.

maybe development-tools::testing

As maintainers, you have the ultimate decision, but my brain says that linting and testing are separate things. (shrug)

[Manishearth]

That makes sense for cargo-clippy, I'd think, not just clippy.

They're the same package. You can install it as a bin or use it as a lib.

Might want to change the description of ::testing there, currently says "Crates to help you verify the correctness of your code." which does sort of apply to what we do here.

[mcarton]

maybe development-tools::testing

As maintainers, you have the ultimate decision, but my brain says that linting and testing are separate things. (shrug)

We fit the description “Crates to help you verify the correctness of your code.” if not the name 😄, that's why I asked other people's opinion.

[shepmaster]

why what it chosen to have to explicitly specify both repos for badges, while most Cargo.toml already have package.repository from which that could be inferred?

I'm not 100% sure which specific inference you mean...

We could have attempted to parse the URL of the repository field, but then we have to deal with various code hosting services (and although unlikely, deal with changes to those URLs) and then we'd still have to have a fallback option for "no, you guessed wrong". On top of that, we'd still have to have a way of specifying that you wish to include the badge or not.

However, I believe that what is there now is backwards-compatible with what you are suggesting, so if an industrious soul adds it, we can just make required fields non-required in the future.

[shepmaster]

They're the same package. You can install it as a bin or use it as a lib.

TIL! If that's the case, then that makes sense to me!

Crates to help you verify the correctness of your code

Hmm. good point! Since there are lints that are deny by default, which is a strong indicator of "this is totally wrong and you should not do it" (e.g. out_of_bounds_indexing), I can see your case here!