Skip to content
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 and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for PanicInfo::message #66745

Closed
9 tasks done
SimonSapin opened this issue Nov 25, 2019 · 27 comments · Fixed by #126732
Closed
9 tasks done

Tracking issue for PanicInfo::message #66745

SimonSapin opened this issue Nov 25, 2019 · 27 comments · Fixed by #126732
Labels
A-error-handling Area: Error handling B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. 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. Libs-Tracked Libs issues that are tracked on the team's project board. PG-error-handling Project group: Error handling (https://github.com/rust-lang/project-error-handling) T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@SimonSapin
Copy link
Contributor

SimonSapin commented Nov 25, 2019

#44489 was closed when #51366 stabilized the corresponding language feature, but we didn’t realize that it was also the tracking issue for this standard library feature:

// In `core::panic`:

impl PanicInfo<'_> {
    /// The message that was given to the `panic!` macro.
    pub fn message(&self) -> PanicMessage<'_>;
}

// Opaque type that wraps a fmt::Arguments<'a>.
pub struct PanicMessage<'a> { .. }

impl Display for PanicMessage<'_>;
impl Debug for PanicMessage<'_>;

impl PanicMessage<'_> {
    pub fn as_str(&self) -> Option<&'static str>;
}

History:

Unresolved questions:

  • Should it be infallible?
    • Yes, by making std::panic::PanicHookInfo a different type.
  • What should the return type be?
    • fmt::Arguments or an opaque PanicMessage? The first is simpler, but the latter allows a bit more flexibility for future changes.
@SimonSapin SimonSapin added B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Nov 25, 2019
@SimonSapin
Copy link
Contributor Author

Instead of making a PR go through the queue to fix the tracking issue, should we stabilize this method?

@rfcbot fcp merge

The doc-comment is slightly wrong or out of date. Its second line shoudl be removed. core::panic! always creates a PanicInfo where message is Some, regardless of the number of arguments given. In the single-argument case, that argument is required to have type &str.

At first returning fmt::Arguments seemed unusual to me and I considered that we could make the method return Option<impl Display + 'a> instead, on the basis that calling its Display impl is almost the only useful thing to do with a Arguments. But Arguments has been stable and documented as the return type of format_args!(…) since 1.0.0, so maybe it’s fine.

@rfcbot

This comment was marked as outdated.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Nov 25, 2019
@SimonSapin SimonSapin changed the title Tracking issue for PanicInfo::message Tracking issue for PanicInfo::message and core::panic Nov 25, 2019
@SimonSapin
Copy link
Contributor Author

The core::panic module also links to that closed tracking issue. Let’s consider the pFCP above to also include stabilizing it. (std::panic is stable.)

@SimonSapin
Copy link
Contributor Author

@rfcbot concern single-arg core::panic

Should we change libcore’s panic macro so that its single-argument form creates a PanicInfo with a payload instead of one with a message? CC #66740 (comment)

Pushing this idea further, it’s tempting to maybe remove PanicInfo::message entirely and instead have a payload whose dynamic type can be fmt::Arguments. But that doesn’t work because downcast_ref is a method of dyn Any + 'static and fmt::Arguments<'_> is not 'static.

@sfackler
Copy link
Member

I thought the point of the message field was that core can't make a payload since it can't allocate?

@SimonSapin
Copy link
Contributor Author

The struct is:

pub struct PanicInfo<'a> {
    payload: &'a (dyn Any + Send),
    message: Option<&'a fmt::Arguments<'a>>,
    location: &'a Location<'a>,
}

Both the payload and message fields involve borrowing. As far as PanicInfo is concerned, they could both be borrowing form a stack frame. (And as far as I understand they are, in practice today.)

It’s in the case of unwinding that there’s an owned Box<dyn Any + Send> that catch_unwind can return, which requires allocating.

@SimonSapin
Copy link
Contributor Author

@RalfJung Based on the timing of https://www.ralfj.de/blog/2019/11/25/how-to-panic-in-rust.html it looks like you may have thoughts on this :)

@SimonSapin
Copy link
Contributor Author

Ah, https://www.ralfj.de/blog/2019/11/25/how-to-panic-in-rust.html goes into how and why the panic handler in libstd (which is called by core::panic! if libstd is linked) ignores the payload it receives.

We could probably change this but it gets tricky: while most implementations of #[panic_handler] for no_std environments would be fine with receiving a borrowed payload, libstd wants to potentially take ownership and box it for unwinding.

@alexcrichton
Copy link
Member

I have zero recollection for why this is the way it is, and I'm not really particularly interested in doing all the archaeology to dig up why it is the way it is. I'm not a huge fan of just stabilizing things because they happen to be there, but I don't really see why we wouldn't want to stabilize this. If there were a reason to not stabilize this though an investigation would presumably turn that up, but I'm not up to do that investigation myself.

@SimonSapin
Copy link
Contributor Author

That’s totally fair.

I’m confident that this was more likely forgotten than deliberately left unstable. If deliberate we would have kept the tracking issue open or made a new one for the remaining bits. This is what lead me to propose stabilization.

Having dug a little more, and thanks to Ralf’s blog post, I think we may want at some point to revisit what data we expect PanicInfo to contain or not in various situation. In particular it could be interesting to extend core::panic!(foo) to support payloads other than &str and make it closer to std::panic!(foo).

Given those possibly-desirable changes, it may not be the time to add more constraints:

@rfcbot fcp cancel

@rfcbot
Copy link

rfcbot commented Nov 25, 2019

@SimonSapin proposal cancelled.

@rfcbot rfcbot removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Nov 25, 2019
@RalfJung
Copy link
Member

Based on the timing of https://www.ralfj.de/blog/2019/11/25/how-to-panic-in-rust.html it looks like you may have thoughts on this :)

Lol, I had no idea. ;)

Cleanup

So, indeed, I was wondering if we could do something about the duality of the message and payload fields in PanicInfo. I assume we cannot change the fact that the same type is used both of panic handlers and panic hooks.

Concretely, I was thinking of adjusting PanicInfo somewhat like this:

pub struct PanicInfo<'a> {
    payload: Payload<'a>,
    location: &'a Location<'a>,
}

enum Payload<'a> {
  Any(&'a (dyn Any + Send)),
  Message(&'a fmt::Arguments<'a>),
}

That would at least remove the need for the NoPayload hack in PanicInfo::internal_constructor. (The hack would likely move to PanicInfo::payload instead, but that is a smaller hack IMO: the hack is now not encoded in the state of PanicInfo any more, just in its dynamic API.)

I think this would retain all current functionality while clarifying the invariant of PanicInfo wrt. the payload (and explicitly calling the message a "payload"; right now it seems to be something that sits next to the payload which is inaccruate). But there are enough subtleties here that we'll only really know once someone implements this.

Extension: convenient convert-to-string

With this change, the panic hook would always get a Payload::Any. We should likely provide a method somewhere in libstd to factor out this code:

let msg = match info.payload().downcast_ref::<&'static str>() {
Some(s) => *s,
None => match info.payload().downcast_ref::<String>() {
Some(s) => &s[..],
None => "Box<Any>",
}
};

I was imagining something like an extension trait on PanicInfo with a type like fn(&self) -> Option<&str>. However, the panic hook is not the only place where that conversion is useful; another situation is code that caught a panic and wants to extract the message. I expect most instances of that to just handle String payloads, not knowing that &str payloads are also common (that is certainly what happened when I wrote such code). So ideally we'd have a method that takes &(dyn Any+Send) and returns Option<&str>, but I do not have a good idea where to put that.

Extension: payload-carrying panics from libcore

This is the hard part, as we cannot use Box. I wonder if we can use a take-based approach, similar to BoxMeUp? Conceptually, core::panic!(payload) would put the panic into an Option<T>, and somehow pass an &mut Option<T> to the panic handler, and the implementation of said handler could then take the payload if it needs full ownership (like for unwinding). Except the panic handler cannot be generic, so it would have to be &mut Option<dyn Any+Send>, which is not a thing. But with enough unsafe code we could re-implement something that behaves like that.

I don't see any way to do this entirely safely; the panic handler that wants to take out the payload and put it somewhere needs to dynamically determine the size of the payload and arrange for there to be enough space. In liballoc, we could provide a safe wrapper for this that puts things into a Box<dyn Any+Send>, but in libcore, I don't think there is a safe API that we could provide to grab ownership. But maybe it is enough for the public API to expose ways to borrow the payload (should work for all non-unwinding handlers); if only libstd needs to take the payload (for unwinding) we could keep the unsafe part of the PanicInfo API internal.

Also, we certainly do not want a panic hook to take the payload out of its PanicInfo. At this point it seems to be quite a problem that panic hook and panic handler both use the same type. In fact, a panic handler likely wants a &mut PanicInfo<'_> to be able to take things without interior mutability. Is there any way we could make the #[panic_handler] attribute support both signatures, and then (based on the types of the PanicInfo methods) only &mut-based implementations will actually be able to get_mut or take the payload?

@SimonSapin
Copy link
Contributor Author

We should likely provide a method somewhere in libstd to factor out this code:

I agree, but it’s can easily be an inherent method of PanicInfo nor of dyn Any+Send because those are in libcore which doesn’t have access to String. It feels slightly unfortunate that we’d need an extension trait just for this.

payload-carrying panics from libcore

I considered this yesterday and come to pretty much the same conclusions.

To take ownership of a payload of unknown size through a non-generic API we pretty much heap allocation, which for libcore means something like receiving an fn alloc(Layout) -> NonNull<()>, unsafely using ptr::write, and returning NonNull<dyn Any+Send> that is to be passed to Box::from_raw.

It’s not pretty, but if only libcore and libstd deal with this internally maybe that’s ok? Is there a use case for a #[panic_handler] other than libstd’s to take ownership of the payload?

@SimonSapin SimonSapin changed the title Tracking issue for PanicInfo::message and core::panic Tracking issue for PanicInfo::message Nov 26, 2019
@RalfJung
Copy link
Member

I was thinking of a slightly different API actually:

fn get_payload_layout(&self) -> Layout;
unsafe fn take_payload(&mut self, ptr: *mut u8);

Here, take_payload does ptr.write to put the payload into caller-allocated storage; that storage must have (at least) size and align as given by get_payload_layout. What I did not consider is how to get out the vtable, so maybe that higher-order approach is better.

@m-ou-se
Copy link
Member

m-ou-se commented Jun 12, 2024

Did that in this PR: #126330

bors added a commit to rust-lang-ci/rust that referenced this issue Jun 18, 2024
Return opaque type from PanicInfo::message()

This changes the return type of the (unstable) PanicInfo::message() method to an opaque type (that implements Display). This allows for a bit more flexibility in the future.

See rust-lang#66745
github-actions bot pushed a commit to rust-lang/miri that referenced this issue Jun 19, 2024
Return opaque type from PanicInfo::message()

This changes the return type of the (unstable) PanicInfo::message() method to an opaque type (that implements Display). This allows for a bit more flexibility in the future.

See rust-lang/rust#66745
@m-ou-se
Copy link
Member

m-ou-se commented Jun 19, 2024

@rfcbot merge

@rfcbot
Copy link

rfcbot commented Jun 19, 2024

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.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Jun 19, 2024
@rfcbot
Copy link

rfcbot commented Jun 19, 2024

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

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Jun 29, 2024
@rfcbot
Copy link

rfcbot commented Jun 29, 2024

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

@rfcbot rfcbot added the to-announce Announce this issue on triage meeting label Jun 29, 2024
@bors bors closed this as completed in 61db24d Jul 1, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jul 1, 2024
Rollup merge of rust-lang#126732 - StackOverflowExcept1on:master, r=m-ou-se

Stabilize `PanicInfo::message()` and `PanicMessage`

Resolves rust-lang#66745

This stabilizes the [`PanicInfo::message()`](https://doc.rust-lang.org/nightly/core/panic/struct.PanicInfo.html#method.message) and [`PanicMessage`](https://doc.rust-lang.org/nightly/core/panic/struct.PanicMessage.html).

Demonstration of [custom panic handler](https://github.com/StackOverflowExcept1on/panicker):
```rust
#![no_std]
#![no_main]

extern crate libc;

#[no_mangle]
extern "C" fn main() -> libc::c_int {
    panic!("I just panic every time");
}

#[panic_handler]
fn my_panic(panic_info: &core::panic::PanicInfo) -> ! {
    use arrayvec::ArrayString;
    use core::fmt::Write;

    let message = panic_info.message();
    let location = panic_info.location().unwrap();

    let mut debug_msg = ArrayString::<1024>::new();
    let _ = write!(&mut debug_msg, "panicked with '{message}' at '{location}'");

    if debug_msg.try_push_str("\0").is_ok() {
        unsafe {
            libc::puts(debug_msg.as_ptr() as *const _);
        }
    }

    unsafe { libc::exit(libc::EXIT_FAILURE) }
}
```
```
$ cargo +stage1 run --release
panicked with 'I just panic every time' at 'src/main.rs:8:5'
```

- [x] FCP: rust-lang#66745 (comment)

r? libs-api
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Jul 4, 2024
facebook-github-bot pushed a commit to facebook/buck2 that referenced this issue Oct 7, 2024
Summary:
Upgrading Rust from `1.80.1` to `1.81.0` ([release notes](https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html)) with the following changes affecting `fbsource`:
* Feature stabilizations:
  * `io_slice_advance` ([#62726](rust-lang/rust#62726))
  * `panic_info_message` ([#66745](rust-lang/rust#66745))
  * `fs_try_exists` ([#83186](rust-lang/rust#83186))
  * `lint_reasons` ([#120924](rust-lang/rust#120924))
  * `duration_abs_diff` ([#117618](rust-lang/rust#117618))
  * `effects` ([#102090](rust-lang/rust#102090))
* New `clippy` lints:
  * `manual_inspect` ([#12287](rust-lang/rust-clippy#12287))
  * `manual_pattern_char_comparison` ([#12849](rust-lang/rust-clippy#12849))
* Other:
  * `NEVER_TYPE_FALLBACK_FLOWING_INTO_UNSAFE` became a deny-by-default lint ([#126881](rust-lang/rust#126881) & [#123748](rust-lang/rust#123748))
  * Changes to `stringify!` introducing whitespaces between some tokens ([#125174](rust-lang/rust#125174))
  * `format!` is now marked with a `must_use` hint ([#127355](rust-lang/rust#127355))

ignore-conflict-markers

Reviewed By: zertosh, dtolnay

Differential Revision: D63864870

fbshipit-source-id: c8d61f3e9483ec709c8116514cfb030c883ec262
facebook-github-bot pushed a commit to facebookexperimental/rust-shed that referenced this issue Oct 7, 2024
Summary:
Upgrading Rust from `1.80.1` to `1.81.0` ([release notes](https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html)) with the following changes affecting `fbsource`:
* Feature stabilizations:
  * `io_slice_advance` ([#62726](rust-lang/rust#62726))
  * `panic_info_message` ([#66745](rust-lang/rust#66745))
  * `fs_try_exists` ([#83186](rust-lang/rust#83186))
  * `lint_reasons` ([#120924](rust-lang/rust#120924))
  * `duration_abs_diff` ([#117618](rust-lang/rust#117618))
  * `effects` ([#102090](rust-lang/rust#102090))
* New `clippy` lints:
  * `manual_inspect` ([#12287](rust-lang/rust-clippy#12287))
  * `manual_pattern_char_comparison` ([#12849](rust-lang/rust-clippy#12849))
* Other:
  * `NEVER_TYPE_FALLBACK_FLOWING_INTO_UNSAFE` became a deny-by-default lint ([#126881](rust-lang/rust#126881) & [#123748](rust-lang/rust#123748))
  * Changes to `stringify!` introducing whitespaces between some tokens ([#125174](rust-lang/rust#125174))
  * `format!` is now marked with a `must_use` hint ([#127355](rust-lang/rust#127355))

ignore-conflict-markers

Reviewed By: zertosh, dtolnay

Differential Revision: D63864870

fbshipit-source-id: c8d61f3e9483ec709c8116514cfb030c883ec262
facebook-github-bot pushed a commit to facebookincubator/buck2-change-detector that referenced this issue Oct 7, 2024
Summary:
Upgrading Rust from `1.80.1` to `1.81.0` ([release notes](https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html)) with the following changes affecting `fbsource`:
* Feature stabilizations:
  * `io_slice_advance` ([#62726](rust-lang/rust#62726))
  * `panic_info_message` ([#66745](rust-lang/rust#66745))
  * `fs_try_exists` ([#83186](rust-lang/rust#83186))
  * `lint_reasons` ([#120924](rust-lang/rust#120924))
  * `duration_abs_diff` ([#117618](rust-lang/rust#117618))
  * `effects` ([#102090](rust-lang/rust#102090))
* New `clippy` lints:
  * `manual_inspect` ([#12287](rust-lang/rust-clippy#12287))
  * `manual_pattern_char_comparison` ([#12849](rust-lang/rust-clippy#12849))
* Other:
  * `NEVER_TYPE_FALLBACK_FLOWING_INTO_UNSAFE` became a deny-by-default lint ([#126881](rust-lang/rust#126881) & [#123748](rust-lang/rust#123748))
  * Changes to `stringify!` introducing whitespaces between some tokens ([#125174](rust-lang/rust#125174))
  * `format!` is now marked with a `must_use` hint ([#127355](rust-lang/rust#127355))

ignore-conflict-markers

Reviewed By: zertosh, dtolnay

Differential Revision: D63864870

fbshipit-source-id: c8d61f3e9483ec709c8116514cfb030c883ec262
facebook-github-bot pushed a commit to facebook/starlark-rust that referenced this issue Oct 7, 2024
Summary:
Upgrading Rust from `1.80.1` to `1.81.0` ([release notes](https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html)) with the following changes affecting `fbsource`:
* Feature stabilizations:
  * `io_slice_advance` ([#62726](rust-lang/rust#62726))
  * `panic_info_message` ([#66745](rust-lang/rust#66745))
  * `fs_try_exists` ([#83186](rust-lang/rust#83186))
  * `lint_reasons` ([#120924](rust-lang/rust#120924))
  * `duration_abs_diff` ([#117618](rust-lang/rust#117618))
  * `effects` ([#102090](rust-lang/rust#102090))
* New `clippy` lints:
  * `manual_inspect` ([#12287](rust-lang/rust-clippy#12287))
  * `manual_pattern_char_comparison` ([#12849](rust-lang/rust-clippy#12849))
* Other:
  * `NEVER_TYPE_FALLBACK_FLOWING_INTO_UNSAFE` became a deny-by-default lint ([#126881](rust-lang/rust#126881) & [#123748](rust-lang/rust#123748))
  * Changes to `stringify!` introducing whitespaces between some tokens ([#125174](rust-lang/rust#125174))
  * `format!` is now marked with a `must_use` hint ([#127355](rust-lang/rust#127355))

ignore-conflict-markers

Reviewed By: zertosh, dtolnay

Differential Revision: D63864870

fbshipit-source-id: c8d61f3e9483ec709c8116514cfb030c883ec262
facebook-github-bot pushed a commit to facebookincubator/reindeer that referenced this issue Oct 7, 2024
Summary:
Upgrading Rust from `1.80.1` to `1.81.0` ([release notes](https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html)) with the following changes affecting `fbsource`:
* Feature stabilizations:
  * `io_slice_advance` ([#62726](rust-lang/rust#62726))
  * `panic_info_message` ([#66745](rust-lang/rust#66745))
  * `fs_try_exists` ([#83186](rust-lang/rust#83186))
  * `lint_reasons` ([#120924](rust-lang/rust#120924))
  * `duration_abs_diff` ([#117618](rust-lang/rust#117618))
  * `effects` ([#102090](rust-lang/rust#102090))
* New `clippy` lints:
  * `manual_inspect` ([#12287](rust-lang/rust-clippy#12287))
  * `manual_pattern_char_comparison` ([#12849](rust-lang/rust-clippy#12849))
* Other:
  * `NEVER_TYPE_FALLBACK_FLOWING_INTO_UNSAFE` became a deny-by-default lint ([#126881](rust-lang/rust#126881) & [#123748](rust-lang/rust#123748))
  * Changes to `stringify!` introducing whitespaces between some tokens ([#125174](rust-lang/rust#125174))
  * `format!` is now marked with a `must_use` hint ([#127355](rust-lang/rust#127355))

ignore-conflict-markers

Reviewed By: zertosh, dtolnay

Differential Revision: D63864870

fbshipit-source-id: c8d61f3e9483ec709c8116514cfb030c883ec262
facebook-github-bot pushed a commit to facebookexperimental/allocative that referenced this issue Oct 7, 2024
Summary:
Upgrading Rust from `1.80.1` to `1.81.0` ([release notes](https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html)) with the following changes affecting `fbsource`:
* Feature stabilizations:
  * `io_slice_advance` ([#62726](rust-lang/rust#62726))
  * `panic_info_message` ([#66745](rust-lang/rust#66745))
  * `fs_try_exists` ([#83186](rust-lang/rust#83186))
  * `lint_reasons` ([#120924](rust-lang/rust#120924))
  * `duration_abs_diff` ([#117618](rust-lang/rust#117618))
  * `effects` ([#102090](rust-lang/rust#102090))
* New `clippy` lints:
  * `manual_inspect` ([#12287](rust-lang/rust-clippy#12287))
  * `manual_pattern_char_comparison` ([#12849](rust-lang/rust-clippy#12849))
* Other:
  * `NEVER_TYPE_FALLBACK_FLOWING_INTO_UNSAFE` became a deny-by-default lint ([#126881](rust-lang/rust#126881) & [#123748](rust-lang/rust#123748))
  * Changes to `stringify!` introducing whitespaces between some tokens ([#125174](rust-lang/rust#125174))
  * `format!` is now marked with a `must_use` hint ([#127355](rust-lang/rust#127355))

ignore-conflict-markers

Reviewed By: zertosh, dtolnay

Differential Revision: D63864870

fbshipit-source-id: c8d61f3e9483ec709c8116514cfb030c883ec262
facebook-github-bot pushed a commit to facebook/hhvm that referenced this issue Oct 7, 2024
Summary:
Upgrading Rust from `1.80.1` to `1.81.0` ([release notes](https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html)) with the following changes affecting `fbsource`:
* Feature stabilizations:
  * `io_slice_advance` ([#62726](rust-lang/rust#62726))
  * `panic_info_message` ([#66745](rust-lang/rust#66745))
  * `fs_try_exists` ([#83186](rust-lang/rust#83186))
  * `lint_reasons` ([#120924](rust-lang/rust#120924))
  * `duration_abs_diff` ([#117618](rust-lang/rust#117618))
  * `effects` ([#102090](rust-lang/rust#102090))
* New `clippy` lints:
  * `manual_inspect` ([#12287](rust-lang/rust-clippy#12287))
  * `manual_pattern_char_comparison` ([#12849](rust-lang/rust-clippy#12849))
* Other:
  * `NEVER_TYPE_FALLBACK_FLOWING_INTO_UNSAFE` became a deny-by-default lint ([#126881](rust-lang/rust#126881) & [#123748](rust-lang/rust#123748))
  * Changes to `stringify!` introducing whitespaces between some tokens ([#125174](rust-lang/rust#125174))
  * `format!` is now marked with a `must_use` hint ([#127355](rust-lang/rust#127355))

ignore-conflict-markers

Reviewed By: zertosh, dtolnay

Differential Revision: D63864870

fbshipit-source-id: c8d61f3e9483ec709c8116514cfb030c883ec262
facebook-github-bot pushed a commit to facebookincubator/gazebo that referenced this issue Oct 7, 2024
Summary:
Upgrading Rust from `1.80.1` to `1.81.0` ([release notes](https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html)) with the following changes affecting `fbsource`:
* Feature stabilizations:
  * `io_slice_advance` ([#62726](rust-lang/rust#62726))
  * `panic_info_message` ([#66745](rust-lang/rust#66745))
  * `fs_try_exists` ([#83186](rust-lang/rust#83186))
  * `lint_reasons` ([#120924](rust-lang/rust#120924))
  * `duration_abs_diff` ([#117618](rust-lang/rust#117618))
  * `effects` ([#102090](rust-lang/rust#102090))
* New `clippy` lints:
  * `manual_inspect` ([#12287](rust-lang/rust-clippy#12287))
  * `manual_pattern_char_comparison` ([#12849](rust-lang/rust-clippy#12849))
* Other:
  * `NEVER_TYPE_FALLBACK_FLOWING_INTO_UNSAFE` became a deny-by-default lint ([#126881](rust-lang/rust#126881) & [#123748](rust-lang/rust#123748))
  * Changes to `stringify!` introducing whitespaces between some tokens ([#125174](rust-lang/rust#125174))
  * `format!` is now marked with a `must_use` hint ([#127355](rust-lang/rust#127355))

ignore-conflict-markers

Reviewed By: zertosh, dtolnay

Differential Revision: D63864870

fbshipit-source-id: c8d61f3e9483ec709c8116514cfb030c883ec262
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-error-handling Area: Error handling B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. 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. Libs-Tracked Libs issues that are tracked on the team's project board. PG-error-handling Project group: Error handling (https://github.com/rust-lang/project-error-handling) T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.