Stream: project-error-handling

Topic: Meeting 2020-10-12


view this post on Zulip Jane Lusby (Oct 12 2020 at 17:57):

Agenda: https://hackmd.io/@rust-libs/SkPmShkLD

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:00):

Alrighty, time to get started

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:01):

ping @Sean Chen to confirm you're around and taking minutes

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:01):

also @Jakub Duchniewicz for the status update on type_id once we get to that

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:01):

I think everyone else has already waved

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:02):

I added an agenda item for anything we'd like to raise in the Libs meeting later this week

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:02):

okay so I'll start with the backtrace in core, I got a fair bit of work done on that the week before last, I got to the point where it was compiling but so far have not solved certain issues around how to actually implement the hooks

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:03):

last week I didn't have any time to work on it unfortunately

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:03):

so far though everything seems to be moving forward just fine, I don't for see any issues, though admittedly there are a few unanswered questions around the hooks themselves

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:03):

What issues did you hit around the hooks?

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:04):

I haven't actually implemented them before :)

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:04):

mainly how to set one up, and in particular how to provide a default hook for no_std environments because I'm assuming we don't want to require no_std crates setup the backtrace equivalent of #[panic_handler] themselves

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:06):

that's pretty much it for the backtrace in core work so far

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:06):

next up is "Setup The Rust Error Book,

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:06):

Ah ok. I'm not sure what we need to do there. Would you like some more :eyes: on it? Sorry if you already posted a link to a branch somewhere :smile:

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:07):

oh, let me grab the link rn

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:07):

eyes wouldn't be minded, though rn its still early

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:07):

tho I think some of the unsafe code I wrote is almost certainly wrong, lol

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:08):

https://github.com/rust-lang/rust/pull/77384

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:08):

okay so, I believe @must-compute setup the book in our repo

view this post on Zulip oliver (Oct 12 2020 at 18:08):

This is different than the other work on the backtrace api?

view this post on Zulip must-compute (Oct 12 2020 at 18:08):

yeah we have a folder for adding book content now

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:09):

yes @oliver

view this post on Zulip oliver (Oct 12 2020 at 18:09):

How are they related?

view this post on Zulip oliver (Oct 12 2020 at 18:10):

I was reviewing this: https://github.com/rust-lang/rust/pull/64154

view this post on Zulip Sean Chen (he/him) (Oct 12 2020 at 18:10):

Sorry, was running a bit late. Here now and taking minutes :)

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:10):

this work is about exporting the entire Backtrace interface from core in a way that doesn't depend on alloc, that one is about adding the Backtrace module to std itself

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:10):

@oliver Supporting backtraces in core :sparkles: somehow :sparkles: was raised as a blocker to stabilizing that API

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:10):

lol, somehow

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:11):

it was me, im sorry

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:11):

I'm more and more convinced that it won't be a blocker though

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:11):

if there's nothing else blocking it I wonder if we might be able to start the stabilization process

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:12):

I'm assuming it will still take months to hit stable, and that we could back it out if issues are discovered

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:12):

might be something to bring up in the next libs meeting @Ashley Mannix ?

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:12):

@Jane Lusby I'll drop a ping on https://github.com/rust-lang/rust/pull/72981 and add it to our Libs meeting

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:12):

awesome

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:12):

alrighty

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:13):

next up is the blog post detailing our long term vision / goals, how's that going @Sean Chen?

view this post on Zulip Lokathor (Oct 12 2020 at 18:14):

once the stabilization PR is merged it's two releases to stable, so 7-12 weeks or so.

view this post on Zulip Sean Chen (he/him) (Oct 12 2020 at 18:14):

I have a draft here: https://hackmd.io/GMLcORX_R7W4de0ZryDIxg?view

view this post on Zulip Sean Chen (he/him) (Oct 12 2020 at 18:15):

Would like additional eyes on it to get thoughts :)

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:15):

I'll start reviewing that after this meeting

view this post on Zulip Jakub Duchniewicz (Oct 12 2020 at 18:15):

I will also give my feedback just after the meeting

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:15):

Alright

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:15):

onto status updates of the in progress PRs

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:15):

Me too :+1: @Sean Chen I'll add you to the HackMD so you can create notes in the Libs group too

view this post on Zulip Sean Chen (he/him) (Oct 12 2020 at 18:16):

Awesome, thanks y'all! :)

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:16):

Generic Member Access is first

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:16):

so I need to update the RFC a little because @Nika Layzell updated her object-provider crate to have a nicer API

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:17):

so I'd like to include that version in the RFC, but other than that its basically stuck in limbo

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:17):

The next step seems to be "get it approved"

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:17):

@Jane Lusby Does it need some libs input too?

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:17):

yes, though that should wait until I've updated the RFC to include the latest object-provider API

view this post on Zulip Jeremiah Senkpiel (Oct 12 2020 at 18:17):

Is this "attach arbitrary data to an Error"?

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:18):

other way around, its access arbitrary data from an error

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:18):

so its a generic superset of source and backtrace

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:18):

where source() = err.context::<&dyn Error + 'static>()

view this post on Zulip Jeremiah Senkpiel (Oct 12 2020 at 18:19):

Interesting. I will note that Tide presently goes the opposite route: access arbitrary error from a http Response.

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:19):

not following

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:19):

can you show me after the meeting?

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:20):

moving on though, next up is Fix the error trait / Stabilizing Backtrace

view this post on Zulip Jeremiah Senkpiel (Oct 12 2020 at 18:20):

(Continue on, I'll comment if in the RFC if it's relevant)

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:21):

I guess we covered that one a bit already?

view this post on Zulip oliver (Oct 12 2020 at 18:21):

Jane Lusby said:

moving on though, next up is Fix the error trait / Stabilizing Backtrace

https://github.com/rust-lang/rust/issues/53487

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:21):

that's currently blocked on the core in backtrace work that we already talked about so I don't think there's much more to add there, and based on earlier discussion in this meeting we may go ahead and start the stabilization work for backtrace which is I think the last bit of Fix the error trait

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:21):

tho I didn't remember to double check the issue before the meeting so I might be missing something

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:21):

There's an open PR for stabilizing backtrace: https://github.com/rust-lang/rust/pull/72981

view this post on Zulip oliver (Oct 12 2020 at 18:22):

I'm confused with all the different backtraces lol

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:22):

so it looks like we might need to do some documentation work

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:23):

oliver said:

I'm confused with all the different backtraces lol

im sorry :grimacing:

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:23):

alright so next up is @oliver on "stabilizing error source iterators"

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:23):

looks like you already added some info on that to the agenda items

view this post on Zulip oliver (Oct 12 2020 at 18:24):

yeah there's the basics there, it's a rather deep item

view this post on Zulip DPC (Oct 12 2020 at 18:24):

isn't that pending on a poc to core?

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:24):

I don't think so?

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:24):

but the trait object vs provided methods comment makes me think it might matter

view this post on Zulip oliver (Oct 12 2020 at 18:24):

I think it's waiting for some other stabilization and there is disagreement in the comments

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:25):

tho any issues introduced there wouldn't be any worse than the existing issues with downcast

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:25):

I haven't caught up on it recently, but I think there were some design decisions to be made on things like whether the iterators include the current error

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:25):

I see, how could we help with making that decision?

view this post on Zulip oliver (Oct 12 2020 at 18:26):

Fix the error trait?

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:26):

_wondering if we could do a write-up of the pros and cons and make a recommendation or something_

view this post on Zulip DPC (Oct 12 2020 at 18:26):

my comment was with respect to https://github.com/rust-lang/rust/pull/72981#issuecomment-638965446

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:26):

oh wait, thats for backtrace and error in core

view this post on Zulip DPC (Oct 12 2020 at 18:26):

ah ok

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:26):

we're on source iterators rn

view this post on Zulip oliver (Oct 12 2020 at 18:27):

Basically we know that an Iterator imp over Error:source() is possible and desirable to users

view this post on Zulip oliver (Oct 12 2020 at 18:27):

The convenience of the interface is problematic

view this post on Zulip oliver (Oct 12 2020 at 18:28):

And there are a ton of related issues at varying stages of progress

view this post on Zulip Jeremiah Senkpiel (Oct 12 2020 at 18:28):

What do you mean by "the convenience is problematic"?

view this post on Zulip oliver (Oct 12 2020 at 18:28):

Most notably as far as I can tell is fixing the error trait

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:28):

when you say fixing the error trait what are you referring to?

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:29):

The other issue I see blocking stability (aside from the name) is the T: Error vs dyn Error issue. For reasons that are beyond annoying, Box<dyn Error> does not implement Error. This makes whether methods are implemented for dyn Error or T: Error matter in really annoying ways.

Hmm, I wonder if https://github.com/rust-lang/rust/pull/75180 feeds into this at all

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:29):

afaik the only way those are related is the source fn which was added by that RFC

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:29):

and thats already on stable

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:29):

It would be good to talk about https://github.com/rust-lang/rust/pull/75180 sometime :smile:

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:29):

agreed

view this post on Zulip oliver (Oct 12 2020 at 18:30):

Jeremiah Senkpiel said:

What do you mean by "the convenience is problematic"?

It appears to be a conflict between introducing a trait object vs. providing a new method, there is some spaghetti'ing and awkward borrow syntax, etc, in some of the designs

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:30):

makes sense

view this post on Zulip oliver (Oct 12 2020 at 18:31):

Jane Lusby said:

when you say fixing the error trait what are you referring to?

It seems to be pointing to RFC #2504

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:33):

okay, it seems like we should resolve the fix the error trait RFC first and foremost then, and revisit the source iterator issue once that is done

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:33):

does that sound accurate @oliver ?

view this post on Zulip Jeremiah Senkpiel (Oct 12 2020 at 18:33):

it sounds like multiple things are blocked by "fix the Error trait" _(he says, probably restating the very obvious)_

view this post on Zulip oliver (Oct 12 2020 at 18:34):

it pushes the discussion out into a broader scope yes

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:35):

alright

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:36):

moving on, next up is stabilizing Error::type_id, @Jakub Duchniewicz whats the status of that issue?

view this post on Zulip Jakub Duchniewicz (Oct 12 2020 at 18:36):

No good news about stabilizing that unfortunately

view this post on Zulip Jakub Duchniewicz (Oct 12 2020 at 18:37):

There are several approaches to that but all of them seem to be waiting for other stabilizations/RFC's

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:37):

do you know which ones they're blocked on?

view this post on Zulip Jakub Duchniewicz (Oct 12 2020 at 18:37):

#[marker] trait stabilization https://github.com/rust-lang/rust/issues/29864

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:37):

Is that actually something we want to stabilize?

view this post on Zulip Jakub Duchniewicz (Oct 12 2020 at 18:37):

might as well paste all of my notes

view this post on Zulip Jakub Duchniewicz (Oct 12 2020 at 18:37):

negative trait impls
dynamic vtable type_id (like C++ typeid keyword) https://github.com/rust-lang/rfcs/pull/2580
final keyword -> no overriding of trait any more
new trait TypeInfo https://github.com/rust-lang/rfcs/pull/2738

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:38):

wow, that's a lot more involved than I expected, lol

view this post on Zulip Jakub Duchniewicz (Oct 12 2020 at 18:38):

final keyword approach and negative trait impls look most promising tho

view this post on Zulip Jeremiah Senkpiel (Oct 12 2020 at 18:39):

Is there an issue for final?

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:39):

As far as I know Error::type_id is a private detail to make downcasting work without an explicit + Any bound

view this post on Zulip Jeremiah Senkpiel (Oct 12 2020 at 18:39):

That is also what it appeared to be when I skimmed it.

view this post on Zulip Jakub Duchniewicz (Oct 12 2020 at 18:40):

@Jeremiah Senkpiel did not see any

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:40):

I'm concerned this one may be a bit of a rabbit hole that we don't want to focus on rn

view this post on Zulip Jakub Duchniewicz (Oct 12 2020 at 18:41):

That is also my feeling

view this post on Zulip Jakub Duchniewicz (Oct 12 2020 at 18:41):

marked as unsound

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:41):

it might be good to figure out what people would want to use type_id for and how big of an issue it not being stable is

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:41):

I've never needed it personally

view this post on Zulip Jakub Duchniewicz (Oct 12 2020 at 18:41):

From what I read it was up only for a very short window

view this post on Zulip Jakub Duchniewicz (Oct 12 2020 at 18:41):

until the vulnerability was reported

view this post on Zulip Jakub Duchniewicz (Oct 12 2020 at 18:42):

so judging from that, almost nobody uses it

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:42):

alright, then I say we back burner this issue

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:43):

Next up @DPC with PanicInfo::message

view this post on Zulip DPC (Oct 12 2020 at 18:43):

sorry haven't made any progress on that

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:43):

no worries, we'll punt that to next meeting

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:43):

did you still want to have it assigned to you?

view this post on Zulip DPC (Oct 12 2020 at 18:43):

was working on another unrelated pr but i can side track that for now and work on this

view this post on Zulip DPC (Oct 12 2020 at 18:43):

ye not an issue

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:43):

alrighty

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:44):

Then the last status update is from @Charles Ellis O'Riley Jr. on "nicer assert messages"

view this post on Zulip Charles Ellis O'Riley Jr. (Oct 12 2020 at 18:44):

Tracking issue for RFC 2011: nicer assert messages #44838 - Per the tracking issue,, assert! should be moved to a procedural macro defined in the compiler. I'll need some insight on how to get started on that. Secondly, I believe I know what's meant by a "nicer assert message". See some examples of what I believe is asked for:

let a = 1;
let b = 2;
assert!(a == b);
thread '<main>' panicked at 'assertion failed:
Expected: a == b
With expansion: 1 == 2'
With addition operators:

let a = 1;
let b = 1;
let c = 3;
assert!(a + b == c);
thread '<main>' panicked at 'assertion failed:
Expected: a + b == c
With expansion: 1 + 1 == 3'
Bool only:

let v = vec![0u8;1];
assert!(v.is_empty());
thread '<main>' panicked at 'assertion failed:
Expected: v.is_empty()'
With short-circuit:

assert!(true && false && true);
thread '<main>' panicked at 'assertion failed:
Expected: true && false && true
With expansion: true && false && (not evaluated)'
With bracket blocks:

let a = 1;
let b = 1;
let c = 3;
assert!({a + b} == c);
thread '<main>' panicked at 'assertion failed:
Expected: {a + b} == c
With expansion: 2 == 3'
With fallback:

let a = NonDebug{};
let b = NonDebug{};
assert!(a == b);
thread '<main>' panicked at 'assertion failed:
Expected: a == b
With expansion: (a) == (b)'

Any thoughts on this? I'm assuming that's what's expected after trying each example.

view this post on Zulip DPC (Oct 12 2020 at 18:45):

(you can use backticks to paste code in zulip for easier formatting :stuck_out_tongue: )

view this post on Zulip Charles Ellis O'Riley Jr. (Oct 12 2020 at 18:45):

?

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:45):

@Charles Ellis O'Riley Jr. so is the situation that the RFC has been approved but nobody has started an implementation?

view this post on Zulip Charles Ellis O'Riley Jr. (Oct 12 2020 at 18:45):

that's correct

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:46):

alright

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:46):

does anyone know if this needs to be written using the built-in compiler version of procedural macros or if this can / should be developed out of tree using proc-macros and syn?

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:47):

if the latter is okay then I'd definitely start by writing this as an external crate, assuming there isn't already a proof of concept impl somewhere

view this post on Zulip Lokathor (Oct 12 2020 at 18:47):

well if it's exported by core it would be adding dep to core, for one, which might not be a huge deal i guess

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:48):

if syn isn't already a build dep then I'm betting we probably don't want to add it as one

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:48):

but I really don't know

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:49):

either way, it seems like the next step is to work on implementing the RFC

view this post on Zulip Charles Ellis O'Riley Jr. (Oct 12 2020 at 18:49):

So, what are some questions to come from this that I can research?

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:50):

we should probably ask for mentorship instructions from the libs / lang / maybee compiler team on how to add a new proc-macro to std, assuming that isnt in the rustc-dev-guide or something

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:50):

and then we should just do the implementation

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:51):

10 minutes left

view this post on Zulip Charles Ellis O'Riley Jr. (Oct 12 2020 at 18:51):

thought about contacting the compiler team but wasn'tr sure.

view this post on Zulip DPC (Oct 12 2020 at 18:51):

i think that falls under t-libs-impl (subset of compiler folk)

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:51):

I'm guessing theres a zulip stream for them @DPC ?

view this post on Zulip DPC (Oct 12 2020 at 18:51):

nope

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:51):

I think we could do this in an external crate using proc macros with a sprinkling of specialization, but am not sure how similar that implementation would be to one baked in directly

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:51):

welp

view this post on Zulip DPC (Oct 12 2020 at 18:51):

if you wish @Charles Ellis O'Riley Jr. we can swap issues

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:53):

moving forward since we don't have much time left

view this post on Zulip Charles Ellis O'Riley Jr. (Oct 12 2020 at 18:53):

I really don't mind seeing this through. Assistance would be nice buty I'd like to see this completed.

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:53):

Last action item is adding an iterator API to backtrace

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:54):

afaik this is currently just starting out,

view this post on Zulip Sean Chen (he/him) (Oct 12 2020 at 18:54):

Looks like there's nothing for this at the moment, but I'd like to push it forward

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:54):

I had a quick look in the backtrace crate to see if it's come up before but didn't find anything

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:54):

It might be something to raise there first

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:55):

@Ashley Mannix do you think this would need an RFC?

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:56):

For inclusion in std I think it will eventually. But in the backtrace crate itself I think we can do anything

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:56):

it looks like the backtrace crate currently provides a frames() fn rather than an iterator API

view this post on Zulip DPC (Oct 12 2020 at 18:56):

yeah the crate doesn't need a rfc

view this post on Zulip Sean Chen (he/him) (Oct 12 2020 at 18:56):

So an RFC would simply propose integrating that functionality from the crate into std?

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:57):

I'm not sure we'd need to change what's in the backtrace crate at all

view this post on Zulip Sean Chen (he/him) (Oct 12 2020 at 18:57):

Sweet :)

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:57):

like, just exporting an identical fn frames(&self) -> &[BacktraceFrame] sounds sufficient to me

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:57):

:+1:

view this post on Zulip Ashley Mannix (Oct 12 2020 at 18:58):

I'd be ok adding that as an unstable API to Backtrace without an RFC to start with (I'd just do a FCP on the implementation itself)

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:58):

if anything that sounds better to me than adding an Iterator or IntoIterator impl directly to Backtrace

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:58):

awesome

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:58):

that sounds like a plan to me

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:59):

alright, 1 minute left

view this post on Zulip Jane Lusby (Oct 12 2020 at 18:59):

so I think we should call it here

view this post on Zulip Jakub Duchniewicz (Oct 12 2020 at 18:59):

Since my issue is on hold, I can work on something else :)

view this post on Zulip Jakub Duchniewicz (Oct 12 2020 at 18:59):

However, it seems like nothing surfaced as of today

view this post on Zulip oliver (Oct 12 2020 at 18:59):

I did come across a few random RFCs I think are related

view this post on Zulip oliver (Oct 12 2020 at 18:59):

Not sure about relevance

view this post on Zulip Jane Lusby (Oct 12 2020 at 19:00):

@Jakub Duchniewicz once this meeting is over ill setup the next meetings agenda and figure out all the action items we created today

view this post on Zulip oliver (Oct 12 2020 at 19:00):

https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md

view this post on Zulip Jane Lusby (Oct 12 2020 at 19:00):

@oliver definitely post them in the zulip and we can figure out if we should track them

view this post on Zulip oliver (Oct 12 2020 at 19:00):

https://github.com/rust-lang/rfcs/pull/2677

view this post on Zulip Jane Lusby (Oct 12 2020 at 19:00):

Thanks everyone for coming today

view this post on Zulip oliver (Oct 12 2020 at 19:00):

https://github.com/rust-lang/rfcs/pull/2593#issuecomment-706514374

view this post on Zulip Jane Lusby (Oct 12 2020 at 19:00):

cya in two weeks!

view this post on Zulip Charles Ellis O'Riley Jr. (Oct 12 2020 at 19:00):

np. thanks

view this post on Zulip oliver (Oct 12 2020 at 19:00):

https://github.com/rust-lang/wg-async-foundations/blob/6b423e0ca89b707534d942ac7d667a9d5f9af2f8/rfc-drafts/must_not_await_lint.md

view this post on Zulip oliver (Oct 12 2020 at 19:01):

https://crates.io/crates/error-chain

view this post on Zulip Jeremiah Senkpiel (Oct 12 2020 at 19:05):

Did we talk about "Box error alias" i.e. https://github.com/rust-lang/rfcs/pull/2820? Does anyone have a tl;dr on the status there?

view this post on Zulip Ashley Mannix (Oct 12 2020 at 19:06):

@Jeremiah Senkpiel It looks like that's blocked on giving the newtype error approach used by crates like anyhow a chance to mature

view this post on Zulip Ashley Mannix (Oct 12 2020 at 19:08):

We don't want both a type alias for type BoxedError = Box<dyn Error> and a newtype like struct BoxedError(Box<dyn Error>), so we don't want to commit to the type alias until we've gone further down the newtype approach in external libraries

view this post on Zulip Jeremiah Senkpiel (Oct 12 2020 at 19:09):

That's reasonable.


Last updated: Jan 26 2022 at 14:02 UTC