Skip to content

Conversation

jrose-apple
Copy link
Contributor

...instead of trying to guess it ourselves.

My previous attempt at this (part of the optional pointers work, bc83940) made a critical mistake because our only test case also referenced UIApplicationMain directly. I've made the test case test several more situations, and also added what would be an execution test if our simulator testing handled UI-based tests.

rdar://problem/25712303

Triggering Swift CI

The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:

Smoke Testing

Platform Comment
All supported platforms @swift-ci Please smoke test
OS X platform @swift-ci Please smoke test OS X platform
Linux platform @swift-ci Please smoke test Linux platform

Validation Testing

Platform Comment
All supported platforms @swift-ci Please test
OS X platform @swift-ci Please test OS X platform
Linux platform @swift-ci Please test Linux platform

Note: Only members of the Apple organization can trigger swift-ci.

@jrose-apple
Copy link
Contributor Author

@swift-ci Please test

@jckarter or @slavapestov, mind reviewing?

@jrose-apple
Copy link
Contributor Author

@swift-ci Please test

/*isForeign*/true};
auto UIApplicationMainFn = SGM.M.getOrCreateFunction(mainClass, mainRef,
NotForDefinition);
assert(UIApplicationMainFn && "failed to lower UIApplicationMain to SIL");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think getOrCreateFunction() can return nullptr, and if it did you would crash on the next line anyway, so I suggest removing this assert.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, removed.

@slavapestov
Copy link
Contributor

I don't see anything obviously wrong here, but I don't have enough knowledge of the underlying issue.

...instead of trying to guess it ourselves.

My previous attempt at this (part of the optional pointers work,
bc83940) made a critical mistake because our only test case /also/
referenced UIApplicationMain directly. I've made the test case test
several more situations, and also added what /would/ be an
execution test if our simulator testing handled UI-based tests.

rdar://problem/25712303
@jrose-apple jrose-apple merged commit ee1f150 into swiftlang:master Apr 14, 2016
@jrose-apple jrose-apple deleted the UIApplicationMain branch April 14, 2016 16:21
@jckarter
Copy link
Contributor

Looks reasonable. The _stdlib_UIApplicationMain stub approach didn't pan out?

@jrose-apple
Copy link
Contributor Author

I couldn't get it to reliably be force-inlined, although this morning I realized that was probably because the "inline me" flag needs to be set at the use site, not just on the function. It also would have required an extra NSString-to-String-to-NSString conversion anyway given how UIApplicationMain normally comes in, something we'd peephole but still making extra work for the optimizer.

Crossed fingers re: future SDK changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants