Change how edition based future compatibility warnings are handled
This fixes https://github.com/rust-lang/rust/issues/85894 by updating how future compatibility lints work. This makes it more apparent that future compatibility warnings can happen for several different reasons.
For now `FutureCompatibilityReasons` are limited to three reasons, but we can easily add more.
This also updates the generated warning for FCW's that signal code that will error in a future edition. This makes the diagnostics between FCWs at edition boundaries more distinct from those not happening at an edition boundary.
r? ``@m-ou-se``
Use https for sourceforge during CI
I saw that we use http during CI opening up the CI process to on the wire tampering.
based on #86573
r? `@pietroalbini`
Do not spawn blacklisted_name lint in test context
---
fixed#7305
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: `blacklisted_name` lint is not spawned in the test context anymore.
Fix detecting of the 'test' attribute
Update UI test to actually check that warning is not triggered in the test code
Fix approach for detecting the test module
Add nested test case
Remove code duplication by extracting 'is_test_module_or_function' into 'clippy_utils'
Cleanup the code
Added `cargo dev setup git-hook` and updated `cargo dev setup intellij` including a `remove` command
This PR enables our dev tool to install a git hook that formats the code before each commit and also runs `update_lints` to make sure that everything is registered correctly. The script is located at `util/etc/pre-commit.sh`. I found it reasonable to locate it in the `util` folder and decided to add a `etc` in correlation to the main rust repo and to bring a bit of structure into it.
* The hook can be installed via: `cargo dev setup git-hook`
* And removed via: `cargo dev remove git-hook`
cc: #5394
The refactoring of `src/ide_setup.rs` to `src/setup/intellij.rs` is an extra commit to simplify the review.
---
Changes:
* Added `cargo dev setup git-hook` for formatting before every commit
* Added `cargo dev remove git-hook` to remove the hook again
* Added `cargo dev remove intellij` to remove rustc source path dependencies
* Changed `cargo dev ide_setup` to `cargo dev setup intellij`
changelog: none
This is only an internal change and therefore not worth an entry in the general change log.
---
Tested on:
* [x] Linux (by `@xFrednet)`
* [ ] Windows (All used commands run inside the git bash, so it's very likely to work as well `@xFrednet)`
* [ ] macOS
rustc_data_structures has a dependency on crossbeam-utils but never uses
it. It appears to have originally had this dependency in order to set
the "nightly" feature; however, its other dependencies use a different
version of crossbeam-utils, so this doesn't actually affect anything.
Furthermore, in current crossbeam-utils, the "nightly" feature has
become a no-op.
The sha-1 and md-5 packages contain crates named sha1 and md5,
respectively. This discrepancy makes it somewhat more challenging to
automate detection of unused crates. Explicitly rename the packages to
the names of the crates they contain, to simplify such detection.
Add `BuildHasher::hash_one` as unstable
Inspired by https://github.com/rust-lang/rust/pull/86140/files#diff-246941135168fbc44fce120385ee9c3156e08a1c3e2697985b56dcb8d728eedeR2416, where I wanted to write a quick test for a `Hash` implementation and it took more of a dance than I'd hoped.
It looks like this would be handy in hashtable implementations, too -- a quick look at hashbrown found two places where it needs to do the same dance:
6302512a8a/src/map.rs (L247-L270)
I wanted to get a "seems plausible" from a libs member before making a tracking issue, so random-sampling the intersection of highfive and governance gave me...
r? `@joshtriplett`
(As always, bikeshed away! And let me know if I missed something obvious again that I should have used instead.)
