-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Explicit Tail Calls #3407
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
phi-go
wants to merge
97
commits into
rust-lang:master
Choose a base branch
from
phi-go:guaranteed-tco
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Explicit Tail Calls #3407
Changes from 1 commit
Commits
Show all changes
97 commits
Select commit
Hold shift + click to select a range
68572cc
[WIP] start writing an initial draft
59345b2
[WIP] keep writing on RFC
6d24e88
add some more TODOs
72209f8
rationale and alternatives
4beeedd
finish up rationale and alternatives
60c0242
fix some formatting issues
7fecbad
prior art add links
ff899fd
finish up prior-art
98dfe99
add reference-level explanation
6233cc3
add unresolved questions and future possibilities
dde8305
final pass
03bdd9f
update based on reviews
phi-go 30967a7
remove stray TODO
phi-go 53a15cc
add TailCall MIR node
phi-go ce069c4
update implementation
phi-go ae2f3b8
gcc supports require tail call
phi-go 377268e
indirect and external functions are supported
phi-go 046b5e4
whitespace changes
phi-go f8da276
fix grammar
phi-go 0d3589a
fix typo
phi-go 0d1c3bd
make section on difference between return and become clearer
phi-go 6f313d6
update use case 1 description
phi-go 9482ad2
reword impact
phi-go 3e7c384
improve wording of type checking section
phi-go 46d8db3
update example illustrating the difference between return and become
phi-go 12b028c
update comments on use case examples
phi-go b0c869e
correct grammar mistake
phi-go fd35d0f
change example in semantics section to ref
phi-go bef3933
rewrite to use TCE
e03c869
change feature name
phi-go 86ad37b
use the term TCE correctly
phi-go c55c189
add more unresolved questions
phi-go 77f93ac
update attribute on return section
phi-go 417aa48
fix wrong link
phi-go 9a24c19
add another reference to question regarding lints
phi-go f23c09e
expand on why operators are not supported
phi-go 8ab2fbd
simplify reference-level explanation
phi-go 0df947b
do another writing pass
phi-go 0abc63a
passing borrows of local variables is not allowed
phi-go b263a9d
add example for arguments that are calls
phi-go 70c0748
fix typo in example
phi-go d17ba51
reword sentence
phi-go 0b47449
merge borrow checking and difference sections
phi-go 1b4b6c2
do a grammar pass
phi-go 578b33f
improve accuracy of steps done by become
phi-go dae7085
fix mistake in drop order example
phi-go acef709
be more clear on where become can be used
phi-go e8df199
update description comparing return and become
phi-go 4dc10e8
add return become alternative
phi-go 3c20119
add alternative: explicit dropping of variables
phi-go f46aa13
fix date formatting
phi-go b6b3094
update with discussion on WebAssembly
phi-go 94916aa
update summary and motivation
phi-go ae758f5
update tail call elimination section
phi-go 2824fc9
use slice instead of list example
phi-go da261a4
update wording for use case 1
phi-go 5c2485e
update alternating example description
phi-go 0e4a645
add impl effort for explicit drop alternative
phi-go eeaa80c
resolving unresolved questions
phi-go 18ec62d
add resolved questions section
phi-go 36d4734
expand reference-level explanation
phi-go 7354862
remove unneeded comment
phi-go c647332
add type comment to example
phi-go e7bc960
update description of return type coercion
phi-go c5301f2
add pointer coercions
phi-go 12c495b
mismatches in mutability
phi-go 4b18487
update generators
phi-go b3dc340
update async
phi-go 3010c2e
add future possibilities to relax requirements
phi-go 60a290b
remove async as open question
phi-go 72f8e4a
remove open question on functions that abort
phi-go 980ebeb
fix typos
phi-go 51ecc12
update zig example
phi-go dfcf7e8
extend rationale and alternatives section
phi-go f7652a9
update async description
phi-go 0533221
update async description
phi-go 8706d7b
fix typo
phi-go 0b61f07
update reference-level explanation
phi-go b7c69e4
move mutability mismatch to future
phi-go 23106d2
add fn tokens
phi-go 2946d63
performance guarantee
phi-go cdac5c2
lint unresolved question to future possibilites
phi-go c7e4ea7
expand motivation section
phi-go b4b3db4
update wasm3 description
phi-go e548a96
Update wasm3 link
phi-go d38ba99
update motivation examples
phi-go d406786
Add RFC PR link and tracking issue link
phi-go 095fc54
Update text/0000-explicit-tail-calls.md
phi-go 8fafb63
Update text/0000-explicit-tail-calls.md
phi-go e4ccaa3
Add section on successors/combinators and improve local goto section
phi-go 5e34a7e
Update text/0000-explicit-tail-calls.md
phi-go 50bf9c1
Update text/0000-explicit-tail-calls.md
phi-go 4525906
Update 0000-explicit-tail-calls.md
phi-go 3304fee
Update description of support for GCC and WebAssembly
phi-go 33c76cd
Move track caller from pitfall to disallowed
phi-go 709c9b9
add tailcall not enabled by default for wasm32
phi-go 4dfb991
Update 0000-explicit-tail-calls.md
phi-go File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Move track caller from pitfall to disallowed
- Loading branch information
commit 33c76cdc353a1af8f29d72696f771305862d2581
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding
track_caller
should also not be breaking. So tail-calling atrack_caller
fn from a non-track_caller
should at most be a warning. (Note that the risk of unexpected stack growth is limited, because thetrack_caller
callee cannot itself usebecome
.)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to make sure, you mean adding
track_caller
to a tail-called function should not be breaking? So the equivalent of addingtrack_caller
?If that is what you meant, I'm a bit confused. On the one hand I can see that we want
track_caller
to be usable transparently but on the other hand tail calls are pretty much incompatible with the idea of tracking the caller anyway. Ignoring the matching function signature issue, what caller would you want tracked for a tail called function? So should this just be added as another action that is not allowed? Or should we movetrack_caller
into the "Unresolved questions" section as we need to figure out how this needs to work?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The call would have to go through the shim that is also used for function pointers, so no caller would be tracked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I didn't know there was precedent for this. If we are just not tracking the caller then we can allow tail calls into caller tracking functions, other than how I understood it. I'll move this to the drawbacks section as it is a complication we need to implement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated: 4dfb991
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The shim however is not going to be tail-calling the actual fn implementation. This means that if I have a track-caller and a non-tracker-caller and have them mutually tail-call each other, the stack usage would grow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nbdd0121 As I point out in the thread OP, the
#[track_caller]
function cannot itself usebecome
, so mutual tail calling is impossible.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The RFC was also updated earlier, let me know if anything is unclear.