The decision to exclude `-Xcc -D` options from swift module hash
actually doesn't help to solve the problem. It wouldn't reduce the
module variants (or the number of swiftmodule build commands) because
the command-line also encodes all the clang PCM dependencies that do get
affected by `-Xcc` flags.
To avoid the false sharing and the nondeterministic build products,
include most of the `-Xcc` flags, except include search path, into swift
module hash.
rdar://132046247
- when compiling embedded cross compile target standard libraries, include AVR
- add 16-bit pointer as a conditional compilation condition and get the void pointer size right for gyb sources
- attempt to fix clang importer not importing __swift_intptr_t correctly on 16 bit platforms
- changed the unit test target to avr-none-none-elf to match the cmake build
[AVR] got the standard library compiling in a somewhat restricted form:
General
- updated the Embedded Runtime
- tweaked CTypes.swift to fix clang import on 16 bit platforms
Strings
- as discussed in https://forums.swift.org/t/stringguts-stringobject-internals-how-to-layout-on-16-bit-platforms/73130, I went for just using the same basic layout in 16 bit as 32 bit but with 16 bit pointers/ints... the conversation is ongoing, I think something more efficient is possible but at least this compiles and will probably work (inefficiently)
Unicode
- the huge arrays of unicode stuff in UnicodeStubs would not compile, so I skipped it for AVR for now.
Synchronization
- disabled building the Synchronization library on AVR for now. It's arguable if it adds value on this platform anyway.
Conflicts:
- `test/Interop/Cxx/class/method/methods-this-and-indirect-return-irgen-itanium.swift`
previously fixed on rebranch, now fixed on main (slightly differently).
When the swiftmodule is built with different clang importer arguments,
they can have the same module hash, causing them to be wrongly re-used even
they contains different interfaces. Add ReducedExtraArgs to the module hash to
disambiguate them.
However, some Xcc arguments, most commonly `-D` options do not affect the
swiftmodule being generated. Do not pass `-Xcc -DARGS` to swift
interface compilation to reduce the amount of module variants in the
build.
rdar://131408266
- Add simple support for the AVR architecture, as a supported conditional compilation value, and added to the default llvm targets to build.
(Later PRs will fix support for 16-bit pointers, which is broken in places, and any fixes needed to get the standard library to build.)
(Note: AVR as a target is expected to always be compiled with -enable-experimental-feature Embedded.)
We were relying on this for `@isolated(any)` mangling suppression, but
it actually doesn't generate correct results for recent deployment targets.
As a result, we treated e.g. macOS 14.4 as if it were completely
unconstrained in terms of runtime availability.
I took this data from availability-macros.def; it's unfortunate that
we can't just generate the implementation directly from that.
Fixes rdar://129861211
Three minor changes:
* Remove unneeded stdint.h inclusion
* Use __FILE_NAME__ instead of __FILE__ to reduce code size
* Write location as "file:line" for better compatibility with existing tools
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
This adds three new assertion macros:
* `ASSERT` - always compiled in, always checked
* `CONDITIONAL_ASSERT` - always compiled in, checked whenever the `-compiler-assertions` flag is provided
* `DEBUG_ASSERT` - only compiled into debug builds, always checked when compiled in (functionally the same as Standard C `assert`)
The new `-compiler-assertions` flag is recognized by both `swift-frontend` and
`swiftc`.
The goal is to eventually replace every use of `assert` in the compiler with one of the above:
* Most assertions will use `ASSERT` (most assertions should always be present and checked, even in release builds)
* Expensive assertions can use `CONDITIONAL_ASSERT` to be suppressed by default
* A few very expensive and/or brittle assertions can use `DEBUG_ASSERT` to be compiled out of release builds
This should:
* Improve quality by catching errors earlier,
* Accelerate compiler triage and debugging by providing more accurate crash dumps by default, and
* Allow compiler engineers and end users alike to add `-compiler-assertions` to get more accurate failure diagnostics with any compiler
Regardless of whether someone made it non-experimental, or deleted all
the checks in the compiler, really, truly, make sure the bit is set to
indicate we have the darn feature.
Conflicts:
lib/Basic/Platform.cpp
```
diff --git a/lib/Basic/Platform.cpp b/lib/Basic/Platform.cpp
index 240edfa144a..1797c87635f 100644
--- a/lib/Basic/Platform.cpp
+++ b/lib/Basic/Platform.cpp
@@ -200,10 +200,7 @@ StringRef swift::getPlatformNameForTriple(const llvm::Triple &triple) {
case llvm::Triple::CUDA:
case llvm::Triple::DragonFly:
case llvm::Triple::DriverKit:
-<<<<<<< HEAD
case llvm::Triple::ELFIAMCU:
-=======
->>>>>>> main
case llvm::Triple::Emscripten:
case llvm::Triple::Fuchsia:
case llvm::Triple::HermitCore:
```
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
Ananas/CloudABI/Contiki/Minix have all been removed from LLVM (in
various commits).
Also adds minimal (ie. necessary for compiling) support for the new
triples.
This patch adds "_multithreaded" as a valid `_runtime` argument and
sets it when the target is `wasm32-unknown-wasi-threads` or other
non-none OS targets.
Now that the compilation model of noncopyable types is enabled everywhere,
and one can enable the feature for specific modules, we no longer need a
separate build-script/CMake option to enable it globally. Remove it all.
LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
