Fixesrust-lang/rust-clippy#5955
I understand that there's a feature freeze right now. I had started
working on this before I was aware of the feature freeze. I don't mind
waiting as long as I need to for feedback.
changelog: [`same_length_and_capacity`]: adds a new lint that checks for
usages of `from_raw_parts` where the same expression is passed for the
length and the capacity
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_SUMMARY_START -->
### Summary Notes
-
[Feature-freeze](https://github.com/rust-lang/rust-clippy/pull/15656#issuecomment-3276620004)
by [github-actions[bot]](https://github.com/github-actions[bot])
*Managed by `@rustbot`—see
[help](https://forge.rust-lang.org/triagebot/note.html) for details*
<!-- TRIAGEBOT_SUMMARY_END -->
<!-- TRIAGEBOT_END -->
This commit is put before the one that actually introduces the lint,
since, were they put in the opposite order, the first commit wouldn't
pass dogfood
Fixesrust-lang/rust-clippy#16061.
Extend `never_loop` to also lint iterator reduction methods (e.g.
`for_each`, `try_for_each`, `fold`, `try_fold`, `reduce`, `all`, `any`)
when the closure’s body diverges (return type `!`). Add a UI test
`never_loop_iterator_reduction` to cover these cases.
Testing:
- TESTNAME=never_loop_iterator_reduction cargo uitest
changelog: [`never_loop`]: lint diverging iterator reduction closures
like `for_each` and `fold`
Externally implementable items
Supersedes https://github.com/rust-lang/rust/pull/140010
Tracking issue: https://github.com/rust-lang/rust/issues/125418
Getting started:
```rust
#![feature(eii)]
#[eii(eii1)]
pub fn decl1(x: u64)
// body optional (it's the default)
{
println!("default {x}");
}
// in another crate, maybe
#[eii1]
pub fn decl2(x: u64) {
println!("explicit {x}");
}
fn main() {
decl1(4);
}
```
- tiny perf regression, underlying issue makes multiple things in the compiler slow, not just EII, planning to solve those separately.
- No codegen_gcc support, they don't have bindings for weak symbols yet but could
- No windows support yet for weak definitions
This PR merges the implementation of EII for just llvm + not windows, doesn't yet contain like a new panic handler implementation or alloc handler. With this implementation, it would support implementing the panic handler in terms of EII already since it requires no default implementation so no weak symbols
The PR has been open in various forms for about a year now, but I feel that having some implementation merged to build upon
Overhaul filename handling for cross-compiler consistency
This PR overhauls the way we handle filenames in the compiler and `rmeta` in order to achieve achieve cross-compiler consistency (ie. having the same path no matter if the filename was created in the current compiler session or is coming from `rmeta`).
This is required as some parts of the compiler rely on consistent paths for the soundness of generated code (see rust-lang/rust#148328).
In order to achieved consistency multiple steps are being taken by this PR:
- by making `RealFileName` immutable
- by only having `SourceMap::to_real_filename` create `RealFileName`
- currently `RealFileName` can be created from any `Path` and are remapped afterwards, which creates consistency issue
- by also making `RealFileName` holds it's working directory, embeddable name and the remapped scopes
- this removes the need for a `Session`, to know the current(!) scopes and cwd, which is invalid as they may not be equal to the scopes used when creating the filename
In order for `SourceMap::to_real_filename` to know which scopes to apply `FilePathMapping` now takes the current remapping scopes to apply, which makes `FileNameDisplayPreference` and company useless and are removed.
This PR is split-up in multiple commits (unfortunately not atomic), but should help review the changes.
Unblocks https://github.com/rust-lang/rust/pull/147611
Fixes https://github.com/rust-lang/rust/issues/148328
Port `doc` attributes to new attribute API
Part of https://github.com/rust-lang/rust/issues/131229.
This PR ports the `doc` attributes to the new attribute API. However, there are things that will need to be fixed in a follow-up:
* Some part of `cfg_old.rs` are likely unused now, so they should be removed.
* Not all error/lints are emitted at the same time anymore, making them kinda less useful considering that you need to run and fix rustc/rustdoc multiple times to get through all of them.
* For coherency with the other attribute errors, I didn't modify the default output too much, meaning that we have some new messages now. I'll likely come back to that to check if the previous ones were better in a case-by-case approach.
* `doc(test(attr(...)))` is handled in a horrifying manner currently. Until we can handle it correctly with the `Attribute` system, it'll remain that thing we're all very ashamed of. 😈
* A type in rustdoc got its size increased, I'll check the impact on performance. But in any case, I plan to improve it in a follow-up so should be "ok".
* Because of error reporting, some fields of `Doc` are suboptimal, like `inline` which instead of being an `Option` is a `ThinVec` because we report the error later on. Part of the things I'm not super happy about but can be postponed to future me.
* In `src/librustdoc/clean/cfg.rs`, the `pub(crate) fn parse(cfg: &MetaItemInner) -> Result<Cfg, InvalidCfgError> {` function should be removed once `cfg_trace` has been ported to new `cfg` API.
* Size of type `DocFragment` went from 32 to 48. Would be nice to get it back to 32.
* ``malformed `doc` attribute input`` wasn't meant for so many candidates, should be improved.
* See how many of the checks in `check_attr` we can move to attribute parsing
* Port target checking to be in the attribute parser completely
* Fix target checking for `doc(alias)` on fields & patterns
And finally, once this PR is merged, I plan to finally stabilize `doc_cfg` feature. :)
cc `@jdonszelmann`
r? `@JonathanBrouwer`
Currently the `sugg` utility treats all `ExprKind::Match` expressions as
potentially needing brackets, and therefore many lints will add
parenthesis around them. However this includes desugared match
expressions like the `?` and `.await` operators.
In this PR I have updated the utility to only treat match expressions
which include a code block as needing parenthesis, as the other types
have similar precedence rules and expectations to things like member
access and I think can be treated like as such.
While this change is small on paper it touches a large amount of code
due to changing a cross cutting concern, I am happy to add additional
tests if we think it is needed, but I wanted to get a feel for if this
is even a sensible change to be doing and what the expectations were
around the level of testing needed before investing more time into it.
Regarding not putting a specific lint in the changelog, determining all
the lints this could possibly effect would be possible but take some
time, and I wonder if it would be a bit too noisy in the changelog. Open
to suggestions about how best to address that.
fixesrust-lang/rust-clippy#16045
changelog: stop inserting unnecessary brackets around `x?` and `x.await`
expressions in suggestions
Inherent const impl
Some constifications are annoying because we need to repeat `T: Trait` bounds from an impl block on the individual constified `const fn`s as `T: [const] Trait`. We've brainstormed solutions before, and one would be to have separate `const impl` blocks or sth. However the final syntax will look, I decided to just impl this syntax and either have sth nice on nightly to work with or at least move the discussion along.
Also interacts with the discussion around `impl const Trait for Type` vs `const impl Trait for Type`, as we may want to use the latter to keep inherent and trait impls in sync (unless we come up with even another scheme).
* [ ] rustdoc + tests
* [ ] macro stability /regression tests
r? `@fee1-dead`
cc `@traviscross` `@rust-lang/project-const-traits`
- move `is_allowed_vec_method` (a stripped-down version of it, anyway,
as the function doesn't make sense as is out of context) to utils, as
it's shared between `useless_vec` and `ptr_arg`
- add another test for non-standard macro brace case
- rm unneeded `allow`s
- rm duplicated tests
- add comments to some tests
Jason Newcomb