The include directories used when preprocessing .rc files are now separate from the target, and by default will use the system MSVC include paths if the MSVC + Windows SDK are present, otherwise it will fall back to the MinGW includes distributed with Zig. This default behavior can be overridden by the `-rcincludes` option (possible values: any (the default), msvc, gnu, or none).
This behavior is useful because Windows resource files may `#include` files that only exist with in the MSVC include dirs (e.g. in `<MSVC install directory>/atlmfc/include` which can contain other .rc files, images, icons, cursors, etc). So, by defaulting to the `any` behavior (MSVC if present, MinGW fallback), users will by default get behavior that is most-likely-to-work.
It also should be okay that the include directories used when compiling .rc files differ from the include directories used when compiling the main binary, since the .res format is not dependent on anything ABI-related. The only relevant differences would be things like `#define` constants being different values in the MinGW headers vs the MSVC headers, but any such differences would likely be a MinGW bug.
The new `@depedencies` module contains generated code like the
following (where strings like "abc123" represent hashes):
```zig
pub const root_deps = [_]struct { []const u8, []const u8 }{
.{ "foo", "abc123" },
};
pub const packages = struct {
pub const abc123 = struct {
pub const build_root = "/home/mlugg/.cache/zig/blah/abc123";
pub const build_zig = @import("abc123");
pub const deps = [_]struct { []const u8, []const u8 }{
.{ "bar", "abc123" },
.{ "name", "ghi789" },
};
};
};
```
Each package contains a build root string, the build.zig import, and a
mapping from dependency names to package hashes. There is also such a
mapping for the root package dependencies.
In theory, we could now remove the `dep_prefix` field from `std.Build`,
since its main purpose is now handled differently. I believe this is a
desirable goal, as it doesn't really make sense to assign a single FQN
to any package (because it may appear in many different places in the
package hierarchy). This commit does not remove that field, as it's used
non-trivially in a few places in the build runner and compiler tests:
this will be a future enhancement.
Resolves: #16354Resolves: #17135
The main motivation for this change is eliminating the `block_ptr`
result location and corresponding `store_to_block_ptr` ZIR instruction.
This is achieved through a simple pass over the AST before AstGen which
determines, for AST nodes which have a choice on whether to provide a
result location, which choice to make, based on whether the result
pointer is consumed non-trivially.
This eliminates so much logic from AstGen that we almost break even on
line count! AstGen no longer has to worry about instruction rewriting
based on whether or not a result location was consumed: it always knows
what to do ahead of time, which simplifies a *lot* of logic. This also
incidentally fixes a few random AstGen bugs related to result location
handling, leading to the changes in `test/` and `lib/std/`.
This opens the door to future RLS improvements by making them much
easier to implement correctly, and fixes many bugs. Most ZIR is made
more compact after this commit, mainly due to not having redundant
`store_to_block_ptr` instructions lying around, but also due to a few
bugs in the old system which are implicitly fixed here.
This makes Cache.findPrefix/findPrefixResolved use `std.fs.path.relative` instead of `std.mem.startsWith` when checking if a file is within a prefix. This fixes multiple edge cases around prefix detection:
- If a prefix path ended with a path separator, then the first character of the 'sub_path' would get cut off because the previous implementation assumed it was a path separator. Example: prefix: `/foo/`, file_path: `/foo/abc.txt` would see that they both start with `/foo/` and then slice starting from one byte past the common prefix, ending up with `bc.txt` instead of the expected `abc.txt`
- If a prefix contained double path separators after any component, then the `startsWith` check would erroneously fail. Example: prefix: `/foo//bar`, file_path: `/foo/bar/abc.txt` would not see that abc.txt is a sub path of the prefix `/foo//bar`
- On Windows, case insensitivity was not respected at all, instead the UTF-8 bytes were compared directly
This fixes all of the things in the above list (and possibly more).
Prior to this change, we would unconditionally emit any system include path/framework
path as `-iwithsysroot`/`-iframeworkwithsysroot` if the sysroot was
set which can lead to unexpected build failures. Now, calls to
`b.addSystemIncludePath` and `b.addFrameworkPath` will always emit
search paths as `-isystem`/`-iframework`. As a result, it is now up to
the user to correctly concat the search paths with the sysroot when
and where desired.
If there is a need for emitting `-iwithsysroot`/`-iframeworkwithsysroot`
I would advise adding explicit hooks such as `addSystemIncludePathWithSysroot`
and `addFrameworkPathWithSysroot`.
Without duping, users could get some unexpected behavior if they used a
string with a lifetime that didn't persist throughout the full build,
i.e. if it wasn't heap allocated, or if it was explicitly freed.
* introduce LazyPath.cwd_relative variant and use it for --zig-lib-dir. closes#12685
* move overrideZigLibDir and setMainPkgPath to options fields set once
and then never mutated.
* avoid introducing Build/util.zig
* use doc comments for deprecation notices so that they show up in
generated documentation.
* introduce InstallArtifact.Options, accept it as a parameter to
addInstallArtifact, and move override_dest_dir into it. Instead of
configuring the installation via Compile step, configure the
installation via the InstallArtifact step. In retrospect this is
obvious.
* remove calls to pushInstalledFile in InstallArtifact. See #14943
* rewrite InstallArtifact to not incorrectly observe whether a Compile
step has any generated outputs. InstallArtifact is meant to trigger
output generation.
* fix child process evaluation code handling of `-fno-emit-bin`.
* don't store out_h_filename, out_ll_filename, etc., pointlessly. these
are all just simple extensions appended to the root name.
* make emit_directory optional. It's possible to have nothing outputted,
for example, if you're just type-checking.
* avoid passing -femit-foo/-fno-emit-foo when it is the default
* rename ConfigHeader.getTemplate to getOutput
* deprecate addOptionArtifact
* update the random number seed of Options step caching.
* avoid using `inline for` pointlessly
* avoid using `override_Dest_dir` pointlessly
* avoid emitting an executable pointlessly in test cases
Removes forceBuild and forceEmit. Let's consider these additions separately.
Nearly all of the usage sites were suspicious.
Specifically this is to make sure llvm data layout generation doesn't
regress. The no emit bin is to allow testing targets that can't
currently be linked. The commented out targets are ones that fail in
the linker anyway when no emit bin is passed.
* build.zig: introduce `-Dflat` option which makes the installation
match what we want to ship for our download tarballs. This allows
deleting a bunch of shell script logic from the CI.
- for example it puts the executable directly in prefix/zig rather
than prefix/bin/zig and it additionally includes prefix/LICENSE.
* build.zig: by default also install std lib documentation to doc/std/
- this can be disabled by `-Dno-autodocs` similar to how there is
already `-Dno-langref`.
* build.zig: add `std-docs` and `langref` steps which build and install
the std lib autodocs and langref to prefix/doc/std and
prefix/doc/langref.html, respectively.
* std.Build: implement proper handling of `-femit-docs` using the
LazyPath system. This is a breaking change.
- this is a partial implementation of #16351
* frontend: fixed the handling of Autodocs with regards to caching and
putting the artifacts in the proper location to integrate with the
build system.
- closes#15864
* CI: delete the logic for autodocs since it is now handled by build.zig
and is enabled by default.
- in the future we should strive to have nearly all the CI shell
script logic deleted in favor of `zig build` commands.
* CI: pass `-DZIG_NO_LIB=ON`/`-Dno-lib` except for the one command where
we want to actually generate the langref and autodocs. Generating the
langref takes 14 minutes right now (why?!) so we don't want to do that
more times than necessary.
* Autodoc: fixed use of a global variable. It works fine as a local
variable instead.
- note that in the future we will want to make Autodoc run
simultaneously using the job system, but for now the principle of
YAGNI dictates that we don't have an init()/deinit() API and instead
simply call the function that does the things.
* Autodoc: only do it when there are no compile errors
Instead, we now have a looser helper called `checkContains(...)`
that will match on any occurrence similarly to `std.mem.indexOf()`.
While at it, I have cleaned up other combinators to make the entire
API more consistent, and so:
* `checkStart(phrase)` is now `checkStart()` followed by
`checkExact(phrase)`
* `checkNext(phrase)` if matching exactly is now `checkExact(phrase)`
* `checkNext(phrase)` if matching loosely is now `checkContains(phrase)`
* `checkNext(phrase)` if matching exactly with var extractors is now
`checkExtract(phrase)`
Finally, `ElfDumper` is now dumping contents of `.symtab` and `.dynsym`
symbol tables. I have also removed dumping of symtabs as optional - they
are now always dumped which cleaned up the implementation even more.
Don't pass the object files from a static library to the linker invocation.
The lib.a file already contains them.
Avoids "duplicate symbol" errors (and useless work by the linker)
