Stream: project-ffi-unwind

Topic: #8


view this post on Zulip gnzlbg (Oct 13 2019 at 08:55):

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

view this post on Zulip gnzlbg (Oct 13 2019 at 08:56):

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

view this post on Zulip gnzlbg (Oct 13 2019 at 08:57):

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

view this post on Zulip gnzlbg (Oct 13 2019 at 08:58):

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

view this post on Zulip gnzlbg (Oct 13 2019 at 08:58):

while simultaneously saying that those functions can unwind

view this post on Zulip gnzlbg (Oct 13 2019 at 09:00):

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

view this post on Zulip gnzlbg (Oct 13 2019 at 09:00):

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.

view this post on Zulip gnzlbg (Oct 13 2019 at 09:01):

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).

view this post on Zulip gnzlbg (Oct 13 2019 at 09:03):

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

view this post on Zulip gnzlbg (Oct 13 2019 at 09:04):

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

view this post on Zulip gnzlbg (Oct 13 2019 at 09:04):

That's not up to us.

view this post on Zulip gnzlbg (Oct 13 2019 at 09:04):

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

view this post on Zulip gnzlbg (Oct 13 2019 at 09:05):

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

view this post on Zulip gnzlbg (Oct 13 2019 at 09:05):

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

view this post on Zulip gnzlbg (Oct 13 2019 at 09:07):

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)

view this post on Zulip gnzlbg (Oct 13 2019 at 09:08):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 14 2019 at 16:24):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 14 2019 at 16:25):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 14 2019 at 16:26):

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.

view this post on Zulip gnzlbg (Oct 15 2019 at 09:38):

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.

view this post on Zulip gnzlbg (Oct 15 2019 at 09:38):

The I in ABI stands for "interface"

view this post on Zulip gnzlbg (Oct 15 2019 at 09:38):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 09:39):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 09:40):

If Rust exposes such a feature other code that correctly conforms to the ABI "just works"

If Rust doesn't expose such a feature, one cannot interface with code that uses such an ABI in Rust, and the behavior for code that tries to do that is undefined (we provide no guaranteed way for this to work).

view this post on Zulip gnzlbg (Oct 15 2019 at 09:41):

The following two statements: "Rust implements the ABI correctly" and "Calling code that conforms to the ABI is UB" cannot be both true. The only way for the second statement to be true, is if the first statement is false.

view this post on Zulip gnzlbg (Oct 15 2019 at 09:43):

(deleted)

view this post on Zulip gnzlbg (Oct 15 2019 at 09:49):

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".

view this post on Zulip gnzlbg (Oct 15 2019 at 09:49):

That's an inconsistent specification.

view this post on Zulip gnzlbg (Oct 15 2019 at 09:54):

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.

view this post on Zulip gnzlbg (Oct 15 2019 at 09:55):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 09:57):

Saying something in Rust about how the code at the other side of the ABI should behave risks being a statement that Rust does not implement the ABI correctly.

view this post on Zulip gnzlbg (Oct 15 2019 at 09:59):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 10:00):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 12:53):

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.

view this post on Zulip gnzlbg (Oct 15 2019 at 13:02):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:04):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:05):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:08):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 13:23):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:36):

MSVC doesn't, but the windows msvc targets do

view this post on Zulip gnzlbg (Oct 15 2019 at 13:37):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:38):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:38):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:38):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 13:39):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:39):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 13:39):

Note that support for SEH is "partial"

view this post on Zulip gnzlbg (Oct 15 2019 at 13:39):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:39):

as opposed to "foreign" exceptions

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 13:41):

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.

view this post on Zulip gnzlbg (Oct 15 2019 at 13:41):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:41):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 13:42):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 13:42):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:42):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 13:43):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:44):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:44):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:44):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:44):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:44):

What could cause them to unwind?

view this post on Zulip gnzlbg (Oct 15 2019 at 13:46):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:46):

depending on what the ABI allows

view this post on Zulip gnzlbg (Oct 15 2019 at 13:47):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:47):

Windows does support foreign exceptions as well

view this post on Zulip gnzlbg (Oct 15 2019 at 13:47):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 13:55):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 13:57):

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.

view this post on Zulip gnzlbg (Oct 15 2019 at 13:58):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 13:58):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 13:59):

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.

view this post on Zulip gnzlbg (Oct 15 2019 at 13:59):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 13:59):

?? C doesn't have extern "C"

view this post on Zulip gnzlbg (Oct 15 2019 at 14:00):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 14:00):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 14:00):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 14:00):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 14:01):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 14:01):

Users cannot write code that unwinds through those

view this post on Zulip gnzlbg (Oct 15 2019 at 14:01):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 14:02):

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.

view this post on Zulip gnzlbg (Oct 15 2019 at 14:02):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 14:02):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 14:03):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 14:03):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 14:04):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 14:04):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 14:04):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 14:05):

I see.

view this post on Zulip gnzlbg (Oct 15 2019 at 14:05):

It's ok to disagree then.

view this post on Zulip gnzlbg (Oct 15 2019 at 14:07):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 14:07):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 14:09):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 14:09):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 14:09):

The toolchain defines its behavior to something useful.

view this post on Zulip gnzlbg (Oct 15 2019 at 14:09):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 14:10):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 14:10):

Rust currently doesn't have any feature like this

view this post on Zulip gnzlbg (Oct 15 2019 at 14:10):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 14:10):

Indeed!

view this post on Zulip gnzlbg (Oct 15 2019 at 14:10):

but as "implementation-defined"

view this post on Zulip gnzlbg (Oct 15 2019 at 14:10):

and the sets of behaviors allowed is constrained by the RFC

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 14:11):

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.

view this post on Zulip gnzlbg (Oct 15 2019 at 14:12):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 14:12):

e.g. the size of an usize

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 14:12):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 14:12):

So say that?

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 14:12):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 14:12):

Its the same thing.

view this post on Zulip gnzlbg (Oct 15 2019 at 14:13):

You can say: "C unwind" is an ABI string that's only available on certain targets and that implements the platform C ABI with unwinding support (e.g. C + -fexceptions), when such an ABI exists.

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 14:13):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 14:13):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 14:13):

Every Rust compiler is already required to diagnose that

view this post on Zulip gnzlbg (Oct 15 2019 at 14:17):

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.

view this post on Zulip gnzlbg (Oct 15 2019 at 14:18):

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"

view this post on Zulip gnzlbg (Oct 15 2019 at 14:19):

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.

view this post on Zulip gnzlbg (Oct 15 2019 at 14:19):

And has none of the complications of double-panics.

view this post on Zulip gnzlbg (Oct 15 2019 at 14:20):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 14:20):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 14:21):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 18:49):

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.

view this post on Zulip nikomatsakis (Oct 15 2019 at 18:52):

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. =)

view this post on Zulip nikomatsakis (Oct 15 2019 at 18:54):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 19:00):

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.

view this post on Zulip gnzlbg (Oct 15 2019 at 19:00):

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.

view this post on Zulip gnzlbg (Oct 15 2019 at 19:01):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 19:02):

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)

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:03):

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.

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:03):

We are trying to break the work into pieces

view this post on Zulip gnzlbg (Oct 15 2019 at 19:03):

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.

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:04):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:04):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:04):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 19:04):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:04):

No, you cannot

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:04):

Because we didn't say :)

view this post on Zulip gnzlbg (Oct 15 2019 at 19:04):

Then we don't implement the ABI spec :D

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:04):

That's what I'm saying?

view this post on Zulip gnzlbg (Oct 15 2019 at 19:04):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 19:05):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:06):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 19:06):

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.

view this post on Zulip gnzlbg (Oct 15 2019 at 19:07):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:07):

The latter, and TBD is perfectly fine

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:07):

I find "not yet specified" also relatively clear

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:07):

I also think RFC is not a relevant thing here

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:08):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 19:08):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 19:08):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 19:08):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:09):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 19:09):

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.

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:09):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:10):

Regardless, this all seems pretty moot

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 19:10):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 19:10):

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"

view this post on Zulip gnzlbg (Oct 15 2019 at 19:10):

whose semantics are to be defined later

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:10):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 19:10):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 19:11):

That would usually not even require an FCP

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:11):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 19:11):

@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

view this post on Zulip gnzlbg (Oct 15 2019 at 19:11):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 19:12):

@nikomatsakis

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

So that sounds like an eRFC to me.

view this post on Zulip gnzlbg (Oct 15 2019 at 19:12):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:12):

We are designing a new process that replaces eRFCs, yes

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:13):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 19:14):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:14):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:14):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:14):

is to create hackmd documents on the fly

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:14):

(not saying that would necessarily have made sense here)

view this post on Zulip gnzlbg (Oct 15 2019 at 19:15):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:15):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 19:15):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:16):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:16):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:16):

which can include what we will reach agreement on later

view this post on Zulip gnzlbg (Oct 15 2019 at 19:16):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 19:16):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:17):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 19:18):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:19):

Yep!

view this post on Zulip gnzlbg (Oct 15 2019 at 19:19):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 19:19):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:19):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 19:19):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:20):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:20):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:21):

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 :)

view this post on Zulip gnzlbg (Oct 15 2019 at 19:21):

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.

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:21):

I'm not sure what the procedural step is there

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:21):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 19:22):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:22):

"not yet specified"?

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:22):

"to be determined"?

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:22):

I'd be happy with either of those

view this post on Zulip gnzlbg (Oct 15 2019 at 19:22):

TBD sounds good to me as well

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:22):

ok, let's use TBD

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:22):

where is that fork you mentioned, @gnzlbg ?

view this post on Zulip gnzlbg (Oct 15 2019 at 19:23):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:23):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:23):

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

view this post on Zulip gnzlbg (Oct 15 2019 at 19:23):

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

view this post on Zulip nikomatsakis (Oct 15 2019 at 19:24):

where we can start with just notes about the platform

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 19:35):

what's UCG?

view this post on Zulip gnzlbg (Oct 15 2019 at 19:39):

unsafe code guidelines

view this post on Zulip BatmanAoD (Kyle Strand) (Oct 15 2019 at 20:28):

unsafe code guidelines

Ah, thanks


Last updated: Jan 26 2022 at 07:20 UTC