cleanup: remove zero-offset GEP
This GEP would've been used to change the pointer type in the past, but after opaque pointers it's a no-op. I missed removing this in #105545.
Split out from #121577.
Fix linting paths with qself in `unused_qualifications`
Fixes#121999
`resolve_qpath` ends up being called again with `qself` set to `None` to check trait items from fully qualified paths. To avoid this the lint is moved to a place that accounts for this already
96561a8fd1/compiler/rustc_resolve/src/late.rs (L4074-L4088)
r? `````@petrochenkov`````
Removing absolute path in proc-macro
With rust 1.75 the absolute build path name is embedding into proc-macro (.rustc section) and which causes reproducibility issues.
Detailed issue description is here - https://github.com/rust-lang/rust/issues/120825#issuecomment-1964307219
With this change the 'absolute path' changed back to '/rust/$hash' format as in earlier revisions.
Rework `untranslatable_diagnostic` lint
Currently it only checks calls to functions marked with `#[rustc_lint_diagnostics]`. This PR changes it to check calls to any function with an `impl Into<{D,Subd}iagnosticMessage>` parameter. This greatly improves its coverage and doesn't rely on people remembering to add `#[rustc_lint_diagnostics]`. It also lets us add `#[rustc_lint_diagnostics]` to a number of functions that don't have an `impl Into<{D,Subd}iagnosticMessage>`, such as `Diag::span`.
r? ``@davidtwco``
This commit adds the said relation by keeping a map of type `FxHashMap<SourceRootId,Option<SourceRootId>>`
inside the `GlobalState`. Its primary use case is reading the rust-analyzer.toml files that can be
placed under every local source root. As a config will be found by traversing this "tree" we need the parent information
for every local source root. This commit omits defining this relation for library source roots entirely.
fix: panic when using float numbers without dots in chain calls
Fix#16278.
This PR fixes the panic caused by using floating-point numbers without a dot (such as `1e2`) in chain calls.
-------------
Although this syntax is very odd 🤣, r-a should not panic.
stricter hidden type wf-check [based on #115008]
Original work by `@aliemjay` in #115008. A huge thanks to them for originally figuring out this approach ❤️
Fixes https://github.com/rust-lang/rust/issues/114728
Fixes https://github.com/rust-lang/rust/issues/114572
Instead of adding the `WellFormed` obligations when relating opaque types, we now always emit such an obligation when defining the hidden type.
This causes nested opaque types which aren't wf to error, see the comment below for the described impact. I believe this change to be desirable as it significantly reduces complexity by removing special-cases.
It also caused an issue with RPITIT: in defaulted trait methods, we add a `Projection(synthetic_assoc, rpit_of_trait_method)` clause to the `param_env`. This clause is not added to the `ParamEnv` of the nested coroutines. This caused a normalization failure in `fn check_coroutine_obligations` with the new solver. I fixed that by using the env of the typeck root instead.
r? `@oli-obk`
fix: keep attributes in assist 'generate_delegate_trait'
fix#15198.
This PR address the issue that `impl` generated by `generate_delegate_trait` doesn't keep attributes.
Embed length of offset/position into Span tag byte
This cuts the average bytes/relative span from 3.5 to 3.2 on libcore, ultimately saving ~400kb of data.
Add test explorer
This PR implements the vscode testing api similar to #14589, this time using a set of lsp extensions in order to make it useful for clients other than vscode, and make the vscode client side logic simpler (its now around ~100 line of TS code)
Fix#3601
net: Don't use checked arithmetic when parsing numbers with known max digits
Add a branch to `Parser::read_number` that determines whether checked or regular arithmetic is used.
- If `max_digits.is_some()`, then we know we are parsing a `u8` or `u16` because `read_number` is only called with `Some(3)` or `Some(4)`. Both types fit within a `u32` without risk of overflow. Thus, we can use plain arithmetic to avoid extra instructions from `checked_mul` and `checked_add`.
Add benches for `IpAddr`, `Ipv4Addr`, `Ipv6Addr`, `SocketAddr`, `SocketAddrV4`, and `SocketAddrV6` parsing
Add `fn index()` and `fn parent_fn()` accessors for `hir::Param`/`hir::SelfParam`
(the PR is motivated by an outside use of the `ra_ap_hir` crate that would benefit from being able to access a `hir::Param`'s/`hir::SelfParam`'s index and parent function)
fix: goto-definition for constants inside range pattern
Fix#15653.
This PR addresses the issue where it was not possible to navigate to constants in range patterns, specifically including two major changes:
1. Previously, both the `start` and `end` fields in `Pat::Range` were of type `LiteralOrConst`. When performing `goto-definition` on constants inside range patterns, r-a would use `resolve_bind_pat_to_const` to find their definitions. However, because the content of a `Const` is not `Pat` but `Path`, it was not stored in the `source_map`, so `resolve_bind_pat_to_const` would returns `None`. This PR changes them to `Const(PatId)`, so that during the lowering process, they are considered as a `pat`, allowing their definitions to be found later through `resolve_bind_pat_to_const`.
2. The process related to range patterns in MIR-lowering has been modified to correctly handle the above changes.
Add ASCII fast-path for `char::is_grapheme_extended`
I discovered that `impl Debug for str` is quite slow because it ends up doing a `unicode_data::grapheme_extend::lookup` for each char, which ends up doing a binary search.
This introduces a fast-path for ASCII chars which do not have this property.
The `lookup` is thus completely gone from profiles.
---
As a followup, maybe it’s worth implementing this fast path directly in `unicode_data` so that it can check for the lower bound directly before going to a potentially expensive binary search.
