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

[IRGen] Add assertion to emitPHINodesForBBArgs #207

Merged
merged 1 commit into from
Dec 4, 2015
Merged

[IRGen] Add assertion to emitPHINodesForBBArgs #207

merged 1 commit into from
Dec 4, 2015

Conversation

mrecachinas
Copy link

Converted the check that the DebugScope DS exists and that the
DebugScope's SILFn is the same as the IGF's to an assertion
based on the FIXME's suggestion on line 831.

Converted the check that the DebugScope `DS` exists and that the
DebugScope's `SILFn` is the same as the `IGF`'s to an assertion
based on the FIXME's suggestion on line 831.
@jckarter
Copy link
Contributor

jckarter commented Dec 4, 2015

Thanks! Have you tested whether any code or test cases rely on the fallback behavior?

@mrecachinas
Copy link
Author

@jckarter -- I ensured that no tests broke between master and my addition (tested with utils/build-script -t). I haven't explicitly tested further to see if anything relies on the fallback because it seemed the idea here was "this should never happen", but I can certainly try to come up with some test cases. Suggestions of examples that might follow that fallback are appreciated as well. :)

@jckarter
Copy link
Contributor

jckarter commented Dec 4, 2015

Good to hear. @adrian-prantl, anything we should try before adding this assert?

@adrian-prantl
Copy link
Contributor

Thanks. After 8ab1e2d, this assertion should now always hold.

@jckarter
Copy link
Contributor

jckarter commented Dec 4, 2015

Thanks @adrian-prantl. @mrecachinas, I'll accept this, and let you know if we see anything break. Thank you again for contributing!

jckarter added a commit that referenced this pull request Dec 4, 2015
[IRGen] Add assertion to `emitPHINodesForBBArgs`
@jckarter jckarter merged commit 5e4bb4b into swiftlang:master Dec 4, 2015
slavapestov pushed a commit to slavapestov/swift that referenced this pull request Nov 27, 2018
SR-3771 and SR-3751: libdispatch should not depend on external libkqueue
slavapestov pushed a commit to slavapestov/swift that referenced this pull request Nov 27, 2018
SR-3771 and SR-3751: libdispatch should not depend on external libkqueue

Signed-off-by: Daniel A. Steffen <dsteffen@apple.com>
maldahleh pushed a commit to maldahleh/swift that referenced this pull request Oct 26, 2020
[build-script] Remove hard-coded install prefix of /usr and pass it in instead
freak4pc pushed a commit to freak4pc/swift that referenced this pull request Sep 28, 2022
Drop building SwifterSwift in 3.0 mode.
DougGregor pushed a commit to DougGregor/swift that referenced this pull request Apr 28, 2024
* WiX: adjust the rules for harvesting directories with heat

This should generate durable GUIDs at compile time to allow an in-place
upgrade.  Remove the unnecessary properties in the developer tools.

* WiX: restructure the toolchain MSI

This restructures the MSIs into a slightly more granular set of MSIs.
It reduces the size of the single MSI making the installer proceed a bit
more uniformly.

bld: Build Tools (binutils, compilers, linker, assembler)
cli: Command Line Tools (clang-format, clang-tidy, swift-api-digester, swift-symbolgraph-extract, swift-package-manager)
dbg: Debugging Tools (lldb, repl)
ide: IDE Integration Tools (clangd, lldb-vscode, sourcekitd, SourceKit-LSP)

In the future, this also provides a logical location for DocC (cli),
swift-inspect (dbg), and swift-format (cli).

Take the opportunity to use the higher compression by default on all the
MSIs.

This also removes `swift-build-tool` and `swift-build-sdk-interfaces`
until we have a need for them.

Simultaneously, we are taking advantage of the WiX 4.0 feature to create
a dual-purpose MSI.  Unfortunately, burn does not support dual-purpose
builds and this implicitly migrates the toolchain to a per-user install
currently.  However, this is desirable as it will likely provide a space
free install path along with removing the need for administrator rights.

* WiX: shuffle the runtime into `Runtimes\[SemVer]`

This makes it fit more naturally into the layout with the co-located
installation.

Take the opportunity to claw back some storage by enabling compression.
This effectively neurtalises the effects of the split MSIs (and slightly
wins even).

* WiX: rework the SDK layout

Restore the components, move the install location, and enable the
dual-purpose installer, and enable higher compression.  The higher
compression helps offset some of the associated costs for the split
MSIs.

The SDKs are now relocated to `%ProgramFiles%\Swift\Platforms` to
co-locate the Platform SDKs with the toolchain and runtime.  The
conversion to a dual purpose MSI will relocate this to
`%LocalAppData%\Programs\Swift\Platforms`.  In most cases this should be
a space free path which allows us to finally migrate away from
`C:\Library` and fix the issue of incorrect permissions on directories.

* WiX: remove the obsolete `DEVELOPER_SDK` environment variable

This was removed from use in SPM in 5.7.  Update the installer to no
longer add this environment variable.

* WiX: adjust the environment handling to handle dual purpose

Ensure that we properly handle the environment when installing.  When
performing a per-user install, we should modify the user's environment
variables and when performing a per-machine install, modify the system
environment variables.

* WiX: reduce some vertical whitespace usage

Remove the use of empty nodes and collapse them to the short form.  This
reduces the height of the directory hierarchy listing and makes it
easier to identify the leaf nodes in the file system.

* WiX: rename version.wxi to config.wxi

The original version information has been removed from the include file
and now only has the configuration for the build.  This allows us to use
a single definition for the various architectures.

* WiX: draw a diagram of the SDK layout

The SDK layout is now the most complex part of the Swift distribution.
Draw a rendering of the layout to make it easier to follow.

* WiX: revert to per-machine installs

The uninstallation path is adversely effected by the dual-purpose
builds.  This allows installation and uninstallation to function.  While
this still requires the UAC prompt, a working installation is more
important.  A subsequent change to enable per-user installs is still
feasible.
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