Sered no longer uses blobs as of
https://github.com/serde-rs/serde/pull/2590
As such, there's no longer need for us to pin it.
Note that this doesn't upgrade serde version we use: I am fairly
confident that the blobs are already there are fine, and now I am fairly
confident that all future versions of serde will be fine as well.
Add projection obligations when comparing impl too
Fixes#115033
In the test, when we ask for WF obligations of `DatasetIter<'a, ArrayBase<D>>`, we get back two important obligations: `[<D as Data>::Elem -> ?1, ?1: 'a]`. If we don't add the projection obligation, `?1` remains unconstrained.
An alternative solution would be to use unnormalized obligations, where we only have one relevant obligation: `<D as Data>::Elem: 'a`. This would leave no inference vars unconstrained.
fix help text for rust-analyzer.check.invocation{Strategy,Location}
I highly doubt that `check.invocationLocation` only has an effect if `cargo.buildScripts.overrideCommand` is set -- looks like a copy-paste mistake from `buildScripts.invocationLocation` to me.
feat: Implement extern crate completion
Hi, this is a draft PR for #13002.
I have basic completion working as well as a filter for existing extern crate imports in the same file. This is based on the tests, I have not actually tried this in an editor. Before going further I think this is a good point to stop and get feedback on the
structure and approach I have taken so far. Let me know what you think :)
I will make sure to add more tests, rebase commits and align with the code style guidelines before submitting a final version.
A few specific questions :
1. Is there a better way to check for matching suggestions? right now I just test if an extern crate name starts with the current
user input.
2. Am I creating the `CompletionItem` correctly? I noticed that `use_.rs` invokes a builder where as I do not.
3. When checking for existing extern crate imports the current implementation only looks at the current source file, is that sufficient?
Remove apple-alt dist build.
This removes the dist-x86_64-apple-alt build to reduce CI usage because I suspect nobody is using it. This builder is almost identical to the `dist-x86_64-apple` with the small difference that the latter adds `rust.lto=thin`, and I do not think that difference was intentional. The reason they are identical is because llvm assertions were disabled in #44610, but I did not see any discussion about the consequence that this made the alt build identical to the normal build. Perhaps because #44610 was intended to be temporary?
fix: avoid problematic serde release
serde 1.0.172 and up rely on opaque non-reproducible binary blobs to function, explicitly not providing a library-level opt-out.
This is problematic for two reasons:
- directly, unauditable binary blobs are a security issue.
- indirectly, it becomes much harder to predict future behaviors of the crate.
As such, I am willing to go on a limb here and forbid building rust-analyzer with those versions of serde. Normally, my philosophy is to defer the choice to the end user, but it's also a design constraint of rust-analyzer that we don't run random binaries downloaded from the internet without explicit user's concent.
Concretely, this upper-bounds serde for both rust-analyzer workspace, as well as the lsp-server lib.
See https://github.com/serde-rs/serde/issues/2538 for wider context.
serde 1.0.172 and up rely on opaque non-reproducible binary blobs to
function, explicitly not providing a library-level opt-out.
This is problematic for two reasons:
- directly, unauditable binary blobs are a security issue.
- indirectly, it becomes much harder to predict future behaviors of the
crate.
As such, I am willing to go on a limb here and forbid building
rust-analyzer with those versions of serde. Normally, my philosophy is
to defer the choice to the end user, but it's also a design constraint
of rust-analyzer that we don't run random binaries downloaded from the
internet without explicit user's concent.
Concretely, this upper-bounds serde for both rust-analyzer workspace, as
well as the lsp-server lib.
See https://github.com/serde-rs/serde/issues/2538 for wider context.
Synchronize with all calls to `unpark` in id-based thread parker
[The documentation for `thread::park`](https://doc.rust-lang.org/nightly/std/thread/fn.park.html#memory-ordering) guarantees that "park synchronizes-with all prior unpark operations". In the id-based thread parking implementation, this is not implemented correctly, as the state variable is reset with a simple store, so there will not be a *synchronizes-with* edge if an `unpark` happens just before the reset. This PR corrects this, replacing the load-check-reset sequence with a single `compare_exchange`.
minor : Deunwrap generate_derive
#15398 subtask 1. Since the editing closure has arms, I did something *experimental* ( in this case just a clever term for bad code ) to bypass creating an `Option` but I am ready to change this.
Replace the \01__gnu_mcount_nc to LLVM intrinsic for ARM
Current `-Zinstrument-mcount` for ARM32 use the `\01__gnu_mcount_nc` directly for its instrumentation function.
However, the LLVM does not use this mcount function directly, but it wraps it to intrinsic, `llvm.arm.gnu.eabi.mcount` and the transform pass also only handle the intrinsic.
As a result, current `-Zinstrument-mcount` not work on ARM32. Refer: https://github.com/namhyung/uftrace/issues/1764
This commit replaces the mcount name from native function to the LLVM intrinsic so that the transform pass can handle it.
Speed up compilation of `type-system-chess`
[`type-system-chess`](https://github.com/rust-lang/rustc-perf/pull/1680) is an unusual program that implements a compile-time chess position solver in the trait system(!) This PR is about making it compile faster.
r? `@ghost`
internal: Record import origins in ItemScope and PerNS
This records the import items definitions come from in the module scope (as well as what an import resolves to in an ItemScope). It does ignore glob imports as thats a lot more work for little to no gain, glob imports act as if the importing items are "inlined" into the scope which suffices for almost all use cases I believe (to my knowledge, attributes on them have little effect).
There is still a lot of work needed to make this available to the IDE layer, but this lays out the ground work for havin IDE layer support.
cc https://github.com/rust-lang/rust-analyzer/issues/14079
avoid transmuting Box when we can just cast raw pointers instead
Always better to avoid a transmute, in particular when the layout assumptions it is making are not clearly documented. :)
Avoid unnecessary Vec resize.
If `size > 0` current implementation will first create an empty vec and then push an element into it, which will cause a resize that can be easily avoided.
It's obviously not a big deal, but this also gets rid of `mut` local variable.
Fix argument removal suggestion around macros
Fixes#112437.
Fixes#113866.
Helps with #114255.
The issue was that `span.find_ancestor_inside(outer)` could previously return a span with a different expansion context from `outer`.
This happens for example for the built-in macro `panic!`, which expands to another macro call of `panic_2021!` or `panic_2015!`. Because the call site of `panic_20xx!` has not associated source code, its span currently points to the call site of `panic!` instead.
Something similar also happens items that get desugared in AST->HIR lowering. For example, `for` loops get two spans: One "inner" span that has the `.desugaring_kind()` kind set to `DesugaringKind::ForLoop` and one "outer" span that does not. Similar to the macro situation, both of these spans point to the same source code, but have different expansion contexts.
This causes problems, because joining two spans with different expansion contexts will usually[^1] not actually join them together to avoid creating "spaghetti" spans that go from the macro definition to the macro call. For example, in the following snippet `full_span` might not actually contain the `adjusted_start` and `adjusted_end`. This caused the broken suggestion / debug ICE in the linked issues.
```rust
let adjusted_start = start.find_ancestor_inside(shared_ancestor);
let adjusted_end = end.find_ancestor_inside(shared_ancestor);
let full_span = adjusted_start.to(adjusted_end)
```
To fix the issue, this PR introduces a new method, `find_ancestor_inside_same_ctxt`, which combines the functionality of `find_ancestor_inside` and `find_ancestor_in_same_ctxt`: It finds an ancestor span that is contained within the parent *and* has the same syntax context, and is therefore safe to extend. This new method should probably be used everywhere, where the returned span is extended, but for now it is just used for the argument removal suggestion.
Additionally, this PR fixes a second issue where the function call itself is inside a macro but the arguments come from outside the macro. The test is added in the first commit to include stderr diff, so this is best reviewed commit by commit.
[^1]: If one expansion context is the root context and the other is not.
internal: Add offset param to token descending API
The offset is unused for now as we can't map by spans yet but it will be required for https://github.com/rust-lang/rust-analyzer/issues/11260 to work once the token map has been changed to record spans
When reporting a heap use-after-free, say where the allocation was allocated and deallocated
This is a partial solution to: https://github.com/rust-lang/miri/issues/2917
Currently in the interpreter, we only have accurate information for where heap allocations are allocated and deallocated (see https://github.com/rust-lang/miri/pull/2940#discussion_r1243559711). So this just implements support for allocations where the information is already available, and the full support will require more interpreter tweaks.
