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?
pin a version of serde without intransparent unreproducible binary blobs
Serde is [shipping a binary blob in its derive crate](https://github.com/serde-rs/serde/issues/2538), which is highly unexpected and subverts user trust. To make matters worse, the binary is [not even reproducible](https://github.com/serde-rs/serde/issues/2575), making the crate largely unauditable and relinquishing the security benefits of open-source software. Build times are not nearly painful enough to justify forcing users to trust binary blobs.
coverage: Give the instrumentor its own counter type, separate from MIR
Within the MIR representation of coverage data, `CoverageKind` is an important part of `StatementKind::Coverage`, but the `InstrumentCoverage` pass also uses it heavily as an internal data structure. This means that any change to `CoverageKind` also needs to update all of the internal parts of `InstrumentCoverage` that manipulate it directly, making the MIR representation difficult to modify.
---
This change fixes that by giving the instrumentor its own `BcbCounter` type for internal use, which is then converted to a `CoverageKind` when injecting coverage information into MIR.
The main change is mostly mechanical, because the initial `BcbCounter` is drop-in compatible with `CoverageKind`, minus the unnecessary `CoverageKind::Unreachable` variant.
I've then removed the `function_source_hash` field from `BcbCounter::Counter`, as a small example of how the two types can now usefully differ from each other. Every counter in a MIR-level function should have the same source hash, so we can supply the hash during the conversion to `CoverageKind::Counter` instead.
---
*Background:* BCB stands for “basic coverage block”, which is a node in the simplified control-flow graph used by coverage instrumentation. The instrumentor pass uses the function's actual MIR control-flow graph to build a simplified BCB graph, then assigns coverage counters and counter expressions to various nodes/edges in that simplified graph, and then finally injects corresponding coverage information into the underlying MIR.
Fix a stack overflow with long else if chains
This fixes stack overflows when running the `issue-74564-if-expr-stack-overflow.rs` test with the parallel compiler.
Add MIR validation for unwind out from nounwind functions + fixes to make validation pass
`@Nilstrieb` This is the MIR validation you asked in https://github.com/rust-lang/rust/pull/112403#discussion_r1222739722.
Two passes need to be fixed to get the validation to pass:
* `RemoveNoopLandingPads` currently unconditionally introduce a resume block (even there is none to begin with!), changed to not do that
* Generator state transform introduces a `assert` which may unwind, and its drop elaboration also introduces many new `UnwindAction`s, so in this case run the AbortUnwindingCalls after the transformation.
I believe this PR should also fixRust-for-Linux/linux#1016, cc `@ojeda`
r? `@Nilstrieb`
