When working with durations it often makes sense to use signed integers
and allow negative durations, and there is currently no nice way to
format these in std.fmt. This patch adds a simple wrapper for the
existing fmtDurtion to fit this need.
AstGen was calling findLineColumn() for every sibling Decl, using the
parent Decl as the starting point for the search for newlines. This
resulted in poor performance for large numbers of Decls with the same
parent.
The solution is simple: since AstGen progresses monotonically through
the AST, keep a single cursor into the source file, and whenever
line/column information is needed, advance the cursor. This guarantees
O(N) on the number of bytes in the file.
Perf:
As an example I ran ast-check on zigwin32/win32/everything.zig
(a 17 MiB file) in master branch, and after this commit.
With master branch, I killed the process after 17 seconds out of
boredom. With this commit, it completed in 300 milliseconds.
Closes#9234
which include:
* `__TEXT,__rodata` => `__DATA_CONST,__const`
* `__TEXT,__typelink` => `__DATA_CONST,__const`
* `__TEXT,__itablink` => `__DATA_CONST,__const`
* `__TEXT,__gosymtab` => `__DATA_CONST,__const`
* `__TEXT,__gopclntab` => `__DATA_CONST,__const`
Also, we treat section as containing machine code and mapping
it to `__TEXT,__text` if it is `S_REGULAR` and contains either
`S_ATTR_PURE_INSTRUCTIONS` or `S_ATTR_SOME_INSTRUCTIONS` or both.
With this change zig ld can link with dynamic libraries
contained within a fat/universal file that had multiple
seperate binaries embedded within it for multi-arch
support (in macOS).
Whilst zig can still only create single-architecture
executables - the ability to link with fat libraries is
useful for cases where they are the easiest (or only)
option to link against.
After giving it more thought, it doesn't make sense to separate
the two structurally. Instead, there should be two constructors
for a Dylib struct: one from binary file, and the other from a stub
file. This cleans up a lot of code and opens the way for recursive
parsing of re-exports from a dylib which are a hard requirement for
native feel when linking frameworks.
Instead of trying to fit a stub file into the frame of a Dylib struct,
I think it makes more sense to keep them as separate entities with
possibly shared interface (which would be added in the future).
This cleaned up a lot of logic in Dylib as well as Stub. Also, while
here I've made creating actual *Symbols lazy in the sense Dylib and
Stub only store hash maps of symbol names that they expose but we
defer create and referencing given dylib/stub until link time when
a symbol is actually referenced. This should reduce memory usage
and speed things up a bit.
