This is a collection of misc issues I've run into while adding bindir & libdir support that aren't really bindir & libdir specific.
While I continue to fiddle with bindir and libdir bugs, I figured these might be useful for others to have merged.
Right now we'll end up globbing them into the accepted targets and (ever worse) they will override the make variables of real target files because we `include`d everything in that directory.
As a side effect, editors get a better hint on file types.
Fixies #11671
This commit changes default relative libdir 'lib' to a relative libdir calculated using LIBDIR provided by --libdir configuration option. In case if no option was provided behavior does not change.
We add CFG_LLVM_TARGET_$(target) (which can be defined in any of the
mk/cfg/* files) and supply a default to the plain target name
CFG_LLVM_TARGET mirrors the value of llvm_target (aka llvm-target) in
the librustc_back runtime target specification.
Without this, if we we're using a non-standard host libdir, the target
bindir would not exist (and rustc would fail to write to the
non-existent directory).
If the expected rustc snapshot is not where we expect it to be,
complain and fail at that point rather than creating a empty rustc file
and continuing until we try to run it.
Futureproof Rust for fancier suffixed literals. The Rust compiler tokenises a literal followed immediately (no whitespace) by an identifier as a single token: (for example) the text sequences `"foo"bar`, `1baz` and `1u1024` are now a single token rather than the pairs `"foo"` `bar`, `1` `baz` and `1u` `1024` respectively.
The compiler rejects all such suffixes in the parser, except for the 12 numeric suffixes we have now.
I'm fairly sure this will affect very few programs, since it's not currently legal to have `<literal><identifier>` in a Rust program, except in a macro invocation. Any macro invocation relying on this behaviour can simply separate the two tokens with whitespace: `foo!("bar"baz)` becomes `foo!("bar" baz)`.
This implements [RFC 463](https://github.com/rust-lang/rfcs/blob/master/text/0463-future-proof-literal-suffixes.md), and so closes https://github.com/rust-lang/rust/issues/19088.
Now that we've done `fail` -> `panic`, I feel bringing back the error handling guide is a good idea. We had one long ago, but it was removed when conditions were removed.
This doesn't cover the new FromError stuff, but I feel like it's already useful in this state, so I'm sending this PR now.
- CFG_CFLAGS is gone (it was previously only used by jemalloc anyhow).
- CFG_JEMALLOC_CFLAGS may contain flags needed for the compiler to
function (produce a binary output).
- jemalloc's configure runs $(CC) without EXTRA_CFLAGS, and (without
this change) will fail if any flags are required for CC to work.
not in hardcoded libdir path. If there was no LIBDIR provided
during configuration fallback to hardcoded paths.
Thanks to Jan Niklas Hasse for solution and to Alex Crichton for improvements.
Closes#11671
Commit bec2ee77f7 started quoting paths
discovered as part of the `probe` function, which includes git. The
`make` `wildcard` function appears to be incompatible with quoted
paths so this check in the makefile now fails. Employing `wildcard`
here appears to only re-verify that git actually exists, which the
configure script already did, so I've just removed it.
Additionally, with the quoted paths the `subst` function should no
longer be needed, so I've removed it as well.
Closes#18771
1. Introduce `putpathvar` function that prints variable shell-quoted by using `%q` format specifier. This function is used within `probe` to save the result into `config.tmp`.
2. Removes search-and-replace pattern that transforms `\` into `/` as it messes up shell-quoted strings.
To make progress on #18585 we're paring down the distribution to theoretically
"only libstd", and this commit makes progress on this by removing the rlibc
crate from the distribution.
The crate has now been moved into an external cargo package located in the rust
lang organization [1]. This is a breaking change due to this removal, and
existing crates depending on `rlibc` should use the Cargo crate instead.
[1]: https://github.com/rust-lang/rlibc
[breaking-change]
cc #18585
Right now the windows nightlies are failing because they're encountering a
linker error when producing stage3 libs. The stage3 libs aren't actually used in
general, and we primarily just want to generate a static stage3 binary, not
static stage3 dylibs.
If a dylib is being produced, the compiler will now first check to see if it can
be created entirely statically before falling back to dynamic dependencies. This
behavior can be overridden with `-C prefer-dynamic`.
Due to the alteration in behavior, this is a breaking change. Any previous users
relying on dylibs implicitly maximizing dynamic dependencies should start
passing `-C prefer-dynamic` to compilations.
Closes#18499
[breaking-change]
Removes all target-specific knowledge from rustc. Some targets have changed
during this, but none of these should be very visible outside of
cross-compilation. The changes make our targets more consistent.
iX86-unknown-linux-gnu is now only available as i686-unknown-linux-gnu. We
used to accept any value of X greater than 1. i686 was released in 1995, and
should encompass the bare minimum of what Rust supports on x86 CPUs.
The only two windows targets are now i686-pc-windows-gnu and
x86_64-pc-windows-gnu.
The iOS target has been renamed from arm-apple-ios to arm-apple-darwin.
A complete list of the targets we accept now:
arm-apple-darwin
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
i686-apple-darwin
i686-pc-windows-gnu
i686-unknown-freebsd
i686-unknown-linux-gnu
mips-unknown-linux-gnu
mipsel-unknown-linux-gnu
x86_64-apple-darwin
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu
x86_64-pc-windows-gnu
Closes#16093
[breaking-change]
If a dylib is being produced, the compiler will now first check to see if it can
be created entirely statically before falling back to dynamic dependencies. This
behavior can be overridden with `-C prefer-dynamic`.
Due to the alteration in behavior, this is a breaking change. Any previous users
relying on dylibs implicitly maximizing dynamic dependencies should start
passing `-C prefer-dynamic` to compilations.
Closes#18499
[breaking-change]
When building for multiple targets, the initial 'make' invocation
always fails. The missing build stamp causes clean-llvm to be
invoked, but clean-llvm cleans *all* llvm builds. So what happens
is that 1) all llvm's are cleaned (a no-op), 2) llvm-${target1}
builds, 3) all llvm's are cleaned (deleting llvm-${target1}),
4) llvm-${target2} is built, 5) the remaining build for ${target1}
fails because llvm does not exist.
This makes the clean operation only clean the correct llvm build.
Should greatly reduce bot failures.
Enable parallel codegen (2 units) by default when --opt-level is 0 or 1. This
gives a minor speedup on large crates (~10%), with only a tiny slowdown (~2%)
for small ones (which usually build in under a second regardless). The current
default (no parallelization) is used when the user requests optimization
(--opt-level 2 or 3), and when the user has enabled LTO (which is incompatible
with parallel codegen).
This commit also changes the rust build system to use parallel codegen
when appropriate. This means codegen-units=4 for stage0 always, and
also for stage1 and stage2 when configured with --disable-optimize.
(Other settings use codegen-units=1 for stage1 and stage2, to get
maximum performance for release binaries.) The build system also sets
codegen-units=1 for compiletest tests (compiletest does its own
parallelization) and uses the same setting as stage2 for crate tests.
All of these crates have been deprecated for some time and properly live in the
rust-lang organization as cargo-based crates.
To update your code, depend on the rust-lang/foo repository via cargo.
[breaking-change]
When running `sudo make install`, we only want to run the actual install
as root, the building of the documentation and the distribution folder
should happen as the non-root user.
Related to #13728.
Richard Diamond