Stream: wg-ffi-unwind

Topic: #8


gnzlbg (Oct 13 2019 at 08:55, on Zulip):

The propagate-rust-panic-through-native-frame.md feels inconsistent and/or unsound.

gnzlbg (Oct 13 2019 at 08:56, on Zulip):

IIUC, even in the minimum viable feature version, extern "C unwind" functions can be called by foreign code, and follow the C ABI with native unwinding

gnzlbg (Oct 13 2019 at 08:57, on Zulip):

If that is correct, that file saying that some of the behavior at the other side of the FFI is undefined can only be a consequence of the extern "C unwind" function not actually following the ABI that it says it follows, which would make them unsound since that ABI can be used in safe Rust code

gnzlbg (Oct 13 2019 at 08:58, on Zulip):

For example, that file says that unwinding into native code is UB

gnzlbg (Oct 13 2019 at 08:58, on Zulip):

while simultaneously saying that those functions can unwind

gnzlbg (Oct 13 2019 at 09:00, on Zulip):

If the function can unwind in the Rust side just fine, then whether that unwinding exhibits UB on the native code itself or not depends on what the native code semantics are

gnzlbg (Oct 13 2019 at 09:00, on Zulip):

For example, that file devotes most of its lines to C++, saying that unwinding frames without or with destructors is UB, catch blocks are UB, etc.

gnzlbg (Oct 13 2019 at 09:01, on Zulip):

But most C++ implementation says that a "foreign" unwind into it can be catched in catch(...) blocks just fine, re-thrown, guarantees that destructors run in a particular order when that happens, etc. (there are some things that C++ says are UB for foreign code, but the file does not mention them though).

gnzlbg (Oct 13 2019 at 09:03, on Zulip):

So the only way in which the behavior could then be undefined in C++ is if extern "C unwind" functions do not actually follow the ABI that they say they do

gnzlbg (Oct 13 2019 at 09:04, on Zulip):

The root of the problem here is that this file tries to specifies what the behavior of other programming languages are.

gnzlbg (Oct 13 2019 at 09:04, on Zulip):

That's not up to us.

gnzlbg (Oct 13 2019 at 09:04, on Zulip):

And is as meaningful as the C++ standard specifying that evaluating the expression 2 + 2 in Rust is UB.

gnzlbg (Oct 13 2019 at 09:05, on Zulip):

When a foreign exception unwinds into a programming language, most (all?) unwinding ABIs leave it up to the language how to handle it

gnzlbg (Oct 13 2019 at 09:05, on Zulip):

The language can just abort, or it can unwind, or do something else like assume that it doesn't happen

gnzlbg (Oct 13 2019 at 09:07, on Zulip):

Independently of what that does, Rust cannot specify what that is for other languages, much less guarantee anything about it (e.g. guarantee that it doesn't change)

gnzlbg (Oct 13 2019 at 09:08, on Zulip):

The only thing Rust can do is specify how foreign exceptions are handled in Rust, and well, it could also forbid extern "C unwind" functions from being called from a different language than Rust, but that doesn't seem very useful.

Kyle Strand (Oct 14 2019 at 16:24, on Zulip):

Part of the specification of an unwinding mechanism _is_ what happens when code tries to interact with the exception object. The relevant implementation detail, I believe, is the personality function. I still need to spend some time researching how personality functions work, but it's my understanding that for C++ to be "well behaved" when trying to catch a Rust exception, there _is_ a burden on Rust to partially define that behavior.

Kyle Strand (Oct 14 2019 at 16:25, on Zulip):

And, of course, everything is "undefined" until we say otherwise, _even though_ in many cases we believe that the implementation should behave "safely".

Kyle Strand (Oct 14 2019 at 16:26, on Zulip):

Relatedly: I'm not sure I understand your last comment on the double-throw issue. You said something about defining the behavior of native (non-Rust) code when attempting to throw while a Rust panic is already in-flight; that actually does sound entirely out of Rust's hands to me, so I'm not sure why you think that's something Rust can define.

gnzlbg (Oct 15 2019 at 09:38, on Zulip):

but it's my understanding that for C++ to be "well behaved" when trying to catch a Rust exception, there _is_ a burden on Rust to partially define that behavior.

No, there isn't.

gnzlbg (Oct 15 2019 at 09:38, on Zulip):

The I in ABI stands for "interface"

gnzlbg (Oct 15 2019 at 09:38, on Zulip):

C++ doesn't care about the programming language the code it interfaces with is written in, as long as it properly implements the ABI

gnzlbg (Oct 15 2019 at 09:39, on Zulip):

The only thing Rust needs to define is whether it exposes a feature to conform to that ABI or not

gnzlbg (Oct 15 2019 at 09:40, on Zulip):

if it does, other code that uses the ABI "just works"
if it doesn't, one cannot interface with code that uses that ABI, so this isn't an issue

gnzlbg (Oct 15 2019 at 09:41, on Zulip):

So saying that "Rust implements the ABI correctly" while also saying that "Using this ABI triggers undefined behavior on code that expects this ABI" does not make sense to me at least

gnzlbg (Oct 15 2019 at 09:43, on Zulip):

The only way in which the second statement could be true, is if the first statement is false, because Rust would not implement the ABI correctly.

gnzlbg (Oct 15 2019 at 09:49, on Zulip):

And, of course, everything is "undefined" until we say otherwise, _even though_ in many cases we believe that the implementation should behave "safely".

This misses the point. The current proposal says "The behavior is defined as both doing X and being undefined".

gnzlbg (Oct 15 2019 at 09:49, on Zulip):

That's an inconsistent specification.

gnzlbg (Oct 15 2019 at 09:54, on Zulip):

I'm not sure I understand your last comment on the double-throw issue.

Which comment?

You said something about defining the behavior of native (non-Rust) code when attempting to throw while a Rust panic is already in-flight;

I doubt I said that, since I was very clear that Rust cannot specify anything about how other languages should work. The only thing Rust can specify is how Rust works, and for this particular feature, whether Rust supports the ABI or not.

gnzlbg (Oct 15 2019 at 09:55, on Zulip):

In particular, C++ already specifies what happens if an exception from any other programming language unwinds into C++, and that causes a double throw.

gnzlbg (Oct 15 2019 at 09:57, on Zulip):

There is nothing that we could say in Rust that would be incompatible with the C++ spec, since that would mean that that particular C++ code now needs to satisfy incompatible requirements

gnzlbg (Oct 15 2019 at 09:59, on Zulip):

Saying nothing would mean that as long as the C++ code doesn't triggern an error in the Rust and C++ abstract machines, everything is tight

gnzlbg (Oct 15 2019 at 10:00, on Zulip):

While explicitly saying that behavior that's defined by the ABI is undefined means that we don't implement the ABI correctly

nikomatsakis (Oct 15 2019 at 12:53, on Zulip):

That's not up to us.

Still catching up, but my thinking was this: there is some point at which the Rust panic propagates out from Rust -- at that point, we can say that it is UB. In particular, that we do not yet how the Rust panic will "present itself" on the other side. Given that we haven't defined that, there is no way that the other language could intercept it in a stable, reliable fashion.

gnzlbg (Oct 15 2019 at 13:02, on Zulip):

@nikomatsakis IIUC the intent is to say that the panic is propagated with an ABI

gnzlbg (Oct 15 2019 at 13:04, on Zulip):

The ABI spec must precisely say what that looks like, and all the common ones do.

gnzlbg (Oct 15 2019 at 13:05, on Zulip):

If the ABI spec says, this looks like this, and you can do A, B, C with it, but the Rust spec says "we don't guarantee how this looks and doing A, B, and C is UB" then Rust does not implement that ABI

gnzlbg (Oct 15 2019 at 13:08, on Zulip):

It might implement a "subset" of the ABI, maybe?

Kyle Strand (Oct 15 2019 at 13:23, on Zulip):

MSVC doesn't actually have a fully stable ABI here. And the C++ standard says nothing about foreign exceptions.

gnzlbg (Oct 15 2019 at 13:36, on Zulip):

MSVC doesn't, but the windows msvc targets do

gnzlbg (Oct 15 2019 at 13:37, on Zulip):

As in, when MSVC compiles C++ exceptions, these exceptions are described as "C++" exceptions IIUC

gnzlbg (Oct 15 2019 at 13:38, on Zulip):

So if you use two different incompatible MSVC toolchains to compile C++ code, and these code throws through the ABI

gnzlbg (Oct 15 2019 at 13:38, on Zulip):

how the exception is propagated through the ABI is guaranteed to work

gnzlbg (Oct 15 2019 at 13:38, on Zulip):

but since both pieces of code have different expectations of what a C++ exception is, things go wrong

Kyle Strand (Oct 15 2019 at 13:39, on Zulip):

....sort of. https://clang.llvm.org/docs/MSVCCompatibility.html

gnzlbg (Oct 15 2019 at 13:39, on Zulip):

This is the same thing that happens if Rust compiled with a different toolchain that's slightly incompatible interfaces with each other

Kyle Strand (Oct 15 2019 at 13:39, on Zulip):

Note that support for SEH is "partial"

gnzlbg (Oct 15 2019 at 13:39, on Zulip):

The problem is that clang wants its exceptions to be C++ exceptions

gnzlbg (Oct 15 2019 at 13:39, on Zulip):

as opposed to "foreign" exceptions

Kyle Strand (Oct 15 2019 at 13:41, on Zulip):

The C++ standard doesn't have a concept of "foreign" exceptions. So in that sense, their behavior is already "undefined" from a language spec point of view.

gnzlbg (Oct 15 2019 at 13:41, on Zulip):

The C++ standard doesn't allow calls to C to unwind either

gnzlbg (Oct 15 2019 at 13:41, on Zulip):

So if that's your argument, interfacing with C++ cannot ever work from Rust

Kyle Strand (Oct 15 2019 at 13:42, on Zulip):

I don't believe it explicitly says anything to that effect? Do you have a citation?

Kyle Strand (Oct 15 2019 at 13:42, on Zulip):

My point is that you seem to be discussing "implementation defined" behavior here.

gnzlbg (Oct 15 2019 at 13:42, on Zulip):

I posted it in the original thread, extern "C" functions in C++ are not required to support unwinding

Kyle Strand (Oct 15 2019 at 13:43, on Zulip):

Which original thread? Could you please just post it again here?

gnzlbg (Oct 15 2019 at 13:44, on Zulip):

The tracking issue with 500 comments that aren't shown by github and aren't searchable

gnzlbg (Oct 15 2019 at 13:44, on Zulip):

If you call a C function, and C doesn't allow those functions to unwind

gnzlbg (Oct 15 2019 at 13:44, on Zulip):

(nothing in the C standard says that's allowed)

gnzlbg (Oct 15 2019 at 13:44, on Zulip):

How could the C++ standard say that C function calls can unwind ?

gnzlbg (Oct 15 2019 at 13:44, on Zulip):

What could cause them to unwind?

gnzlbg (Oct 15 2019 at 13:46, on Zulip):

Either way, the current proposal doesn't say that the behavior is implementation-defined

gnzlbg (Oct 15 2019 at 13:46, on Zulip):

depending on what the ABI allows

gnzlbg (Oct 15 2019 at 13:47, on Zulip):

it says that it is undefined, and if that's incompatible with the ABI, then such platform cannot IMO be reported as supporting the feature

gnzlbg (Oct 15 2019 at 13:47, on Zulip):

Windows does support foreign exceptions as well

gnzlbg (Oct 15 2019 at 13:47, on Zulip):

that's the mechanism that longjmp uses there, which isn't treated as a C++ exception

Kyle Strand (Oct 15 2019 at 13:55, on Zulip):

extern "C" doesn't mean "a function conforming to the C standard" in either C++ or C. C++ must be able to invoke a C++ function that is defined in an extern "C" block, and C++ functions can unwind, so I don't believe the standard states or implies any connection between exceptions and linkage specification.

Kyle Strand (Oct 15 2019 at 13:57, on Zulip):

But I feel like we're a bit in the weeds here. When, in roadmap documents, RFCs, and the Reference, we say that something is "undefined", we mean it's not defined by Rust - yet.

gnzlbg (Oct 15 2019 at 13:58, on Zulip):

https://docs.microsoft.com/en-us/cpp/c-runtime-library/internal-crt-globals-and-functions?view=vs-2019 shows how the C++ unwind ABI is evolved for the target (e.g. if you consider __CxxFrameHandler, there are now __CxxFrameHandler2, __CxxFrameHandler3, and the latest release has a new __CxxFrameHandler4 API. The older symbols are still available, so can still be called, even when new functionality is added.

Kyle Strand (Oct 15 2019 at 13:58, on Zulip):

The point is not that rustc might somehow reach into C++ code and perform optimizations based on Rust's concept of UB.

gnzlbg (Oct 15 2019 at 13:59, on Zulip):

extern "C" doesn't mean "a function conforming to the C standard" in either C++ or C.

It does in C, which doesn't has a notion of unwinding.

gnzlbg (Oct 15 2019 at 13:59, on Zulip):

Nothing in the C standard says that a function can unwind. The only similar thing offered is a longjmp.

Kyle Strand (Oct 15 2019 at 13:59, on Zulip):

?? C doesn't have extern "C"

gnzlbg (Oct 15 2019 at 14:00, on Zulip):

No, but it could call a C++ function that unwinds, and the behavior is undefined according to the standard, even with -fexceptions

Kyle Strand (Oct 15 2019 at 14:00, on Zulip):

Once we are satisfied that the ABI is specified in an implementation-compatible way, then we can say that the behavior is "implementation defined"

Kyle Strand (Oct 15 2019 at 14:00, on Zulip):

Until then, we err on the side of caution, which is to say, "undefined"

gnzlbg (Oct 15 2019 at 14:00, on Zulip):

So I read that as "the behavior of "C unwind" is undefined if the function unwinds"

gnzlbg (Oct 15 2019 at 14:01, on Zulip):

that is, the compiler can assume that it does not happen

gnzlbg (Oct 15 2019 at 14:01, on Zulip):

Users cannot write code that unwinds through those

gnzlbg (Oct 15 2019 at 14:01, on Zulip):

It also does not implement the "native ABI of the platform" if the platform supports unwinding

Kyle Strand (Oct 15 2019 at 14:02, on Zulip):

That's why I added the bit about LLVM-UB. Yes, the behavior is undefined, but even though we haven't yet specified it, we don't want to let rustc optimize on the assumption that it can't happen.

gnzlbg (Oct 15 2019 at 14:02, on Zulip):

Still, this feature would need a motivation for which problem it intends to solve.

gnzlbg (Oct 15 2019 at 14:02, on Zulip):

With the current specification, it adds no value over extern "C"

gnzlbg (Oct 15 2019 at 14:03, on Zulip):

There is nothing valid that you can do with "C unwind" as proposed that cannot be done with extern "C"

Kyle Strand (Oct 15 2019 at 14:03, on Zulip):

The intent, for now, is only to prohibit aborting and inserting nounwind

Kyle Strand (Oct 15 2019 at 14:04, on Zulip):

But, yes, there is nothing defined-by-standardeze that can be done, yet.

gnzlbg (Oct 15 2019 at 14:04, on Zulip):

By "for now", do you mean that this is going to be the intent of the RFC?

Kyle Strand (Oct 15 2019 at 14:04, on Zulip):

Yes. Part of the purpose of this WG is to permit providing partial guarantees as part of the full development of the feature.

gnzlbg (Oct 15 2019 at 14:05, on Zulip):

I see.

gnzlbg (Oct 15 2019 at 14:05, on Zulip):

It's ok to disagree then.

gnzlbg (Oct 15 2019 at 14:07, on Zulip):

I don't think that an RFC that proposes a feature that adds no value can be reviewed.

gnzlbg (Oct 15 2019 at 14:07, on Zulip):

It's impossible to know if the trade-offs the RFC makes are correct if the value it adds is zero, or unknown.

gnzlbg (Oct 15 2019 at 14:09, on Zulip):

If you want to add an experimental ABI that doesn't have abort-on-panic shims, you don't need an RFC, just a PR to nightly with an FCP, or not even that.

Kyle Strand (Oct 15 2019 at 14:09, on Zulip):

The behavior of -fexceptions is undefined in a formal language-spec sense; do you not see value in that feature?

gnzlbg (Oct 15 2019 at 14:09, on Zulip):

The toolchain defines its behavior to something useful.

gnzlbg (Oct 15 2019 at 14:09, on Zulip):

So its undefined in C, but defined in GCC-C on Linux

Kyle Strand (Oct 15 2019 at 14:10, on Zulip):

Exactly. We want rustc to define the behavior here, to the extent that it can.

gnzlbg (Oct 15 2019 at 14:10, on Zulip):

Rust currently doesn't have any feature like this

gnzlbg (Oct 15 2019 at 14:10, on Zulip):

For similar features, the behavior is not specified as "undefined"

Kyle Strand (Oct 15 2019 at 14:10, on Zulip):

Indeed!

gnzlbg (Oct 15 2019 at 14:10, on Zulip):

but as "implementation-defined"

gnzlbg (Oct 15 2019 at 14:10, on Zulip):

and the sets of behaviors allowed is constrained by the RFC

Kyle Strand (Oct 15 2019 at 14:11, on Zulip):

It is possible that "implementation defined" is the best way to phrase this, but there was concern about this in RFC 2699, I think. One issue is that C++ formally defines the phrase "implementation defined", but as of right now, Rust does not.

gnzlbg (Oct 15 2019 at 14:12, on Zulip):

We already have a lot of implementation-defined behavior in Rust

gnzlbg (Oct 15 2019 at 14:12, on Zulip):

e.g. the size of an usize

Kyle Strand (Oct 15 2019 at 14:12, on Zulip):

We also don't necessarily want to guarantee that all implementations must define this behavior.

gnzlbg (Oct 15 2019 at 14:12, on Zulip):

So say that?

Kyle Strand (Oct 15 2019 at 14:12, on Zulip):

I'm not sure that counts, at least, not in the same sense

gnzlbg (Oct 15 2019 at 14:12, on Zulip):

Its the same thing.

gnzlbg (Oct 15 2019 at 14:13, on Zulip):

You can say: "C unwind" is an ABI string that's only available on certain targets and that implements the platform ABI call ABI with unwinding support when such an ABI exists.

Kyle Strand (Oct 15 2019 at 14:13, on Zulip):

usize refers to a basic concept that must exist on every platform, by definition

gnzlbg (Oct 15 2019 at 14:13, on Zulip):

If you try to use an ABI string on a target that doesn't support it, you get a compiler-error already

gnzlbg (Oct 15 2019 at 14:13, on Zulip):

Every Rust compiler is already required to diagnose that

gnzlbg (Oct 15 2019 at 14:17, on Zulip):

After such a definition like the above, you can go on and say whatever might make sense for what happens when such functions unwind into Rust.

gnzlbg (Oct 15 2019 at 14:18, on Zulip):

What I don't think makes much sense is to say that if a "C unwind" function unwinds, the behavior is undefined, because that means that, as proposed, such a feature does not add any value over extern "C"

gnzlbg (Oct 15 2019 at 14:19, on Zulip):

What you propose of only allowing those functions to unwind through Copy frames seems a very reasonable first step that adds a lot of value.

gnzlbg (Oct 15 2019 at 14:19, on Zulip):

And has none of the complications of double-panics.

gnzlbg (Oct 15 2019 at 14:20, on Zulip):

It also means that Rust panics can unwind out of Rust through that ABI, where they might do "whatever".

gnzlbg (Oct 15 2019 at 14:20, on Zulip):

On Itanium when unwinding into C++, C++ code can catch them, rethrow them, etc.

gnzlbg (Oct 15 2019 at 14:21, on Zulip):

On windows, C++ might or might not be able to do that. That's something for the C++ implementation of the platform to say.

nikomatsakis (Oct 15 2019 at 18:49, on Zulip):

OK, there are a lot of comments here, and it would be good to review them, but I still don't understand your original point, @gnzlbg . It seems to me that we can say "if a Rust panic occurs, we don't specify any details about how it is translated into native terms" and thus leave the behavior undefined at the point of crossing the boundary. I'm not expert on any of this stuff, but I'm sure every exception propagation mechanism has some kind of "structure" or way to specify metadata -- for example, the "personality" function or whatever -- and we are effectively saying that we have not defined this yet. Another way to look at it would be that extern "C unwind" as an ABI is simply not fully defined on any targets.

nikomatsakis (Oct 15 2019 at 18:52, on Zulip):

What I don't think makes much sense is to say that if a "C unwind" function unwinds, the behavior is undefined, because that means that, as proposed, such a feature does not add any value over extern "C"

Is this your main point? This is true, but it is a temporary state of affairs, which is the whole point. =)

nikomatsakis (Oct 15 2019 at 18:54, on Zulip):

It also means that Rust panics can unwind out of Rust through that ABI, where they might do "whatever".

As an example of the sort of thing I would prefer we leave "undefined" for the moment, when I skim the LLVM docs around exception handling, they state:

When execution resumes at a landing pad, it receives an exception structure and a selector value corresponding to the type of exception thrown.

presumably we might not yet want to define much about the "selector value" we use for Rust panics

Kyle Strand (Oct 15 2019 at 19:00, on Zulip):

OK, there are a lot of comments here, and it would be good to review them...

I wonder if it would be good to start writing up summaries of longish discussions like this and putting them in the repo.

In this case, I think the important points are all captured in comments on PR #8 in the repo, but I don't know if @gnzlbg would agree, necessarily.

gnzlbg (Oct 15 2019 at 19:00, on Zulip):

It seems to me that we can say "if a Rust panic occurs, we don't specify any details about how it is translated into native terms" and thus leave the behavior undefined at the point of crossing the boundary.

The translation from whatever mechanism Rust uses for unwinding is unspecified (because the Rust unwinding mechanism is unspecified), but this specifies that there is a translation to "native terms". How that translation happens doesn't matter. What matters is that those "native terms" are specified by the ABI spec.

gnzlbg (Oct 15 2019 at 19:01, on Zulip):

Maybe I should ask: What are we trying to achieve by making this undefined behavior ?

gnzlbg (Oct 15 2019 at 19:02, on Zulip):

presumably we might not yet want to define much about the "selector value" we use for Rust panics

For example, the Itanium ABI says that there is a unique C string for every programming language (kind of)

nikomatsakis (Oct 15 2019 at 19:03, on Zulip):

Maybe I should ask: What are we trying to achieve by making this undefined behavior ?

Perhaps the term "undefined behavior" is throwing you off. The point is that this behavior is not yet specified.

nikomatsakis (Oct 15 2019 at 19:03, on Zulip):

We are trying to break the work into pieces

gnzlbg (Oct 15 2019 at 19:03, on Zulip):

We don't have to say which string we use for Rust (probably just "Rust"), but if we were to use "C++", then C++ code would be expecting our code to be precisely C++ exceptions.

nikomatsakis (Oct 15 2019 at 19:04, on Zulip):

This is a perfect example. The behavior is effectively unspecified at this time because we don't say what string it will be.

nikomatsakis (Oct 15 2019 at 19:04, on Zulip):

So if you rely on that string to be a particular thing, you will have trouble.

nikomatsakis (Oct 15 2019 at 19:04, on Zulip):

Saying that the behavior is currently "undefined" is a maximal version of this.

gnzlbg (Oct 15 2019 at 19:04, on Zulip):

You can rely on it not being "C++" though

nikomatsakis (Oct 15 2019 at 19:04, on Zulip):

No, you cannot

nikomatsakis (Oct 15 2019 at 19:04, on Zulip):

Because we didn't say :)

gnzlbg (Oct 15 2019 at 19:04, on Zulip):

Then we don't implement the ABI spec :D

nikomatsakis (Oct 15 2019 at 19:04, on Zulip):

That's what I'm saying?

gnzlbg (Oct 15 2019 at 19:04, on Zulip):

Because it says we can only use "C++" if we implement "C++"

gnzlbg (Oct 15 2019 at 19:05, on Zulip):

I thought you were also saying that "C unwind" implements the native ABI

nikomatsakis (Oct 15 2019 at 19:06, on Zulip):

I'm saying that it's intention is to implement the native ABI, yes, but that its' behavior on any given platform is not yet fully defined -- and that we will take it platform by platform, but until your platform has a :check_mark: you can expect that details may change

gnzlbg (Oct 15 2019 at 19:06, on Zulip):

By undefined behavior I also understand that we make no guarantees. What I'm not 100% sure is where the documents say "undefined behavior" means that the RFC for this feature will say that, and therefore, no guarantees is part of the initial version of this feature. Or that we will define that behavior before that first RFC.

gnzlbg (Oct 15 2019 at 19:07, on Zulip):

If it's the second, I'd prefer to use TBD or similar

nikomatsakis (Oct 15 2019 at 19:07, on Zulip):

The latter, and TBD is perfectly fine

nikomatsakis (Oct 15 2019 at 19:07, on Zulip):

I find "not yet specified" also relatively clear

nikomatsakis (Oct 15 2019 at 19:07, on Zulip):

I also think RFC is not a relevant thing here

nikomatsakis (Oct 15 2019 at 19:08, on Zulip):

Like, RFCs are always an initial design in any case, and changes can and do happen

Kyle Strand (Oct 15 2019 at 19:08, on Zulip):

Maybe the more pertinent question is, "how much specification constitutes an MVP?"

gnzlbg (Oct 15 2019 at 19:08, on Zulip):

Sure, but for an RFC it is kind of important to know what problems the feature solve

gnzlbg (Oct 15 2019 at 19:08, on Zulip):

Yeah, I think that's something that we should all agree first

nikomatsakis (Oct 15 2019 at 19:09, on Zulip):

Yes. And the problem that the feature solves is that extern "C" is undefined behavior and expected to remain so -- and hence we may start to actively abort execution etc. extern "C unwind" is not expected to remain so

Kyle Strand (Oct 15 2019 at 19:09, on Zulip):

Sure, but for an RFC it is kind of important to know what problems the feature solve

I appreciate your concerns about stability/well-defined-ness, but I'm always a bit confused when you say something like this, because it seems to imply that the motivations for the feature are not well understood; from my perspective, they seem pretty well established.

nikomatsakis (Oct 15 2019 at 19:09, on Zulip):

I too feel a bit confused about what is confusing :)

nikomatsakis (Oct 15 2019 at 19:10, on Zulip):

Regardless, this all seems pretty moot

Kyle Strand (Oct 15 2019 at 19:10, on Zulip):

Are you distinguishing between "problems the feature solve" and "motivating use-cases for this feature"? If so, I don't understand the distinction

gnzlbg (Oct 15 2019 at 19:10, on Zulip):

Yes. And the problem that the feature solves is that extern "C" is undefined behavior and expected to remain so -- and hence we may start to actively abort execution etc. extern "C unwind" is not expected to remain so

That makes sense. I'm just skeptic of "placeholder language features"

gnzlbg (Oct 15 2019 at 19:10, on Zulip):

whose semantics are to be defined later

nikomatsakis (Oct 15 2019 at 19:10, on Zulip):

(In the sense that -- for the time being -- I would expect "C unwind" to be nightly only until we stabilize it.)

gnzlbg (Oct 15 2019 at 19:10, on Zulip):

For this kind of work, we can just add the ABI string, and remove nounwind, and that will work on nightly

gnzlbg (Oct 15 2019 at 19:11, on Zulip):

That would usually not even require an FCP

nikomatsakis (Oct 15 2019 at 19:11, on Zulip):

The point of the RFC is basically to commit to the design work

Kyle Strand (Oct 15 2019 at 19:11, on Zulip):

@gnzlbg It's my understanding that "undefined behavior" was originally (i.e. in the ANSII C standard) used in precisely the sense of "placeholder language features", at least in some cases! So in a sense using it that way is a return to the term's roots :D

gnzlbg (Oct 15 2019 at 19:11, on Zulip):

So my confusion is that I view this as the actual guarantees that such a stable feature would offer

gnzlbg (Oct 15 2019 at 19:12, on Zulip):

@nikomatsakis

The point of the RFC is basically to commit to the design work

So that sounds like an eRFC to me.

gnzlbg (Oct 15 2019 at 19:12, on Zulip):

Some general design direction, and the actual semantics will be nailed down down the road

nikomatsakis (Oct 15 2019 at 19:12, on Zulip):

We are designing a new process that replaces eRFCs, yes

nikomatsakis (Oct 15 2019 at 19:13, on Zulip):

Some general design direction, and the actual semantics will be nailed down down the road

also the point of the table and repo is to show what "the road" is

gnzlbg (Oct 15 2019 at 19:14, on Zulip):

So for an eRFC saying that we want to pursue "C unwind" and land part of an implementation on nightly to gain experience, and that we don't know what the semantics would be, I think is completely reasonable

nikomatsakis (Oct 15 2019 at 19:14, on Zulip):

I wonder if it would be good to start writing up summaries of longish discussions like this and putting them in the repo.

this seems very good btw

nikomatsakis (Oct 15 2019 at 19:14, on Zulip):

what I've found I try to do in long-ish zulip conversations

nikomatsakis (Oct 15 2019 at 19:14, on Zulip):

is to create hackmd documents on the fly

nikomatsakis (Oct 15 2019 at 19:14, on Zulip):

(not saying that would necessarily have made sense here)

gnzlbg (Oct 15 2019 at 19:15, on Zulip):

I think another reason I was confused is because the repo does have an rfc document.

nikomatsakis (Oct 15 2019 at 19:15, on Zulip):

Anyway, @gnzlbg it sounds like you might be well-postiioned to help in enumerating "what would need to be defined for ecah platform"

gnzlbg (Oct 15 2019 at 19:15, on Zulip):

I have a fork of the rfc document that provides the guarantees that I thought might be worth discussing for an MVP

nikomatsakis (Oct 15 2019 at 19:16, on Zulip):

sounds good -- I am certainly game to provide more guarantees than "none", though I don't really think it should hold up the intial RFC

nikomatsakis (Oct 15 2019 at 19:16, on Zulip):

basically I'd like us to reach agreement on "small things" first

nikomatsakis (Oct 15 2019 at 19:16, on Zulip):

which can include what we will reach agreement on later

gnzlbg (Oct 15 2019 at 19:16, on Zulip):

Maybe I can split that in different documents, where we collect motivating examples, constraints on the design, etc. that can be later on after discussion and consensus be put in an RFC, or at least used to show where do we want to end

Kyle Strand (Oct 15 2019 at 19:16, on Zulip):

I think another reason I was confused is because the repo does have an rfc document.

That's fair. To be honest I haven't even looked at that other than to note that the "summary" was something Niko, Adam, and I drafted together

nikomatsakis (Oct 15 2019 at 19:17, on Zulip):

I think the rest is just copied from the old RFC, and should be deleted

gnzlbg (Oct 15 2019 at 19:18, on Zulip):

I think we probably want to land an implementation before the actual RFC here, to get a feeling for the actual details

nikomatsakis (Oct 15 2019 at 19:19, on Zulip):

Yep!

gnzlbg (Oct 15 2019 at 19:19, on Zulip):

So it would probably better to start by getting lang team support for doing just that (all feature gated)

gnzlbg (Oct 15 2019 at 19:19, on Zulip):

After that we will know much better what's easy to guarantee and what's harder than we expected.

nikomatsakis (Oct 15 2019 at 19:19, on Zulip):

So the point of the RFC (as indicated by the summarY) is basically:

gnzlbg (Oct 15 2019 at 19:19, on Zulip):

The goal maybe could be initially to implement something that @Adam C. Foltzer could use

nikomatsakis (Oct 15 2019 at 19:20, on Zulip):

and then the next step (which is what we were working on) is to elaborate for ourselves the order of steps we plan to take

nikomatsakis (Oct 15 2019 at 19:20, on Zulip):

so yeah I think working towards goals like that is exactly right

nikomatsakis (Oct 15 2019 at 19:21, on Zulip):

So it would probably better to start by getting lang team support for doing just that (all feature gated)

to be clear, the lang team is already basically on board with this plan :)

gnzlbg (Oct 15 2019 at 19:21, on Zulip):

we may stabilize some aspects as we go (e.g., the ABI string, or certain platforms but not others)

So as long as these require a proper RFC this is fine with me.

nikomatsakis (Oct 15 2019 at 19:21, on Zulip):

I'm not sure what the procedural step is there

nikomatsakis (Oct 15 2019 at 19:21, on Zulip):

it might be a full RFC, it might also be an FCP

gnzlbg (Oct 15 2019 at 19:22, on Zulip):

So maybe we could replace some used of "undefined behavior" with "we don't know" ?

nikomatsakis (Oct 15 2019 at 19:22, on Zulip):

"not yet specified"?

nikomatsakis (Oct 15 2019 at 19:22, on Zulip):

"to be determined"?

nikomatsakis (Oct 15 2019 at 19:22, on Zulip):

I'd be happy with either of those

gnzlbg (Oct 15 2019 at 19:22, on Zulip):

TBD sounds good to me as well

nikomatsakis (Oct 15 2019 at 19:22, on Zulip):

ok, let's use TBD

nikomatsakis (Oct 15 2019 at 19:22, on Zulip):

where is that fork you mentioned, @gnzlbg ?

gnzlbg (Oct 15 2019 at 19:23, on Zulip):

that differentiates from things we might explicitly not want to support, for things that we just haven't considered yet

nikomatsakis (Oct 15 2019 at 19:23, on Zulip):

I would sort of like to see this proceeding a bit like UCG (but with more "confirmation" steps than we've mansged so foar)

nikomatsakis (Oct 15 2019 at 19:23, on Zulip):

i.e., we should have an "in-progress spec" per platform

gnzlbg (Oct 15 2019 at 19:23, on Zulip):

https://github.com/gnzlbg/project-ffi-unwind

nikomatsakis (Oct 15 2019 at 19:24, on Zulip):

where we can start with just notes about the platform

nikomatsakis (Oct 15 2019 at 19:24, on Zulip):

https://github.com/gnzlbg/project-ffi-unwind

this branch specifically? https://github.com/gnzlbg/project-ffi-unwind/tree/mvp_rfc

Kyle Strand (Oct 15 2019 at 19:35, on Zulip):

what's UCG?

gnzlbg (Oct 15 2019 at 19:39, on Zulip):

unsafe code guidelines

Kyle Strand (Oct 15 2019 at 20:28, on Zulip):

unsafe code guidelines

Ah, thanks

Kyle Strand (Oct 18 2019 at 16:01, on Zulip):

Is there a way to mark topics "resolved"?

Kyle Strand (Oct 18 2019 at 16:02, on Zulip):

I could mute it, but what I really want is a way to indicate to anyone just joining the stream that this topic is only of historical value at this point

gnzlbg (Oct 18 2019 at 16:44, on Zulip):

I think we should try to be more disciplined about properly using threads in zulip

gnzlbg (Oct 18 2019 at 16:45, on Zulip):

maybe you could change the title of the thread to indicate that ?

Kyle Strand (Oct 18 2019 at 16:55, on Zulip):

I haven't used Zulip prior to joining this stream; do you have any suggestions for what that "discipline" would comprise?

Kyle Strand (Oct 18 2019 at 16:55, on Zulip):

I generally feel that threads are under-utilized in Slack, so my preference is to err on the side of over-use here, then gracefully "expire" them somehow...I just don't see how that last step would work here (possibly because I lack sufficient admin permissions for the stream)

Kyle Strand (Oct 18 2019 at 16:56, on Zulip):

I do not see a way for me to change the topic title, but maybe Niko can

Kyle Strand (Oct 18 2019 at 16:57, on Zulip):

Even without the ability to archive topics, it might be good to pin some of them

Kyle Strand (Oct 18 2019 at 16:57, on Zulip):

I don't actually know if Zulip supports either feature

gnzlbg (Oct 18 2019 at 17:03, on Zulip):

So what I try to do is, everytime something is mentioned that's a different topic than what the current thread has, branch of a new thread (you can also move comments from a thread to a new one, so that can be cleaned up a bit afterwards as well)

gnzlbg (Oct 18 2019 at 17:04, on Zulip):

This does not make sense for all threads, e.g., a"meeting" thread contains a meeting

gnzlbg (Oct 18 2019 at 17:05, on Zulip):

To get a feeling maybe just hang out a bit in the t-compiler or other streams

Kyle Strand (Oct 18 2019 at 17:14, on Zulip):

I'll do that!

Kyle Strand (Oct 18 2019 at 17:15, on Zulip):

I.e. I'll hang out in those streams

Kyle Strand (Oct 18 2019 at 17:16, on Zulip):

Huh, seems like nothing really gets archived anywhere, e.g. stream:t-compiler topic:#52531-error-pattern-in-ui-tests

Last update: Nov 15 2019 at 10:40UTC