I'm investigating issues where users see a load of logs of the form:
```
Failed to set the current working dir to /redacted/path. Error: Os { code: 2, kind: NotFound, message: "No such file or directory" }
```
This is tricky to debug because there's two different code paths that
write exactly the same error message. Ensure they're unique.
`split_numeric_suffix` used `rfind` to locate the last non-numeric
character and then split at `pos + 1`. Since `rfind` returns a byte
offset, this panics when the last non-numeric character is multi-byte
(e.g. CJK identifiers like `日本語`).
Use `str::ceil_char_boundary` to advance past the full character before
splitting.
Gate #![reexport_test_harness_main] properly
Address the FIXME
Removed from `issue-43106-gating-of-builtin-attrs.rs` since that is for stable attributes only.
This would be a breaking change, search of github shows it is mostly but not always used with `#![test_runner]` which is already gated correctly.
Details:
https://github.com/rust-lang/rust/issues/50297
Feel free to close this issue if you think it is not worth addressing the FIXME...
Currently rust-analyzer only watches the directory itself, and doesn't
consider children recursively.
This is a problem when the directory itself is deleted and
recreated (e.g. if you're creating all of `mycrate/src/` with a code
generating script). The obvious solution is to configure rust-analyzer
to watch the parent directory (assuming rust-project.json), but that
requires recursive watching.
This problem probably also occurs when switching between git commits.
Instead, watch directories recursively so we can use the file watcher
with parent directories.
See also discussion on rust-lang/rust-analyzer#19907.
I've tested on some decent sized projects (several hundred transitive
dependencies) and performance seemed fine.
When rust-analyzer handles file watching, it previously wouldn't
update the VFS on file deletion. We would discard events where
fs::metadata() isn't available, and we never have metadata for deleted
files.
See also the discussion in rust-lang/rust-analyzer#19907.
As explained in the comments, PostAnalysis is good for most IDE things but not method resolution.
This fixes a bug which should not be impacted by this at all - return position impl trait in trait. It is currently lowered to an opaque, while it should be lowered to an anonymous associated type. But today when it is lowered as an opaque, this opaque of course has no definition and will normalize to an error, preventing method resolution on it from succeeding in some cases.
When rewriting assoc type shorthand lowering (`TypeParam::AssocType`), I took into account that if two traits have the same assoc type, even if one is a supertrait of the other, it's an error. However it turns out that assoc type predicates (`Trait<AssocType = Foo>`) uses the same infrastructure, and there it's allowed to specify an ambiguous assoc type when it refers to a sub-trait. So make a distinction between ambiguous assoc type that comes from a supertrait and one that does not, and if it comes from a supertrait, keep the resolved assoc type for cases that need it.
