scip: Generate symbols for local crates.
Consider something like:
```
// a.rs
pub struct Foo { .. } // Foo is "local 1"
fn something() {
crate:🅱️:Bar::new() // Bar is "local 1", but of "b.rs"
}
// b.rs
pub struct Bar { .. } // "local 1"
```
Without this there's no way to disambiguate whether "local 1" references "Bar" or "Foo".
Fixed consistency of Apple simulator target's ABI
Currently there's a few Apple device simulator targets that are inconsistent since some set `target_abi = "sim"` (the correct thing to do) while a bunch of others don't set anything (`""`). Due to this its very hard to reliability check if some Rust code is running inside a simulator. This changes all of them to do the same thing and set `sim` as their `target_abi`.
The new way to identity a simulator during compilation is as simple as `cfg(all(target_vendor="apple", target_abi = "sim"))` or even `cfg(target_abi = "sim")` being less pedantic about it.
The issues with the current form (and inspiration for this) are also summarized in `@thomcc's` [Tweet](https://twitter.com/at_tcsc/status/1576685244702691328).
feat: add config for inserting must_use in `generate_enum_as_method`
Should fix#13312
Didn't add a test because I was not sure on how to add test for a specific configuration option, tried to look for the usages for other `AssistConfig` variants but couldn't find any in `tests`. If there is a way to test this, do point me towards it.
I tried to extract the formatting string as a common `template_string` and only have if-else for that, but it didn't compile :(
Also it seems these tests are failing:
```
test config::tests::generate_config_documentation ... FAILED
test config::tests::generate_package_json_config ... FAILED
```
Can you also point me to how to correct these 😅 ( I guess there is some command to automatically generate these? )
fix: make custom expr prefix completions to understand refs
Possible fix of #7929
While reviewing the postfix completion code I saw that while calling `add_custom_postfix_completions` we were doing it under the part where reference was not taken into consideration, but as we are only adding postfix completions with `Expr` scope ( [source](ba28e19b78/crates/ide-completion/src/completions/postfix.rs (L272)) )
I shifted the `add_custom_postfix_completions` call to part where references are considered
I am not sure if this is the correct fix or I am understanding the problem exactly but this small move seemed to have fixed the issue :)
rustdoc: Do not add external traits to the crate in `register_res`
It's not clear why it was done, and apparently it's no longer necessary now.
Such additions are unpredictable for early doc link resolution and would force us to collect all doc links from all external traits.
Fixes https://github.com/rust-lang/rust/issues/103463
Track where diagnostics were created.
This implements the `-Ztrack-diagnostics` flag, which uses `#[track_caller]` to track where diagnostics are created. It is meant as a debugging tool much like `-Ztreat-err-as-bug`.
For example, the following code...
```rust
struct A;
struct B;
fn main(){
let _: A = B;
}
```
...now emits the following error message:
```
error[E0308]: mismatched types
--> src\main.rs:5:16
|
5 | let _: A = B;
| - ^ expected struct `A`, found struct `B`
| |
| expected due to this
-Ztrack-diagnostics: created at compiler\rustc_infer\src\infer\error_reporting\mod.rs:2275:31
```
feat: show signature help when calling generic types implementing `FnOnce`
This queries chalk for the `FnOnce` impl of callees and takes argument and return types from there, making generic `Callable`s available to the IDE. This makes signature help work for them, and potentially allows other features to take generic callables into account in the future.
fix: disregard type variable expectation for if expressions
Fixes#13522
As [the comment](8142d1f606/crates/hir-ty/src/infer.rs (L1087-L1090)) on `Expectation::adjust_for_branches` explains:
> If the expected type is just a type variable, then don't use an expected type. Otherwise, we might write parts of the type when checking the 'then' block which are incompatible with the 'else' branch.
Note that we already use it in match expressions. I've added tests for them too nevertheless.
fix) update broken links in guide.md
Hi, I Just fixed some broken links in `guide.md`.
In most cases, it is not connected by an old version (expecially `guide-2019-01`) of the link, so I made some modifications.
Thanks for your time :)
Don't use usub.with.overflow intrinsic
The canonical form of a usub.with.overflow check in LLVM are separate sub + icmp instructions, rather than a usub.with.overflow intrinsic. Using usub.with.overflow will generally result in worse optimization potential.
The backend will attempt to form usub.with.overflow when it comes to actual instruction selection. This is not fully reliable, but I believe this is a better tradeoff than using the intrinsic in IR.
Fixes#103285.
ci: Bring back ninja for dist builders
The primary reason for this is that make can result in a substantial under utilization of parallelism (noticed while testing on a workstation), mostly due to the submake structure preventing good dependency tracking and scheduling.
In f758c7b2a78 (Debian 6 doesn't have ninja, so use make for the dist builds) llvm.ninja was disabled due to lack of distro package. This is no longer the case with the CentOS 7 base, so bring ninja back for a performance boost.
Clean up tests and add documentation for GATs related stuff
This is a follow-up PR for #13494.
- addresses https://github.com/rust-lang/rust-analyzer/pull/13494#discussion_r1006774897
- documents the ordering constraint on `Binders` and `Substitution` (which is not really follow-up for the previous PR, but it was introduced to support GATs and I strongly feel it's worth it)
Introduce UnordMap, UnordSet, and UnordBag (MCP 533)
This is the start of implementing [MCP 533](https://github.com/rust-lang/compiler-team/issues/533).
I followed `@eddyb's` suggestion of naming the collection types `Unord(Map/Set/Bag)` which is a bit easier to type than `Unordered(Map/Set/Bag)`
r? `@eddyb`
privacy: Rename "accessibility levels" to "effective visibilities"
And a couple of other naming and comment tweaks.
Related to https://github.com/rust-lang/rust/issues/48054
For `enum Level` I initially used naming `enum EffectiveVisibilityLevel`, but it was too long and inconvenient because it's used pretty often.
So I shortened it to just `Level`, if it needs to be used from some context where this name would be ambiguous, then it can be imported with renaming like `use rustc_middle::privacy::Level as EffVisLevel` or something.
poll_fn and Unpin: fix pinning
See [IRLO](https://internals.rust-lang.org/t/surprising-soundness-trouble-around-pollfn/17484) for details: currently `poll_fn` is very subtle to use, since it does not pin the closure, so creating a `Pin::get_unchcked(&mut capture)` inside the closure is unsound. This leads to actual miscompilations with `futures::join!`.
IMO the proper fix is to pin the closure when the future is pinned, which is achieved by changing the `Unpin` implementation. This is a breaking change though. 1.64.0 was *just* released, so maybe this is still okay?
The alternative would be to add some strong comments to the docs saying that closure captures are *not pinned* and doing `Pin::get_unchecked` on them is unsound.
