Suggest blanket impl to the local traits
This PR will add additional suggestion regarding the blanket implementation when it is possible, by generation a new help message + suggestion.
Closes https://github.com/rust-lang/rust/issues/96076
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Rewrite dead-code pass to avoid fetching HIR.
This allows to get a more uniform handling of spans, and to simplify the grouping of diagnostics for variants and fields.
The existing derive code allows for various possibilities that aren't
needed in practice, which complicates the code. There are only a few
auto-derived traits and new ones are unlikely, so this commit simplifies
things.
- `PtrTy` has been eliminated. The `Raw` variant was never used, and the
lifetime for the `Borrowed` variant was always `None`. That left just
the mutability field, which has been inlined as necessary.
- `MethodDef::explicit_self` was a confusing `Option<Option<PtrTy>>`.
Indicating either `&self` or nothing. It's now a `bool`.
- `borrowed_self` is renamed as `self_ref`.
- `Ty::Ptr` is renamed to `Ty::Ref`.
Add a `--build-dir` flag to rustbuild
This adds an optional `--build-dir <path>` flag to rustbuild (to both the python and rust code in src/bootstrap). If provided, it overrides build directory from the config file (if any was provided).
My reason for wanting this is that I often will make a change, save, and then go run `x.py check` or `x.py test` (or something). Because I've saved, vscode will start doing its thing in the background, but this will take the file lock, preventing `x.py` from running until vscode finishes whatever it's doing (since the manually invoked x.py won't be able to acquire said file lock). This is annoying, because I'd rather the command I explicitly invoke *not* wait for r-a to complete, as r-a's check is conceptually a background task (and one which can take quite some time to complete).
Anyway, while there are likely other ways this could be handled, if you have the disk space an easy way is to just have vscode be configured to use a different build directory, and then they never have to block each-other.
This can currently be arranged without this patch, by maintaining two `config.toml`s, one of which has a different build dir, and just exists to be passed into the overridden check command in vscode.
Unfortunately, this has the downside of requiring I maintain two `config.toml`s and keep them (at least somewhat) in sync, aside from the build dir. I dislike for several reasons, not the least of which because I know myself well enough to know that these will inevitably get out of sync and confuse me in the future (perhaps this case would be different since I've thought about it enough to write this patch? Who knows, I'd rather not find out).
Either way, it would be much easier for me to have a way for *only* the build directory to differ, which this patch provides by way of a new flag. I suggested this to `@jyn514` who indicated it sounded reasonable so long as it didn't add too much complexity, which I think I've achieved, but he can be the judge.
Anyway, with this patch I can just use something like `["python3", "x.py", "check", "--build-dir", "build-vscode", "--json-output"]` as the overridden check command to rust-analyzer, and do not need to futz with any additional `config.toml`s. Which is very nice!
I've tested this manually, and can confirm that it works. I'm not sure if it needs automated tests, or where I should add them if so.
r? `@jyn514` (who has had to put up with my complaints about this... many times. <3)
Update RELEASES.md
Clarify that flow sensitive checks now understand that *visibly*
uninhabited call expressions never return.
The change influences checks of reachable and unreachable code alike,
not just dead code like previous wording would imply.
cc ``@Kixunil``
Let rust-analyzer ship on stable, non-preview
The consensus on rust-lang/rust-analyzer#12432 seems to be that we are ready for `rust-analyzer` to ship as a rustup component on the beta and stable channels. This won't always be the preferred distribution method, e.g. the VS Code extension will probably still independently update to its weekly releases, but it's still useful to have a component that follows the release train with the rest of the Rust toolchain. So this removes the nightly-only gating on the bundled component, and removes the "-preview" suffix as well by the usual renaming mechanism.
cc ``@rust-lang/wg-rls-2`` ``@rust-lang/release``
By skipping the call to `copy` with a zero length. This makes it closer
to `push`.
I did this recently for `SmallVec`
(https://github.com/servo/rust-smallvec/pull/282) and it was a big perf win in
one case. Although I don't have a specific use case in mind, it seems
worth doing it for `Vec` as well.
Things to note:
- In the `index < len` case, the number of conditions checked is
unchanged.
- In the `index == len` case, the number of conditions checked increases
by one, but the more expensive zero-length copy is avoided.
- In the `index > len` case the code now reserves space for the extra
element before panicking. This seems like an unimportant change.
The `&[ast::Variant]` field isn't used.
The `Vec<Ident>` field is only used for its length, but that's always
the same as the length of the `&[Ident]` and so isn't necessary.
This created unexpected diagnostics while compiling alga:
cannot satisfy `<Self as Module>::Ring == _`
Turns out that we don't need this diagnostic as we disable inlining when
it would trigger an ICE.
Const eval no longer runs MIR optimizations so unless this is getting
run as part of a MIR optimization like const-prop, there can be unused
type parameters even if polymorphization is enabled.
get rid of tidy 'unnecessarily ignored' warnings
I think these warnings are quite pointless: when I say `allow(foo)` in my code, that doesn't necessarily mean that I expect `foo` to happen -- it just means that I am okay with `foo` happening.
For example, having to add and remove `ignore-tidy-linelength` as the longest line in the file keeps growing and shrinking is just annoying and doesn't benefit anyone, IMO. This usually incurs *two* CI roundtrips: first CI tells you that line lengths in your test file are ignored unnecessarily, so you go and remove that attribute; then CI tells you that now your line numbers changed, so you re-bless your tests (often takes >5min if parts of rustc need rebuilding because `./x.py fmt` changed something somewhere). That's just a lot of wasted effort and time and patience.
Remove unneeded methods declaration for old web browsers
All these methods were not defined for IE mostly. But since we don't support it anymore, no need to keep them around.
cc ```@jsha```
r? ```@notriddle```
