Fill in some text #2

BatmanAoD · 2019-10-04T23:32:56Z

The new content is mostly based on the HackMD doc.

BatmanAoD · 2019-10-04T23:33:40Z

README.md

+  - [acfoltzer](https://github.com/acfoltzer)
+  - [batmanaod (Kyle)](https://github.com/batmanaod)
+  - with guidance/assistance from [nikmoatsakis](https://github.com/nikmoatsakis)


Suggested change

- with guidance/assistance from [nikmoatsakis](https://github.com/nikmoatsakis)

- with guidance/assistance from [Niko](https://github.com/nikmoatsakis)

I think having our "handles" and our names is probably a good idea, though I think that matters most in my case, where there's no clear connection between my name and my handle.

nikomatsakis · 2019-10-08T17:53:18Z

faq.md

@@ -0,0 +1,32 @@
+## FAQ questions
+
+- Why use a new ABI? Why not an attribute?


Formatting nit: I think let's use ### headings (this also means people can link to the questions)

gnzlbg

The setjmp/longjmp section looks good but there are some minor issues open.

Also, I'm not sure that the claim that drop is always guaranteed to run in some platforms is true. I recall that on MSVC whether objects are drop on a longjmp depends on whether a function is inlined or not. For example, if you have something like:

fn foo() {
   if setjmp(jmpbuf) == 0 {
       bar()     
   }
}
fn bar() {
   let x: DropT;
   baz()
}
fn baz() { longjmp(jmpbuf, 1) }

and bar is not inlined, then the destructor of bar::x will run because the bar function is unwound by the longjmp implementation. However, if bar is inlined into foo, the longjmp does not unwind over the cleanup code of bar::x because it will be somewhere in foos stack frame, and that stack frame is not unwound, so the destructor for bar::x does not run.

gnzlbg · 2019-10-10T17:38:16Z

faq.md

+### How does cross-language unwinding differ from cross-language
+  `setjmp`/`longjmp`?
+- `setjmp`/`longjmp` across Rust frames is currently guaranteed not to have
+  undefined behavior or to `abort`


This is a weird way to say that the behavior of setjmp/longjmp is defined. Maybe just explain how their behavior is defined instead?

"Not undefined" is not equivalent to "is defined"; this is an (arguably unfortunate) legacy of the C/C++ ISO standards. Nico and I agree that Rust needs to better specify how "unspecified", "undefined", "implementation defined", etc are to be used in the Rust Reference and elsewhere in the Rust community, but at the moment, I felt that this was the safest phrasing, because "undefined behavior" is (ironically) the best-defined phrase at hand, as far as I can tell.

Sure, but what I'm saying is that the behavior of setjmp and longjmp in Rust is actually defined.

gnzlbg · 2019-10-10T17:40:21Z

faq.md

+- It should never be assumed that `drop` will be called for objects in
+  intermediate frames traversed by a `longjmp`, but this may occur on certain
+  platforms. Rust provides no guarantee either way. Conversely, on platforms
+  where unwinding is supported, it will always call `drop`.


What does this last sentence mean ? E.g. x86_64-unknown-linux-gnu is a platform where unwinding is supported, but longjmp never drops values living in stack frames. On other platforms like MSVC, do longjmps always drop values on stack frames?

Sorry, "it" here should have been "unwinding". You're right, this wasn't clear.

gnzlbg · 2019-10-10T17:41:32Z

faq.md

+- `setjmp`/`longjmp` across Rust frames is currently guaranteed not to have
+  undefined behavior or to `abort`
+- It should never be assumed that `drop` will be called for objects in
+  intermediate frames traversed by a `longjmp`, but this may occur on certain


If replacing a longjmp with a panic and a setjmp with a catch_unwind causes any destructors to run, the behavior is undefined. Some safe Rust abstractions like Pin rely on such things never happening.

Well, so much for my "safe" phrasing above! But this is sort of what I was worried about and why I don't want to just say that the behavior is defined. Wasn't it pointed out in one of the RFC threads that LLVM with the MSVC linker currently does generate code that causes longjmp to invoke destructors?

Wasn't it pointed out in one of the RFC threads that LLVM with the MSVC linker currently does generate code that causes longjmp to invoke destructors?

Since for the case being discussed the behavior is undefined, running destructors is one of the many things that could happen. Whatever LLVM does can change any time as a consequence of this, and IIRC whether destructors are run or not for particular functions depends on things like the optimization level.

gnzlbg · 2019-10-10T17:45:20Z

faq.md

+  where unwinding is supported, it will always call `drop`.
+- Rust does not have a concept of `Copy` for stack-frames, which would permit
+  the compiler to check that `longjmp` may safely traverse those frames. Such a
+  language feature may be added in the future, but although it would be useful


You can point to Centril/rfc-effects#11 if you want to add more context about what that would entail.

gnzlbg · 2019-10-10T17:45:40Z

faq.md

+  the compiler to check that `longjmp` may safely traverse those frames. Such a
+  language feature may be added in the future, but although it would be useful
+  for `longjmp`, it would not be useful for unwinding.
+- `setjmp`/`longjmp` does not involve data transfer (the exception object)


The return value of setjmp is a data-transfer from a longjmp.

Okay, that's true. I'll modify it to say that the only possible value that can be transferred is c_int.

Note that you can use the return value of setjmp to transfer any kind of payload via the heap, just like we do for unwinding (the payload of panic is behind a Box<dyn Any + ...>), by doing a heap allocation before the longjmp and putting the pointer to it in a thread-local, that can be accessed from the setjmp.

gnzlbg · 2019-10-10T17:46:04Z

faq.md

+  for `longjmp`, it would not be useful for unwinding.
+- `setjmp`/`longjmp` does not involve data transfer (the exception object)
+- unwinding involves the use of a personality function, which raises additional
+  cross-language compatibility concerns; `setjmp`/`longjmp` does not


The last sentence is unfinished.

Hm, I actually just wasn't consistent about putting periods at the end of bullet points.

So setjmp / longjmp have some requirements on how the language run-time works, e.g., the setjmp and longjmp must happen on the same thread, etc.

BatmanAoD · 2019-10-10T20:39:19Z

... claim that drop is always guaranteed to run in some platforms is true.

I am guessing you are referring to the part where I used "it" ambiguously, and that my response there resolves this concern?

gnzlbg · 2019-10-11T07:05:25Z

I am guessing you are referring to the part where I used "it" ambiguously, and that my response there resolves this concern?

Yes, that resolves it.

Kyle Strand added 3 commits October 4, 2019 17:19

Add FAQ

424b23e

Flesh out plan by copy-and-paste from discussion doc

c9863da

Some details and links in README

6c9b7bd

BatmanAoD commented Oct 4, 2019

View reviewed changes

Kyle Strand added 3 commits October 7, 2019 13:41

Add Adam & Niko first names

e28364a

demote 'what is a project'; add Josh T

0377e9a

Zulip link

d759792

nikomatsakis requested changes Oct 8, 2019

View reviewed changes

Formatting suggestion from code review

6adfb5a

nikomatsakis approved these changes Oct 8, 2019

View reviewed changes

nikomatsakis merged commit 604321c into rust-lang:master Oct 8, 2019

gnzlbg reviewed Oct 10, 2019

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fill in some text #2

Fill in some text #2

BatmanAoD commented Oct 4, 2019

BatmanAoD Oct 4, 2019

nikomatsakis Oct 8, 2019

gnzlbg left a comment

gnzlbg Oct 10, 2019

BatmanAoD Oct 10, 2019

gnzlbg Oct 11, 2019

gnzlbg Oct 10, 2019

BatmanAoD Oct 10, 2019

gnzlbg Oct 10, 2019

BatmanAoD Oct 10, 2019

gnzlbg Oct 11, 2019

gnzlbg Oct 10, 2019

gnzlbg Oct 10, 2019

BatmanAoD Oct 10, 2019

gnzlbg Oct 11, 2019

gnzlbg Oct 10, 2019

BatmanAoD Oct 10, 2019

gnzlbg Oct 11, 2019

BatmanAoD commented Oct 10, 2019

gnzlbg commented Oct 11, 2019

	- with guidance/assistance from [nikmoatsakis](https://github.com/nikmoatsakis)
	- with guidance/assistance from [Niko](https://github.com/nikmoatsakis)

		@@ -0,0 +1,32 @@
		## FAQ questions

		- Why use a new ABI? Why not an attribute?

Fill in some text #2

Fill in some text #2

Conversation

BatmanAoD commented Oct 4, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gnzlbg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BatmanAoD commented Oct 10, 2019

gnzlbg commented Oct 11, 2019