Skip to content
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

inference: remove ability to infer f(svec(a, b, c)...) #29935

Merged
merged 1 commit into from
Nov 13, 2018

Conversation

vtjnash
Copy link
Member

@vtjnash vtjnash commented Nov 5, 2018

It seems unlikely that this code pattern is used anywhere (since the code would need to literally syntactically call svec and immediately splat the result into another call--as shown above), and it is the last instance of this inference hack we have remaining (after the PartialTuple work). If some package does end up needing it, we can easily reimplement it much better (via adding PartialSimpleVector), but I strongly suspect this is effectively dead-code, and thus not worthwhile to maintain.

It seems unlikely that this code pattern is used anywhere, and it is the last instance of this inference hack
we have remaining (after the PartialTuple work). If some package does end up needing it,
we can reimplement it (via adding PartialSimpleVector), but I strongly suspect this is effectively dead-code,
and thus not worthwhile to maintain.
@vtjnash vtjnash added the compiler:inference Type inference label Nov 5, 2018
@Keno
Copy link
Member

Keno commented Nov 5, 2018

I assume we're still ok if the whole svec is Const. If so, this is fine with me.

@vtjnash
Copy link
Member Author

vtjnash commented Nov 5, 2018

Right, this only handled the exact syntax form above

@JeffBezanson
Copy link
Member

Actually I've been wondering if we should change the lowering of splatting to use svec instead of tuples. It might save a bunch of unnecessary tuple types.

@vtjnash vtjnash merged commit b4d8795 into master Nov 13, 2018
@vtjnash vtjnash deleted the jn/precise_container_type-remove-svec-hack branch November 13, 2018 05:11
@vtjnash
Copy link
Member Author

vtjnash commented Nov 13, 2018

Well, as I said, it's effectively dead code right now, and we can implement a better copy of it when and if we actually need it.

tkf pushed a commit to tkf/julia that referenced this pull request Nov 21, 2018
)

It seems unlikely that this code pattern is used anywhere, and it is the last instance of this inference hack
we have remaining (after the PartialTuple work). If some package does end up needing it,
we can reimplement it (via adding PartialSimpleVector), but I strongly suspect this is effectively dead-code,
and thus not worthwhile to maintain.
vtjnash added a commit that referenced this pull request Nov 28, 2018
Uses of this function previously assumed that all Slots were SSA.
Fortunately, we now just have one user (post #29935) and it has very simple requirements
so we can check conservatively for this case without loss of (much) accuracy.
vtjnash added a commit that referenced this pull request Nov 29, 2018
Uses of this function previously assumed that all Slots were SSA.
Fortunately, we now just have one user (post #29935) and it has very simple requirements
so we can check conservatively for this case without loss of (much) accuracy.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler:inference Type inference
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants