Rollup of 9 pull requests
Successful merges:
- #99212 (introduce `implied_by` in `#[unstable]` attribute)
- #99352 (Use `typeck_results` to avoid duplicate `ast_ty_to_ty` call)
- #99355 (better error for bad depth parameter on macro metavar expr)
- #99480 (Diagnostic width span is not added when '0$' is used as width in format strings)
- #99488 (compiletest: Allow using revisions with debuginfo tests.)
- #99489 (rustdoc UI fixes)
- #99508 (Avoid `Symbol` to `String` conversions)
- #99510 (adapt assembly/static-relocation-model test for LLVM change)
- #99516 (Use new tracking issue for proc_macro::tracked_*.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Diagnostic width span is not added when '0$' is used as width in format strings
When the following code is run rustc does not add diagnostic spans for the width argument. Such spans are necessary for a clippy lint that I am currently writing.
```rust
println!("Hello {1:0$}!", 5, "x");
// ^^
// Should have a span here
```
introduce `implied_by` in `#[unstable]` attribute
Requested by the library team [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/better.20support.20for.20partial.20stabilizations/near/285581519).
If part of a feature is stabilized and a new feature is added for the remaining parts, then the `implied_by` meta-item can be added to `#[unstable]` to indicate which now-stable feature was used previously.
```diagnostic
error: the feature `foo` has been partially stabilized since 1.62.0 and is succeeded by the feature `foobar`
--> $DIR/stability-attribute-implies-using-unstable.rs:3:12
|
LL | #![feature(foo)]
| ^^^
|
note: the lint level is defined here
--> $DIR/stability-attribute-implies-using-stable.rs:2:9
|
LL | #![deny(stable_features)]
| ^^^^^^^^^^^^^^^
help: if you are using features which are still unstable, change to using `foobar`
|
LL | #![feature(foobar)]
| ~~~~~~
help: if you are using features which are now stable, remove this line
|
LL - #![feature(foo)]
|
```
When a `#![feature(..)]` attribute still exists for the now-stable attribute, then there this has two effects:
- There will not be an stability error for uses of items from the implied feature which are still unstable (until the `#![feature(..)]` is removed or updated to the new feature).
- There will be an improved diagnostic for the remaining use of the feature attribute for the now-stable feature.
```rust
/// If part of a feature is stabilized and a new feature is added for the remaining parts,
/// then the `implied_by` attribute is used to indicate which now-stable feature previously
/// contained a item.
///
/// ```pseudo-Rust
/// #[unstable(feature = "foo", issue = "...")]
/// fn foo() {}
/// #[unstable(feature = "foo", issue = "...")]
/// fn foobar() {}
/// ```
///
/// ...becomes...
///
/// ```pseudo-Rust
/// #[stable(feature = "foo", since = "1.XX.X")]
/// fn foo() {}
/// #[unstable(feature = "foobar", issue = "...", implied_by = "foo")]
/// fn foobar() {}
/// ```
```
In the Zulip discussion, this was envisioned as `implies` on `#[stable]` but I went with `implied_by` on `#[unstable]` because it means that only the unstable attribute needs to be changed in future, not the new stable attribute, which seems less error-prone. It also isn't particularly feasible for me to detect whether items from the implied feature are used and then only suggest updating _or_ removing the `#![feature(..)]` as appropriate, so I always do both.
There's some new information in the cross-crate metadata as a result of this change, that's a little unfortunate, but without requiring that the `#[unstable]` and `#[stable]` attributes both contain the implication information, it's necessary:
```rust
/// This mapping is necessary unless both the `#[stable]` and `#[unstable]` attributes should
/// specify their implications (both `implies` and `implied_by`). If only one of the two
/// attributes do (as in the current implementation, `implied_by` in `#[unstable]`), then this
/// mapping is necessary for diagnostics. When a "unnecessary feature attribute" error is
/// reported, only the `#[stable]` attribute information is available, so the map is necessary
/// to know that the feature implies another feature. If it were reversed, and the `#[stable]`
/// attribute had an `implies` meta item, then a map would be necessary when avoiding a "use of
/// unstable feature" error for a feature that was implied.
```
I also change some comments to documentation comments in the compiler, add a helper for going from a `Span` to a `Span` for the entire line, and fix a incorrect part of the pre-existing stability attribute diagnostics.
cc `@yaahc`
interpret: rename Tag/PointerTag to Prov/Provenance
We were pretty inconsistent with calling this the "tag" vs the "provenance" of the pointer; I think we should consistently call it "provenance".
r? `@oli-obk`
Add PROC_MACRO_TEST_TOOLCHAIN environment variable
This allows overriding the toolchain used to run `proc-macro-srv` tests.
---
Sample usage.
Testing the current ABI (variable unset/empty):
```shell
amos@tails ~/bearcove/rust-analyzer/crates/proc-macro-srv proc-macro-test-toolchain*
❯ PROC_MACRO_TEST_TOOLCHAIN="" cargo test --quiet
running 16 tests
................
test result: ok. 16 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s
```
Testing an older ABI:
```shell
amos@tails ~/bearcove/rust-analyzer/crates/proc-macro-srv proc-macro-test-toolchain*
❯ PROC_MACRO_TEST_TOOLCHAIN="1.58" cargo test --quiet
running 16 tests
................
test result: ok. 16 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s
```
Testing current nightly ABI:
```shell
❯ rustc +nightly --version
rustc 1.64.0-nightly (f8588549c 2022-07-18)
❯ PROC_MACRO_TEST_TOOLCHAIN="nightly" cargo test --quiet
running 16 tests
................
test result: ok. 16 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s
```
Testing future ABI (`rust-lang/rust` master):
```shell
amos@tails ~/bearcove/rust-analyzer/crates/proc-macro-srv proc-macro-test-toolchain
❯ PROC_MACRO_TEST_TOOLCHAIN="stage1" cargo test --quiet
running 16 tests
..........thread '<unnamed>' panicked at 'range end index 216221164920373249 out of range for slice of length 18', library/core/src/slice/index.rs:73:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
....F.
failures:
---- tests::test_fn_like_macro2 stdout ----
thread 'tests::test_fn_like_macro2' panicked at 'called `Result::unwrap()` on an `Err` value: "range end index 216221164920373249 out of range for slice of length 18"', crates/proc-macro-srv/src/tests/utils.rs:38:83
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
tests::test_fn_like_macro2
test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--lib
```
---
Tagging `@jonas-schievink:` this might be helpful when updating versioned ABIs later on.
Add proc-macro-srv integration test that clones literals
This exercises some of the upcoming proc_macro bridge changes. It should also pass for all supported ABIs, with the older-style bridge.
This changed is tracked in:
* https://github.com/rust-lang/rust-analyzer/issues/12818
Build proc-macro-test-impl out-of-tree
Building it in-place fails in rust CI because the source directory is read-only. This changes `proc-macro-test`'s build script to first
copy `imp` under `OUT_DIR` (which is read-write).
It also prints stdout/stderr for the nested cargo invocation, should it fail. (I've seen failures in rust CI that I couldn't explain, and
when they take 25 minutes to reproduce, you want to have that info)
This change is tracked in:
* https://github.com/rust-lang/rust-analyzer/issues/12818
Maintainer impact: none.
* Add a test for atomic operations introduced in #97423 & #98383.
* Add a test for fallback code generation strategy used on LLVM 12
introduced in #98385. Use a separate test case instead of a revision
system since test will be gone once LLVM 12 is no longer supported.
