Conflicts:
cmake/Findllvm.cmake
The llvm11 branch changed 10's to 11's and master branch added the
"using LLVM_CONFIG_EXE" help message, so the resolution was to merge
these changes together.
I also added a check to make sure LLVM is built with AVR enabled, which
is no longer an experimental target.
* std.fs.File.copyRange and copyRangeAll return u64 instead of usize -
the returned value is how much of the `len` is transferred, so the
types should match. This removes the need for an `@intCast`.
* fix typo that removed a subtraction
* Fix the size of codegen.AnyMCValue which gave me a compile error when
I tried to build self-hosted for i386-linux.
* restore the coercion to u64 of syms_sect.sh_info. We want to make
sure the multiplication happens with 64 bits and not the smaller type
used by the ELF format.
* fix another offset parameter in link/Elf.zig to be u64 instead of usize
* add a nice little TODO note to help out Jakub
* FmtError already has FileTooBig in it; we just need to return it.
zig0 is only used for building objects, thus it has no options like
`build-exe/obj`. But when cross-compiling, we have a working zig
compiler on the host, thus we need to pass `build-obj` to the zig compiler.
On some distros (e.g. Void Linux) the release field of the tsname
struct may contain an underscore followed by a revision number at the
end. (e.g. 5.8.12_2).
* Correctly scan all the exponent bits, this caused the incorrect result
to be computed for exponents being powers of two.
* Allocate enough limbs to make llmulacc stop whining.
This reverts commit 70f37679035e64bacfc4807709da37bc02fbb346.
After discussion, I can see the value provided here, specifically with
avoiding the footgun of defer { suspend { free(@frame()); } }.
However the doc comments are updated to explain the semantics directly,
rather than basing them on the behavior of another programming language.
It was regressed in 2 ways from the merge of #6250:
* it was not being enabled by default when the target OS is native.
* we were testing the libfoo.so file path existence with bogus format
string ('{}' instead of '{s}') and so it ended up being something
like "libstd.HashMap(K,V,...).Entry.so" instead of "libfoo.so". Using
{} rather than {s} is a footgun, be careful!
Previous functionality is now restored.
closes#6523
Zig supports both Linux and Windows natively. Those are the main use
cases we are focusing on. Happy to accept mingw patches if they are
non-invasive, but we will not be hampering progress on the main use
cases with failing mingw CI builds.
Before this it was trying to copy all the files from the zig-cache dir
to the output dir, but in the current compiler architecture the cache
dir is also used for internal compiler files.
See #6552#6553#6483
Also fixes a regression introduced in
1d777e99588be047ec4d7650f048b043d6e52da0 of not converting an integer to
a string for a command line parameter.
