| Age | Commit message (Collapse) | Author | Lines |
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
r=albertlarsan68
optimize and cleanup bootstrap source
I suggest reviewing this commit by commit.
|
|
Overall optimizations for bootstrap on conditions, assertions,
trait implementations, etc.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
|
|
Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de>
|
|
`detail` and `macro` weren't adding any info.
|
|
Signed-off-by: ozkanonur <work@onurozkan.dev>
|
|
* although
* correct
* granular
* libunwind
* repository
* section
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
|
|
This also adds a new `mod download` instead of scattering the download code
across `config.rs` and `native.rs`.
|
|
|
|
|
|
|
|
This PR adds support for fetching version information from the
`git-commit-info` file when building the compiler from a source tarball.
|
|
implement detail_exit but I'm not sure it is right.
not create new file and write detail exit in lib.rs
replace std::process::exit to detail_exit
that is not related to code runnning.
remove pub
|
|
|
|
|
|
|
|
The majority of the code is only used by either rustbuild or
rustc_llvm's build script. Rust_build is compiled once for rustbuild and
once for every stage. This means that the majority of the code in this
crate is needlessly compiled multiple times. By moving only the code
actually used by the respective crates to rustbuild and rustc_llvm's
build script, this needless duplicate compilation is avoided.
|
|
|
|
The iOS toolchain can be built on Linux with minor changes. The
compilation will invoke `xcrun` to find the path to the iPhone SDK but
a fake `xcrun` executable can be used.
```
#!/bin/sh
echo "/path/to/sdk"
```
The iOS toolchain can then be built and linked with rustup.
```
$ ./x.py build --stage 2 --host x86_64-unknown-linux-gnu \
--target aarch64-apple-ios
$ rustup toolchain link stage1 build/x86_64-unknown-linux-gnu/stage1
```
It's possible to take this toolchain and compile an iOS executable
with it. This requires the ld64 linker and an iOS SDK. The ld64 linker
can be taken from
[cctools](https://github.com/tpoechtrager/cctools-port). A project's
.cargo/config can then be edited to use the linker for this target.
```
[target.aarch64-apple-ios]
linker = "/path/to/cctools/bin/arm-apple-darwin-ld"
rustflags = [
"-C",
"""
link-args=
-F/path/to/sdk/System/Library/Frameworks
-L/path/to/sdk/usr/lib
-L/path/to/sdk/usr/lib/system/
-adhoc_codesign
""",
]
```
|
|
Previously, setting `download-ci-llvm = true` when cmake wasn't
installed would give the following error:
```
failed to execute command: "cmake" "--help"
error: The system cannot find the file specified. (os error 2)
```
|
|
|
|
addresses:
clippy::or_fun_call
clippy::single_char_add_str
clippy::comparison_to_empty
clippy::or_fun_call
|
|
Misc rustbuild improvements when the LLVM backend isn't used
* Don't checkout llvm-project
* Don't require cmake and ninja
Fixes #78564
|
|
|
|
|
|
|
|
|
|
The performance difference is negligible, but it makes me feel better.
Note that this does not remove some clones in `config`, because it would
require changing the logic around (and performance doesn't matter
for bootstrap).
|
|
It isn't practical to determine whether we'll build LLVM very early in the
pipeline, so move the ninja checking to a dynamic check.
|
|
Let people know that they can set ninja=false if they don't want to
install ninja.
|
|
`rustc` allows passing in predefined target triples as well as JSON
target specification files. This change allows bootstrap to have the
first inkling about those differences. This allows building a
cross-compiler for an out-of-tree architecture (even though that
compiler won't work for other reasons).
Even if no one ever uses this functionality, I think the newtype
around the `Interned<String>` improves the readability of the code.
|
|
Make it possible to customize the location of musl libdir using
musl-libdir in config.toml, e.g., to use lib64 instead of lib.
|
|
it's not been built since a long time ago
|
|
|
|
Background: targets can be specied with or without config files;
unneccessarily differences in the logic between those cases has caused
a) the bug I tried to fix in the previous commit, b) the bug I
introduced in the previous commit.
The solution is to make the code paths the same as much as possible.
1. Targets are now not created from the `default` method. (I would both
remove the impl if this was a public library, but just wrap it for
convience becaues it's not.) Instead, there is a `from_triple` method
which does the defaulting.
2. Besides the sanity checking, use the new method in the code reading
config files. Now `no_std` is overriden iff set explicitly just like the
other fields which are optional in the TOML AST type.
3. In sanity checking, just populate the map for all targets no matter
what. That way do don't duplicate logic trying to be clever and remember
which targets have "non standard" overrides. Sanity checking is back to
just sanity checking, and out of the game of trying to default too.
|
|
Currently, it is only set correctly in the sanity checking implicit
default fallback code. Having a config file at all will for force
`no_std = false`.
|
|
|
|
|
|
|
|
|
|
|
|
Before this commit, if you're running x.py directly on a system where
`python` is symlinked to Python 3, then the `python` config option will
default to a Python 3 interpreter. This causes debuginfo tests to fail
with an opaque error message, since they have a hard requirement on
Python 2.
This commit modifies the Python probe behavior to look for python2.7 and
python2 *before* using the interpreter used to execute `x.py`.
|
|
The old logic would incorrectly look for "python2.exe" when searching
for "python2.7.exe".
|
|
|
|
|
|
|
|
This commit replaces many usages of `File::open` and reading or writing
with `fs::read_to_string`, `fs::read` and `fs::write`. This reduces code
complexity, and will improve performance for most reads, since the
functions allocate the buffer to be the size of the file.
I believe that this commit will not impact behavior in any way, so some
matches will check the error kind in case the file was not valid UTF-8.
Some of these cases may not actually care about the error.
|