Rollup merge of #154409 - scottmcm:change-try-tracking, r=TaKO8Ki

Update `try_blocks` to a new tracking issue number

New tracking issue #154391
Closes #31436

Author: JonathanBrouwer

compiler/rustc_feature/src/unstable.rs

@@ -693,7 +693,7 @@ declare_features! (
     /// Allows inconsistent bounds in where clauses.
     (unstable, trivial_bounds, "1.28.0", Some(48214)),
     /// Allows using `try {...}` expressions.
-    (unstable, try_blocks, "1.29.0", Some(31436)),
+    (unstable, try_blocks, "1.29.0", Some(154391)),
     /// Allows using `try bikeshed TargetType {...}` expressions.
     (unstable, try_blocks_heterogeneous, "1.94.0", Some(149488)),
     /// Allows `impl Trait` to be used inside type aliases (RFC 2515).

src/doc/unstable-book/src/language-features/try-blocks.md

@@ -1,8 +1,8 @@
 # `try_blocks`
 
-The tracking issue for this feature is: [#31436]
+The tracking issue for this feature is: [#154391]
 
-[#31436]: https://github.com/rust-lang/rust/issues/31436
+[#154391]: https://github.com/rust-lang/rust/issues/154391
 
 ------------------------
 
@@ -14,14 +14,14 @@ block creates a new scope one can use the `?` operator in.
 
 use std::num::ParseIntError;
 
-let result: Result<i32, ParseIntError> = try {
+let result = try {
     "1".parse::<i32>()?
         + "2".parse::<i32>()?
         + "3".parse::<i32>()?
 };
 assert_eq!(result, Ok(6));
 
-let result: Result<i32, ParseIntError> = try {
+let result = try {
     "1".parse::<i32>()?
         + "foo".parse::<i32>()?
         + "3".parse::<i32>()?

src/tools/rust-analyzer/crates/ide-db/src/generated/lints.rs

@@ -11576,9 +11576,9 @@ The tracking issue for this feature is: [#85731]
         label: "try_blocks",
         description: r##"# `try_blocks`
 
-The tracking issue for this feature is: [#31436]
+The tracking issue for this feature is: [#154391]
 
-[#31436]: https://github.com/rust-lang/rust/issues/31436
+[#154391]: https://github.com/rust-lang/rust/issues/154391
 
 ------------------------
 
@@ -11590,14 +11590,14 @@ block creates a new scope one can use the `?` operator in.
 
 use std::num::ParseIntError;
 
-let result: Result<i32, ParseIntError> = try {
+let result = try {
     "1".parse::<i32>()?
         + "2".parse::<i32>()?
         + "3".parse::<i32>()?
 };
 assert_eq!(result, Ok(6));
 
-let result: Result<i32, ParseIntError> = try {
+let result = try {
     "1".parse::<i32>()?
         + "foo".parse::<i32>()?
         + "3".parse::<i32>()?

tests/ui/README.md

@@ -1420,7 +1420,7 @@ Tests for the `#[doc(hidden)]` items.
 
 ## `tests/ui/try-block/`
 
-`#![feature(try_blocks)]`. See [Tracking issue for `?` operator and `try` blocks (RFC 243, `question_mark` & `try_blocks` features)](https://github.com/rust-lang/rust/issues/31436).
+`#![feature(try_blocks)]` & `#![feature(try_blocks_heterogeneous)]`. See [Tracking Issue for homogeneous `try_blocks`](https://github.com/rust-lang/rust/issues/154391) & [Experimental Tracking Issue for Heterogeneous Try Blocks](https://github.com/rust-lang/rust/issues/149488).
 
 ## `tests/ui/try-trait/`
 

tests/ui/feature-gates/feature-gate-try_blocks.stderr

@@ -8,7 +8,7 @@ LL | |         x
 LL | |     };
    | |_____^
    |
-   = note: see issue #31436 <https://github.com/rust-lang/rust/issues/31436> for more information
+   = note: see issue #154391 <https://github.com/rust-lang/rust/issues/154391> for more information
    = help: add `#![feature(try_blocks)]` to the crate attributes to enable
    = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
 

tests/ui/try-block/try-block-homogeneous-pre-expansion.stderr

@@ -4,7 +4,7 @@ warning: `try` blocks are unstable
 LL |     try {}
    |     ^^^^^^
    |
-   = note: see issue #31436 <https://github.com/rust-lang/rust/issues/31436> for more information
+   = note: see issue #154391 <https://github.com/rust-lang/rust/issues/154391> for more information
    = help: add `#![feature(try_blocks)]` to the crate attributes to enable
    = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
    = warning: unstable syntax can change at any point in the future, causing a hard error!