I added it by mistake in #18927.
I chose to keep the method as not static, because it's more comfortable, and keep the name `add_reference()` and not `reference()`, because it is clearer and better matches `strip_reference[s]()`.
It should be considered by the edition of the caller, not the callee.
Technically we still don't do it correctly - we need the span of the method name (if it comes from a macro), but we don't keep it and this is good enough for now.
Split manual.adoc into markdown files, one for each chapter.
For the parts of the manual that are generated from source code doc
comments, update the comments to use markdown syntax and update the
code generators to write to `generated.md` files.
For the weekly release, stop copying the .adoc files to the
`rust-analyzer/rust-analyzer.github.io` at release time. Instead,
we'll sync the manual hourly from this repository.
See https://github.com/rust-analyzer/rust-analyzer.github.io/pull/226
for the sync. This PR should be merged first, and that PR needs to be
merged before the next weekly release.
This change is based on #15795, but rebased and updated. I've also
manually checked each page for markdown syntax issues and fixed any I
encountered.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Co-authored-by: Josh Rotenberg <joshrotenberg@gmail.com>
More correctly, *also* per-token. Because as it turns out, while the top-level edition affects parsing (I think), the per-token edition affects escaping of identifiers/keywords.
We should immediately mark them as finished, on the first entry.
The funny (or sad) part was that this bug was pre-existing, but previously to #18327, it was causing us to generate bindings non-stop, 65535 of them, until we get to the hardcoded repetition limit, and then throw it all away. And it was so Blazingly Fast that nobody noticed.
With #18327 however, this is still what happens, except that now instead of *merging* the fragments into the result, we write them on-demand. Meaning that when we hit the limit, we've already written all previous entries. This is a minor change, I thought for myself when I was writing this, and it's actually for the better, so who cares. Minor change? Not so fast. This caused us to emit 65535 repetitions, all of which the MBE infra needs to handle when calling other macros with the expansion, and convert to rowan tree etc., which resulted a *massive* hang.
The test (and also `analysis-stats`) used to crash with stack overflow on this macro, because we were dropping some crazily deep rowan tree. Now they work properly. Because I am lazy, and also because I could not find the exact conditions that causes a macro match but with a missing binding, I just copied all macros from tracing. Easy.
Because it was a mess.
Previously, pretty much you had to handle all path diagnostics manually: remember to check for them and handle them. Now, we wrap the resolver in `TyLoweringContext` and ensure proper error reporting.
This means that you don't have to worry about them: most of the things are handled automatically, and things that cannot will create a compile-time error (forcing you top `drop(ty_lowering_context);`) if forgotten, instead of silently dropping the diagnostics.
The real place for error reporting is in the hir-def resolver, because there are other things resolving, both in hir-ty and in hir-def, and they all need to ensure proper diagnostics. But this is a good start, and future compatible.
This commit also ensures proper path diagnostics for value/pattern paths, which is why it's marked "feat".
Previously all lints were assumed to be `#[warn]`, and we had a hand-coded list of `#[allow]` exceptions. Now the severity is autogenerated from rustdoc output.
Also support lints that change status between editions, and the `warnings` lint group.
Implement diagnostics in all places left: generics (predicates, defaults, const params' types), fields, and type aliases.
Unfortunately this results in a 20mb addition in `analysis-stats .` due to many type methods returning an addition diagnostics result now (even if it's `None` in most cases). I'm not sure if this can be improved.
An alternative strategy that can prevent the memory usage growth is to never produce diagnostics in hir-ty methods. Instead, lower all types in the hir crate when computing diagnostics from scratch (with diagnostics this time). But this has two serious disadvantages:
1. This can cause code duplication (although it can probably be not that bad, it will still mean a lot more code).
2. I believe we eventually want to compute diagnostics for the *entire* workspace (either on-type or on-save or something alike), so users can know when they have diagnostics even in inactive files. Choosing this approach will mean we lose all precomputed salsa queries. For one file this is fine, for the whole workspace this will be very slow.
The diagnostic implemented is a simple one (E0109). It serves as a test for the new foundation.
This commit only implements diagnostics for type in bodies and body-carrying signatures; the next commit will include diagnostics in the rest of the things.
Also fix one weird bug that was detected when implementing this that caused `Fn::(A, B) -> C` (which is a valid, if bizarre, alternative syntax to `Fn(A, B) -> C` to lower incorrectly.
And also fix a maybe-bug where parentheses were sneaked into a code string needlessly; this was not detected until now because the parentheses were removed (by the make-AST family API), but with a change in this commit they are now inserted. So fix that too.
We add union fields access (in both expressions and patterns) and inline assembly.
That completes the unsafe check (there are some other unsafe things but they are unstable), and so also opens the door to reporting unused unsafe without annoying people about their not-unused unsafe blocks.
Only in calls, because to support them in bounds we need support from Chalk. However we don't yet report error from bounds anyway, so this is less severe.
The returned future is shown in its name within inlay hints instead of as a nicer `impl Future`, but that can wait for another PR.
