simplify some proc_macro things

[cyrgani]

Each commit should be reviewable on its own. Locally, this also resulted in some slightly better perf results.

[rustbot]

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @petrochenkov

[Kobzol]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: aba743d (aba743d72e1a2d02bf787988ac919c3c416f243c, parent: c0bb140a37c81cf59a0b40c21c9413059644e294)

[rust-timer]

Finished benchmarking commit (aba743d): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.4%	[0.1%, 1.1%]	27
Regressions ❌ (secondary)	0.2%	[0.2%, 0.2%]	1
Improvements ✅ (primary)	-0.8%	[-1.9%, -0.2%]	13
Improvements ✅ (secondary)	-1.9%	[-4.2%, -0.1%]	13
All ❌✅ (primary)	-0.0%	[-1.9%, 1.1%]	40

Max RSS (memory usage)

Results (primary 2.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.4%	[2.4%, 2.4%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.4%	[2.4%, 2.4%]	1

Cycles

Results (primary 0.4%, secondary -5.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.9%	[1.7%, 2.1%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.7%	[-2.7%, -2.7%]	1
Improvements ✅ (secondary)	-5.6%	[-5.6%, -5.6%]	1
All ❌✅ (primary)	0.4%	[-2.7%, 2.1%]	3

Binary size

Results (primary -0.9%, secondary -2.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.9%	[-1.3%, -0.4%]	17
Improvements ✅ (secondary)	-2.1%	[-3.0%, -0.4%]	7
All ❌✅ (primary)	-0.9%	[-1.3%, -0.4%]	17

Bootstrap: 511.375s -> 517.888s (1.27%)
Artifact size: 400.63 MiB -> 400.68 MiB (0.01%)

[bjorn3]

Wouldn't this cause all tokenstreams to be unnecessarily retained on the server side until the end of the proc macro invocation even if the client drops it earlier?

View changes since the review

[petrochenkov]

Yeah, the motivation is missing for this change now - what did this drop do, what happens now when it's removed, why it's good.

[petrochenkov]

Any specific reason to remove this optimization?
It would probably be better to benchmark it separately in any case.

View changes since the review

[petrochenkov]

Why is it better to directly manage Buffer memory without using Vec?

View changes since the review