Stabilize proc_macro::Span::{file, local_file}. by m-ou-se · Pull Request #140514 · rust-lang/rust (original) (raw)

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation16 Commits2 Checks6 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

m-ou-se

Stabilizes this part of #54725:

impl Span { pub fn file(&self) -> String; // Mapped/artificial file name, for display purposes.

pub fn local_file(&self) -> Option<PathBuf>; // Real file name as it exists on the local file system.

}

See also the naming discussion in #139903

@m-ou-se m-ou-se added T-libs-api

Relevant to the library API team, which will review and decide on the PR/issue.

needs-fcp

This change is insta-stable, or significant enough to need a team FCP to proceed.

S-waiting-on-fcp

Status: PR is in FCP and is awaiting for FCP to complete.

A-proc-macros

Area: Procedural macros

labels

Apr 30, 2025

@m-ou-se

@rfcbot

Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rust-log-analyzer

This comment has been minimized.

@m-ou-se

@m-ou-se

@m-ou-se

I think we should ship (stable) file and local_file in the same rust version as line and column. So it would be good if we can merge this into 1.88 too. :)

@rfcbot rfcbot added the final-comment-period

In the final comment period and will be merged soon unless new substantive objections are raised.

label

Apr 30, 2025

@rfcbot

🔔 This is now entering its final comment period, as per the review above. 🔔

@sam0x17

very excited to see this coming to stable, have been waiting for this for years ❤️

ojeda added a commit to ojeda/linux that referenced this pull request

May 2, 2025

@ojeda

The KUnit #[test] support that landed recently is very basic and does not map the assert*! macros into KUnit like the doctests do, so they panic at the moment.

Thus implement the custom mapping in a similar way to doctests, reusing the infrastructure there.

In Rust 1.88.0, the file() method in Span may be stable [1]. However, it was changed recently (from SourceFile), so we need to do something different in previous versions. Thus create a helper for it and use it to get the path.

With this, a failing test suite like:

#[kunit_tests(my_test_suite)]
mod tests {
    use super::*;

    #[test]
    fn my_first_test() {
        assert_eq!(42, 43);
    }

    #[test]
    fn my_second_test() {
        assert!(42 >= 43);
    }
}

will properly map back to KUnit, printing something like:

[    1.924325]     KTAP version 1
[    1.924421]     # Subtest: my_test_suite
[    1.924506]     # speed: normal
[    1.924525]     1..2
[    1.926385]     # my_first_test: ASSERTION FAILED at rust/kernel/lib.rs:251
[    1.926385]     Expected 42 == 43 to be true, but is false
[    1.928026]     # my_first_test.speed: normal
[    1.928075]     not ok 1 my_first_test
[    1.928723]     # my_second_test: ASSERTION FAILED at rust/kernel/lib.rs:256
[    1.928723]     Expected 42 >= 43 to be true, but is false
[    1.929834]     # my_second_test.speed: normal
[    1.929868]     not ok 2 my_second_test
[    1.930032] # my_test_suite: pass:0 fail:2 skip:0 total:2
[    1.930153] # Totals: pass:0 fail:2 skip:0 total

Link: rust-lang/rust#140514 [1] Signed-off-by: Miguel Ojeda ojeda@kernel.org

intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request

May 2, 2025

@ojeda @intel-lab-lkp

The KUnit #[test] support that landed recently is very basic and does not map the assert*! macros into KUnit like the doctests do, so they panic at the moment.

Thus implement the custom mapping in a similar way to doctests, reusing the infrastructure there.

In Rust 1.88.0, the file() method in Span may be stable [1]. However, it was changed recently (from SourceFile), so we need to do something different in previous versions. Thus create a helper for it and use it to get the path.

With this, a failing test suite like:

#[kunit_tests(my_test_suite)]
mod tests {
    use super::*;

    #[test]
    fn my_first_test() {
        assert_eq!(42, 43);
    }

    #[test]
    fn my_second_test() {
        assert!(42 >= 43);
    }
}

will properly map back to KUnit, printing something like:

[    1.924325]     KTAP version 1
[    1.924421]     # Subtest: my_test_suite
[    1.924506]     # speed: normal
[    1.924525]     1..2
[    1.926385]     # my_first_test: ASSERTION FAILED at rust/kernel/lib.rs:251
[    1.926385]     Expected 42 == 43 to be true, but is false
[    1.928026]     # my_first_test.speed: normal
[    1.928075]     not ok 1 my_first_test
[    1.928723]     # my_second_test: ASSERTION FAILED at rust/kernel/lib.rs:256
[    1.928723]     Expected 42 >= 43 to be true, but is false
[    1.929834]     # my_second_test.speed: normal
[    1.929868]     not ok 2 my_second_test
[    1.930032] # my_test_suite: pass:0 fail:2 skip:0 total:2
[    1.930153] # Totals: pass:0 fail:2 skip:0 total

Link: rust-lang/rust#140514 [1] Signed-off-by: Miguel Ojeda ojeda@kernel.org

@Amanieu

So this lands in the same release as Span::{line,column}.

@bors r+ p=1

@bors

📌 Commit 2a053c7 has been approved by Amanieu

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

May 6, 2025

@ojeda ojeda mentioned this pull request

May 6, 2025

96 tasks

bors added a commit to rust-lang-ci/rust that referenced this pull request

May 6, 2025

@bors

Stabilize proc_macro::Span::{file, local_file}.

Stabilizes this part of rust-lang#54725:

impl Span {
    pub fn file(&self) -> String; // Mapped/artificial file name, for display purposes.

    pub fn local_file(&self) -> Option<PathBuf>; // Real file name as it exists on the local file system.
}

See also the naming discussion in rust-lang#139903

@bors

@rust-log-analyzer

The job x86_64-mingw-1 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot) 

failures:

---- [mir-opt] tests\mir-opt\inline\inline_async.rs stdout ----

error: compilation failed!
status: exit code: 0xc00000fd
command: PATH="D:\a\rust\rust\build\x86_64-pc-windows-gnu\stage2\bin;D:\a\rust\rust\build\x86_64-pc-windows-gnu\stage0-bootstrap-tools\x86_64-pc-windows-gnu\release\deps;D:\a\rust\rust\build\x86_64-pc-windows-gnu\stage0\bin;D:\a\rust\rust\ninja;D:\a\rust\rust\mingw64\bin;C:\msys64\usr\bin;D:\a\rust\rust\sccache;C:\Program Files\MongoDB\Server\5.0\bin;C:\aliyun-cli;C:\vcpkg;C:\Program Files (x86)\NSIS;C:\tools\zstd;C:\Program Files\Mercurial;C:\hostedtoolcache\windows\stack\3.5.1\x64;C:\cabal\bin;C:\ghcup\bin;C:\mingw64\bin;C:\Program Files\dotnet;C:\Program Files\MySQL\MySQL Server 8.0\bin;C:\Program Files\R\R-4.4.2\bin\x64;C:\SeleniumWebDrivers\GeckoDriver;C:\SeleniumWebDrivers\EdgeDriver;C:\SeleniumWebDrivers\ChromeDriver;C:\Program Files (x86)\sbt\bin;C:\Program Files (x86)\GitHub CLI;C:\Program Files\Git\bin;C:\Program Files (x86)\pipx_bin;C:\npm\prefix;C:\hostedtoolcache\windows\go\1.21.13\x64\bin;C:\hostedtoolcache\windows\Python\3.9.13\x64\Scripts;C:\hostedtoolcache\windows\Python\3.9.13\x64;C:\hostedtoolcache\windows\Ruby\3.0.7\x64\bin;C:\Program Files\OpenSSL\bin;C:\tools\kotlinc\bin;C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\8.0.452-9\x64\bin;C:\Program Files\ImageMagick-7.1.1-Q16-HDRI;C:\Program Files\Microsoft SDKs\Azure\CLI2\wbin;C:\ProgramData\kind;C:\ProgramData\Chocolatey\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Program Files\dotnet;C:\Program Files\PowerShell\7;C:\Program Files\Microsoft\Web Platform Installer;C:\Program Files\TortoiseSVN\bin;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn;C:\Program Files\Microsoft SQL Server\150\Tools\Binn;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit;C:\Program Files (x86)\WiX Toolset v3.14\bin;C:\Program Files\Microsoft SQL Server\130\DTS\Binn;C:\Program Files\Microsoft SQL Server\140\DTS\Binn;C:\Program Files\Microsoft SQL Server\150\DTS\Binn;C:\Program Files\Microsoft SQL Server\160\DTS\Binn;C:\Strawberry\c\bin;C:\Strawberry\perl\site\bin;C:\Strawberry\perl\bin;C:\ProgramData\chocolatey\lib\pulumi\tools\Pulumi\bin;C:\Program Files\CMake\bin;C:\ProgramData\chocolatey\lib\maven\apache-maven-3.9.9\bin;C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code;C:\Program Files\Microsoft SDKs\Service Fabric\Tools\ServiceFabricLocalClusterManager;C:\Program Files\nodejs;C:\Program Files\Git\cmd;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\bin;C:\Program Files\GitHub CLI;C:\tools\php;C:\Program Files (x86)\sbt\bin;C:\Program Files\Amazon\AWSCLIV2;C:\Program Files\Amazon\SessionManagerPlugin\bin;C:\Program Files\Amazon\AWSSAMCLI\bin;C:\Program Files\Microsoft SQL Server\130\Tools\Binn;C:\Program Files\LLVM\bin;C:\Users\runneradmin\.dotnet\tools;C:\Users\runneradmin\.cargo\bin;C:\Users\runneradmin\AppData\Local\Microsoft\WindowsApps" "D:\\a\\rust\\rust\\build\\x86_64-pc-windows-gnu\\stage2\\bin\\rustc.exe" "D:\\a\\rust\\rust\\tests\\mir-opt\\inline\\inline_async.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=C:\\Users\\runneradmin\\.cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=D:\\a\\rust\\rust\\vendor" "--sysroot" "D:\\a\\rust\\rust\\build\\x86_64-pc-windows-gnu\\stage2" "--target=x86_64-pc-windows-gnu" "--check-cfg" "cfg(test,FALSE)" "-O" "-Copt-level=1" "-Zdump-mir=all" "-Zvalidate-mir" "-Zlint-mir" "-Zdump-mir-exclude-pass-number" "-Zmir-include-spans=false" "--crate-type=rlib" "-Zmir-opt-level=4" "-Zmir-enable-passes=+ReorderBasicBlocks,+ReorderLocals" "-Zdump-mir-dir=D:\\a\\rust\\rust\\build\\x86_64-pc-windows-gnu\\test\\mir-opt\\inline\\inline_async" "--emit" "mir" "-C" "prefer-dynamic" "--out-dir" "D:\\a\\rust\\rust\\build\\x86_64-pc-windows-gnu\\test\\mir-opt\\inline\\inline_async" "-A" "internal_features" "-Crpath" "-Cdebuginfo=0" "--edition=2018"
stdout: none
--- stderr -------------------------------

thread 'main' has overflowed its stack
------------------------------------------
---
test result: FAILED. 333 passed; 1 failed; 3 ignored; 0 measured; 0 filtered out; finished in 13.33s

Some tests failed in compiletest suite=mir-opt mode=mir-opt host=x86_64-pc-windows-gnu target=x86_64-pc-windows-gnu
Build completed unsuccessfully in 1:38:33
make: *** [Makefile:124: ci-mingw-x] Error 1
  local time: Tue May  6 18:38:42 CUT 2025
  network time: Tue, 06 May 2025 18:38:43 GMT
##[error]Process completed with exit code 2.
Post job cleanup.
[command]"C:\Program Files\Git\bin\git.exe" version

@bors

@bors bors added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

and removed S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

labels

May 6, 2025

@m-ou-se

@bors bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

May 6, 2025

@bors

@bors

@github-actions GitHub Actions

What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 27d6200 (parent) -> 669c1ab (this PR)

Test differences

No test diffs found

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml --
test-dashboard 669c1ab9677ae8dc1d7db30b75fd173d06c0c75a --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. dist-x86_64-apple: 11285.0s -> 7565.0s (-33.0%)
  2. x86_64-apple-2: 4214.6s -> 4793.1s (13.7%)
  3. dist-arm-linux: 5139.8s -> 4798.2s (-6.6%)
  4. dist-android: 2563.6s -> 2394.2s (-6.6%)
  5. x86_64-gnu-distcheck: 4495.2s -> 4768.3s (6.1%)
  6. x86_64-apple-1: 8831.0s -> 8334.0s (-5.6%)
  7. dist-i686-linux: 5971.9s -> 6285.9s (5.3%)
  8. dist-loongarch64-linux: 6660.0s -> 6327.6s (-5.0%)
  9. x86_64-msvc-2: 6614.2s -> 6887.4s (4.1%)
  10. test-various: 4487.0s -> 4303.7s (-4.1%) How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer

Finished benchmarking commit (669c1ab): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

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

Max RSS (memory usage)

Results (primary 0.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌ (primary) 0.8% [0.5%, 1.2%] 4
Regressions ❌ (secondary) - - 0
Improvements ✅ (primary) -0.8% [-1.5%, -0.4%] 3
Improvements ✅ (secondary) - - 0
All ❌✅ (primary) 0.1% [-1.5%, 1.2%] 7

Cycles

Results (primary -0.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌ (primary) 0.7% [0.7%, 0.7%] 1
Regressions ❌ (secondary) - - 0
Improvements ✅ (primary) -0.4% [-0.5%, -0.4%] 5
Improvements ✅ (secondary) - - 0
All ❌✅ (primary) -0.3% [-0.5%, 0.7%] 6

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 769.287s -> 768.04s (-0.16%)
Artifact size: 365.44 MiB -> 365.49 MiB (0.01%)

@m-ou-se m-ou-se deleted the proc-macro-span-file branch

May 7, 2025 07:07

github-actions bot pushed a commit to carolynzech/rust that referenced this pull request

May 16, 2025

@bors

Stabilize proc_macro::Span::{file, local_file}.

Stabilizes this part of rust-lang#54725:

impl Span {
    pub fn file(&self) -> String; // Mapped/artificial file name, for display purposes.

    pub fn local_file(&self) -> Option<PathBuf>; // Real file name as it exists on the local file system.
}

See also the naming discussion in rust-lang#139903

ojeda added a commit to ojeda/linux that referenced this pull request

May 26, 2025

@ojeda

The KUnit #[test] support that landed recently is very basic and does not map the assert*! macros into KUnit like the doctests do, so they panic at the moment.

Thus implement the custom mapping in a similar way to doctests, reusing the infrastructure there.

In Rust 1.88.0, the file() method in Span may be stable [1]. However, it was changed recently (from SourceFile), so we need to do something different in previous versions. Thus create a helper for it and use it to get the path.

With this, a failing test suite like:

#[kunit_tests(my_test_suite)]
mod tests {
    use super::*;

    #[test]
    fn my_first_test() {
        assert_eq!(42, 43);
    }

    #[test]
    fn my_second_test() {
        assert!(42 >= 43);
    }
}

will properly map back to KUnit, printing something like:

[    1.924325]     KTAP version 1
[    1.924421]     # Subtest: my_test_suite
[    1.924506]     # speed: normal
[    1.924525]     1..2
[    1.926385]     # my_first_test: ASSERTION FAILED at rust/kernel/lib.rs:251
[    1.926385]     Expected 42 == 43 to be true, but is false
[    1.928026]     # my_first_test.speed: normal
[    1.928075]     not ok 1 my_first_test
[    1.928723]     # my_second_test: ASSERTION FAILED at rust/kernel/lib.rs:256
[    1.928723]     Expected 42 >= 43 to be true, but is false
[    1.929834]     # my_second_test.speed: normal
[    1.929868]     not ok 2 my_second_test
[    1.930032] # my_test_suite: pass:0 fail:2 skip:0 total:2
[    1.930153] # Totals: pass:0 fail:2 skip:0 total

Link: rust-lang/rust#140514 [1] Reviewed-by: David Gow davidgow@google.com Acked-by: Danilo Krummrich dakr@kernel.org Link: https://lore.kernel.org/r/20250502215133.1923676-2-ojeda@kernel.org [ Used the cfg_attr from the TODO comment, removed the TODO and clarified the comment, since the feature is now in beta and thus quite likely stable in Rust 1.88.0. Simplified the new_body code by introducing a new variable. - Miguel ] Signed-off-by: Miguel Ojeda ojeda@kernel.org

ojeda added a commit to ojeda/linux that referenced this pull request

May 26, 2025

@ojeda

The KUnit #[test] support that landed recently is very basic and does not map the assert*! macros into KUnit like the doctests do, so they panic at the moment.

Thus implement the custom mapping in a similar way to doctests, reusing the infrastructure there.

In Rust 1.88.0, the file() method in Span may be stable [1]. However, it was changed recently (from SourceFile), so we need to do something different in previous versions. Thus create a helper for it and use it to get the path.

With this, a failing test suite like:

#[kunit_tests(my_test_suite)]
mod tests {
    use super::*;

    #[test]
    fn my_first_test() {
        assert_eq!(42, 43);
    }

    #[test]
    fn my_second_test() {
        assert!(42 >= 43);
    }
}

will properly map back to KUnit, printing something like:

[    1.924325]     KTAP version 1
[    1.924421]     # Subtest: my_test_suite
[    1.924506]     # speed: normal
[    1.924525]     1..2
[    1.926385]     # my_first_test: ASSERTION FAILED at rust/kernel/lib.rs:251
[    1.926385]     Expected 42 == 43 to be true, but is false
[    1.928026]     # my_first_test.speed: normal
[    1.928075]     not ok 1 my_first_test
[    1.928723]     # my_second_test: ASSERTION FAILED at rust/kernel/lib.rs:256
[    1.928723]     Expected 42 >= 43 to be true, but is false
[    1.929834]     # my_second_test.speed: normal
[    1.929868]     not ok 2 my_second_test
[    1.930032] # my_test_suite: pass:0 fail:2 skip:0 total:2
[    1.930153] # Totals: pass:0 fail:2 skip:0 total

Link: rust-lang/rust#140514 [1] Reviewed-by: David Gow davidgow@google.com Acked-by: Danilo Krummrich dakr@kernel.org Link: https://lore.kernel.org/r/20250502215133.1923676-2-ojeda@kernel.org [ Used the cfg_attr from the TODO comment and clarified its comment now that the stabilization is in beta and thus quite likely stable in Rust 1.88.0. Simplified the new_body code by introducing a new variable. Added #[allow(clippy::incompatible_msrv)]. - Miguel ] Signed-off-by: Miguel Ojeda ojeda@kernel.org

ojeda added a commit to Rust-for-Linux/linux that referenced this pull request

May 27, 2025

@ojeda

The KUnit #[test] support that landed recently is very basic and does not map the assert*! macros into KUnit like the doctests do, so they panic at the moment.

Thus implement the custom mapping in a similar way to doctests, reusing the infrastructure there.

In Rust 1.88.0, the file() method in Span may be stable [1]. However, it was changed recently (from SourceFile), so we need to do something different in previous versions. Thus create a helper for it and use it to get the path.

With this, a failing test suite like:

#[kunit_tests(my_test_suite)]
mod tests {
    use super::*;

    #[test]
    fn my_first_test() {
        assert_eq!(42, 43);
    }

    #[test]
    fn my_second_test() {
        assert!(42 >= 43);
    }
}

will properly map back to KUnit, printing something like:

[    1.924325]     KTAP version 1
[    1.924421]     # Subtest: my_test_suite
[    1.924506]     # speed: normal
[    1.924525]     1..2
[    1.926385]     # my_first_test: ASSERTION FAILED at rust/kernel/lib.rs:251
[    1.926385]     Expected 42 == 43 to be true, but is false
[    1.928026]     # my_first_test.speed: normal
[    1.928075]     not ok 1 my_first_test
[    1.928723]     # my_second_test: ASSERTION FAILED at rust/kernel/lib.rs:256
[    1.928723]     Expected 42 >= 43 to be true, but is false
[    1.929834]     # my_second_test.speed: normal
[    1.929868]     not ok 2 my_second_test
[    1.930032] # my_test_suite: pass:0 fail:2 skip:0 total:2
[    1.930153] # Totals: pass:0 fail:2 skip:0 total

Link: rust-lang/rust#140514 [1] Reviewed-by: David Gow davidgow@google.com Acked-by: Danilo Krummrich dakr@kernel.org Link: https://lore.kernel.org/r/20250502215133.1923676-2-ojeda@kernel.org [ Required KUNIT=y like for doctests. Used the cfg_attr from the TODO comment and clarified its comment now that the stabilization is in beta and thus quite likely stable in Rust 1.88.0. Simplified the new_body code by introducing a new variable. Added #[allow(clippy::incompatible_msrv)]. - Miguel ] Signed-off-by: Miguel Ojeda ojeda@kernel.org

Labels

A-proc-macros

Area: Procedural macros

disposition-merge

This issue / PR is in PFCP or FCP with a disposition to merge it.

finished-final-comment-period

The final comment period is finished for this PR / Issue.

merged-by-bors

This PR was explicitly merged by bors.

needs-fcp

This change is insta-stable, or significant enough to need a team FCP to proceed.

S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

S-waiting-on-fcp

Status: PR is in FCP and is awaiting for FCP to complete.

T-libs-api

Relevant to the library API team, which will review and decide on the PR/issue.