mirror of
https://github.com/rust-lang/rust.git
synced 2025-04-13 12:36:47 +00:00
Auto merge of #119945 - matthiaskrgr:rollup-oy3e1j2, r=matthiaskrgr
Rollup of 5 pull requests Successful merges: - #119189 (Move section "Installing from Source" to seperate file) - #119925 (store the segment name when resolution fails) - #119935 (Move personality implementation out of PAL) - #119937 (Improve UEFI target docs) - #119938 (Allow unauthorized users to user the has-merge-commits label) r? `@ghost` `@rustbot` modify labels: rollup
This commit is contained in:
bors
commit
3deb9bbf84
@ -18,6 +18,7 @@ Files: compiler/*
|
||||
configure
|
||||
CONTRIBUTING.md
|
||||
COPYRIGHT
|
||||
INSTALL.md
|
||||
LICENSE-APACHE
|
||||
LICENSE-MIT
|
||||
README.md
|
||||
|
||||
253
INSTALL.md
Normal file
253
INSTALL.md
Normal file
@ -0,0 +1,253 @@
|
||||
# Installing from Source
|
||||
|
||||
**Note: This document describes _building_ Rust _from source_.
|
||||
This is _not recommended_ if you don't know what you're doing.
|
||||
If you just want to install Rust, check out the [README.md](README.md) instead.**
|
||||
|
||||
The Rust build system uses a Python script called `x.py` to build the compiler,
|
||||
which manages the bootstrapping process. It lives at the root of the project.
|
||||
It also uses a file named `config.toml` to determine various configuration
|
||||
settings for the build. You can see a full list of options in
|
||||
`config.example.toml`.
|
||||
|
||||
The `x.py` command can be run directly on most Unix systems in the following
|
||||
format:
|
||||
|
||||
```sh
|
||||
./x.py <subcommand> [flags]
|
||||
```
|
||||
|
||||
This is how the documentation and examples assume you are running `x.py`.
|
||||
See the [rustc dev guide][rustcguidebuild] if this does not work on your
|
||||
platform.
|
||||
|
||||
More information about `x.py` can be found by running it with the `--help` flag
|
||||
or reading the [rustc dev guide][rustcguidebuild].
|
||||
|
||||
[gettingstarted]: https://rustc-dev-guide.rust-lang.org/getting-started.html
|
||||
[rustcguidebuild]: https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html#what-is-xpy
|
||||
|
||||
## Dependencies
|
||||
|
||||
Make sure you have installed the dependencies:
|
||||
|
||||
* `python` 3 or 2.7
|
||||
* `git`
|
||||
* A C compiler (when building for the host, `cc` is enough; cross-compiling may
|
||||
need additional compilers)
|
||||
* `curl` (not needed on Windows)
|
||||
* `pkg-config` if you are compiling on Linux and targeting Linux
|
||||
* `libiconv` (already included with glibc on Debian-based distros)
|
||||
|
||||
To build Cargo, you'll also need OpenSSL (`libssl-dev` or `openssl-devel` on
|
||||
most Unix distros).
|
||||
|
||||
If building LLVM from source, you'll need additional tools:
|
||||
|
||||
* `g++`, `clang++`, or MSVC with versions listed on
|
||||
[LLVM's documentation](https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library)
|
||||
* `ninja`, or GNU `make` 3.81 or later (Ninja is recommended, especially on
|
||||
Windows)
|
||||
* `cmake` 3.13.4 or later
|
||||
* `libstdc++-static` may be required on some Linux distributions such as Fedora
|
||||
and Ubuntu
|
||||
|
||||
On tier 1 or tier 2 with host tools platforms, you can also choose to download
|
||||
LLVM by setting `llvm.download-ci-llvm = true`.
|
||||
Otherwise, you'll need LLVM installed and `llvm-config` in your path.
|
||||
See [the rustc-dev-guide for more info][sysllvm].
|
||||
|
||||
[sysllvm]: https://rustc-dev-guide.rust-lang.org/building/new-target.html#using-pre-built-llvm
|
||||
|
||||
|
||||
## Building on a Unix-like system
|
||||
|
||||
### Build steps
|
||||
|
||||
1. Clone the [source] with `git`:
|
||||
|
||||
```sh
|
||||
git clone https://github.com/rust-lang/rust.git
|
||||
cd rust
|
||||
```
|
||||
|
||||
[source]: https://github.com/rust-lang/rust
|
||||
|
||||
2. Configure the build settings:
|
||||
|
||||
```sh
|
||||
./configure
|
||||
```
|
||||
|
||||
If you plan to use `x.py install` to create an installation, it is
|
||||
recommended that you set the `prefix` value in the `[install]` section to a
|
||||
directory: `./configure --set install.prefix=<path>`
|
||||
|
||||
3. Build and install:
|
||||
|
||||
```sh
|
||||
./x.py build && ./x.py install
|
||||
```
|
||||
|
||||
When complete, `./x.py install` will place several programs into
|
||||
`$PREFIX/bin`: `rustc`, the Rust compiler, and `rustdoc`, the
|
||||
API-documentation tool. By default, it will also include [Cargo], Rust's
|
||||
package manager. You can disable this behavior by passing
|
||||
`--set build.extended=false` to `./configure`.
|
||||
|
||||
[Cargo]: https://github.com/rust-lang/cargo
|
||||
|
||||
### Configure and Make
|
||||
|
||||
This project provides a configure script and makefile (the latter of which just
|
||||
invokes `x.py`). `./configure` is the recommended way to programmatically
|
||||
generate a `config.toml`. `make` is not recommended (we suggest using `x.py`
|
||||
directly), but it is supported and we try not to break it unnecessarily.
|
||||
|
||||
```sh
|
||||
./configure
|
||||
make && sudo make install
|
||||
```
|
||||
|
||||
`configure` generates a `config.toml` which can also be used with normal `x.py`
|
||||
invocations.
|
||||
|
||||
## Building on Windows
|
||||
|
||||
On Windows, we suggest using [winget] to install dependencies by running the
|
||||
following in a terminal:
|
||||
|
||||
```powershell
|
||||
winget install -e Python.Python.3
|
||||
winget install -e Kitware.CMake
|
||||
winget install -e Git.Git
|
||||
```
|
||||
|
||||
Then edit your system's `PATH` variable and add: `C:\Program Files\CMake\bin`.
|
||||
See
|
||||
[this guide on editing the system `PATH`](https://www.java.com/en/download/help/path.html)
|
||||
from the Java documentation.
|
||||
|
||||
[winget]: https://github.com/microsoft/winget-cli
|
||||
|
||||
There are two prominent ABIs in use on Windows: the native (MSVC) ABI used by
|
||||
Visual Studio and the GNU ABI used by the GCC toolchain. Which version of Rust
|
||||
you need depends largely on what C/C++ libraries you want to interoperate with.
|
||||
Use the MSVC build of Rust to interop with software produced by Visual Studio
|
||||
and the GNU build to interop with GNU software built using the MinGW/MSYS2
|
||||
toolchain.
|
||||
|
||||
### MinGW
|
||||
|
||||
[MSYS2][msys2] can be used to easily build Rust on Windows:
|
||||
|
||||
[msys2]: https://www.msys2.org/
|
||||
|
||||
1. Download the latest [MSYS2 installer][msys2] and go through the installer.
|
||||
|
||||
2. Run `mingw32_shell.bat` or `mingw64_shell.bat` from the MSYS2 installation
|
||||
directory (e.g. `C:\msys64`), depending on whether you want 32-bit or 64-bit
|
||||
Rust. (As of the latest version of MSYS2 you have to run `msys2_shell.cmd
|
||||
-mingw32` or `msys2_shell.cmd -mingw64` from the command line instead.)
|
||||
|
||||
3. From this terminal, install the required tools:
|
||||
|
||||
```sh
|
||||
# Update package mirrors (may be needed if you have a fresh install of MSYS2)
|
||||
pacman -Sy pacman-mirrors
|
||||
|
||||
# Install build tools needed for Rust. If you're building a 32-bit compiler,
|
||||
# then replace "x86_64" below with "i686". If you've already got Git, Python,
|
||||
# or CMake installed and in PATH you can remove them from this list.
|
||||
# Note that it is important that you do **not** use the 'python2', 'cmake',
|
||||
# and 'ninja' packages from the 'msys2' subsystem.
|
||||
# The build has historically been known to fail with these packages.
|
||||
pacman -S git \
|
||||
make \
|
||||
diffutils \
|
||||
tar \
|
||||
mingw-w64-x86_64-python \
|
||||
mingw-w64-x86_64-cmake \
|
||||
mingw-w64-x86_64-gcc \
|
||||
mingw-w64-x86_64-ninja
|
||||
```
|
||||
|
||||
4. Navigate to Rust's source code (or clone it), then build it:
|
||||
|
||||
```sh
|
||||
python x.py setup user && python x.py build && python x.py install
|
||||
```
|
||||
|
||||
### MSVC
|
||||
|
||||
MSVC builds of Rust additionally require an installation of Visual Studio 2017
|
||||
(or later) so `rustc` can use its linker. The simplest way is to get
|
||||
[Visual Studio], check the "C++ build tools" and "Windows 10 SDK" workload.
|
||||
|
||||
[Visual Studio]: https://visualstudio.microsoft.com/downloads/
|
||||
|
||||
(If you're installing CMake yourself, be careful that "C++ CMake tools for
|
||||
Windows" doesn't get included under "Individual components".)
|
||||
|
||||
With these dependencies installed, you can build the compiler in a `cmd.exe`
|
||||
shell with:
|
||||
|
||||
```sh
|
||||
python x.py setup user
|
||||
python x.py build
|
||||
```
|
||||
|
||||
Right now, building Rust only works with some known versions of Visual Studio.
|
||||
If you have a more recent version installed and the build system doesn't
|
||||
understand, you may need to force rustbuild to use an older version.
|
||||
This can be done by manually calling the appropriate vcvars file before running
|
||||
the bootstrap.
|
||||
|
||||
```batch
|
||||
CALL "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat"
|
||||
python x.py build
|
||||
```
|
||||
|
||||
### Specifying an ABI
|
||||
|
||||
Each specific ABI can also be used from either environment (for example, using
|
||||
the GNU ABI in PowerShell) by using an explicit build triple. The available
|
||||
Windows build triples are:
|
||||
- GNU ABI (using GCC)
|
||||
- `i686-pc-windows-gnu`
|
||||
- `x86_64-pc-windows-gnu`
|
||||
- The MSVC ABI
|
||||
- `i686-pc-windows-msvc`
|
||||
- `x86_64-pc-windows-msvc`
|
||||
|
||||
The build triple can be specified by either specifying `--build=<triple>` when
|
||||
invoking `x.py` commands, or by creating a `config.toml` file (as described in
|
||||
[Building on a Unix-like system](#building-on-a-unix-like-system)), and passing
|
||||
`--set build.build=<triple>` to `./configure`.
|
||||
|
||||
## Building Documentation
|
||||
|
||||
If you'd like to build the documentation, it's almost the same:
|
||||
|
||||
```sh
|
||||
./x.py doc
|
||||
```
|
||||
|
||||
The generated documentation will appear under `doc` in the `build` directory for
|
||||
the ABI used. That is, if the ABI was `x86_64-pc-windows-msvc`, the directory
|
||||
will be `build\x86_64-pc-windows-msvc\doc`.
|
||||
|
||||
## Notes
|
||||
|
||||
Since the Rust compiler is written in Rust, it must be built by a precompiled
|
||||
"snapshot" version of itself (made in an earlier stage of development).
|
||||
As such, source builds require an Internet connection to fetch snapshots, and an
|
||||
OS that can execute the available snapshot binaries.
|
||||
|
||||
See https://doc.rust-lang.org/nightly/rustc/platform-support.html for a list of
|
||||
supported platforms.
|
||||
Only "host tools" platforms have a pre-compiled snapshot binary available; to
|
||||
compile for a platform without host tools you must cross-compile.
|
||||
|
||||
You may find that other platforms work, but these are our officially supported
|
||||
build environments that are most likely to work.
|
||||
253
README.md
253
README.md
@ -15,9 +15,6 @@ If you wish to _contribute_ to the compiler, you should read
|
||||
<summary>Table of Contents</summary>
|
||||
|
||||
- [Quick Start](#quick-start)
|
||||
- [Installing from Source](#installing-from-source)
|
||||
- [Building Documentation](#building-documentation)
|
||||
- [Notes](#notes)
|
||||
- [Getting Help](#getting-help)
|
||||
- [Contributing](#contributing)
|
||||
- [License](#license)
|
||||
@ -32,255 +29,9 @@ Read ["Installation"] from [The Book].
|
||||
["Installation"]: https://doc.rust-lang.org/book/ch01-01-installation.html
|
||||
[The Book]: https://doc.rust-lang.org/book/index.html
|
||||
|
||||
## Installing from Source
|
||||
## Installing from source
|
||||
|
||||
The Rust build system uses a Python script called `x.py` to build the compiler,
|
||||
which manages the bootstrapping process. It lives at the root of the project.
|
||||
It also uses a file named `config.toml` to determine various configuration
|
||||
settings for the build. You can see a full list of options in
|
||||
`config.example.toml`.
|
||||
|
||||
The `x.py` command can be run directly on most Unix systems in the following
|
||||
format:
|
||||
|
||||
```sh
|
||||
./x.py <subcommand> [flags]
|
||||
```
|
||||
|
||||
This is how the documentation and examples assume you are running `x.py`.
|
||||
See the [rustc dev guide][rustcguidebuild] if this does not work on your
|
||||
platform.
|
||||
|
||||
More information about `x.py` can be found by running it with the `--help` flag
|
||||
or reading the [rustc dev guide][rustcguidebuild].
|
||||
|
||||
[gettingstarted]: https://rustc-dev-guide.rust-lang.org/getting-started.html
|
||||
[rustcguidebuild]: https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html#what-is-xpy
|
||||
|
||||
### Dependencies
|
||||
|
||||
Make sure you have installed the dependencies:
|
||||
|
||||
* `python` 3 or 2.7
|
||||
* `git`
|
||||
* A C compiler (when building for the host, `cc` is enough; cross-compiling may
|
||||
need additional compilers)
|
||||
* `curl` (not needed on Windows)
|
||||
* `pkg-config` if you are compiling on Linux and targeting Linux
|
||||
* `libiconv` (already included with glibc on Debian-based distros)
|
||||
|
||||
To build Cargo, you'll also need OpenSSL (`libssl-dev` or `openssl-devel` on
|
||||
most Unix distros).
|
||||
|
||||
If building LLVM from source, you'll need additional tools:
|
||||
|
||||
* `g++`, `clang++`, or MSVC with versions listed on
|
||||
[LLVM's documentation](https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library)
|
||||
* `ninja`, or GNU `make` 3.81 or later (Ninja is recommended, especially on
|
||||
Windows)
|
||||
* `cmake` 3.13.4 or later
|
||||
* `libstdc++-static` may be required on some Linux distributions such as Fedora
|
||||
and Ubuntu
|
||||
|
||||
On tier 1 or tier 2 with host tools platforms, you can also choose to download
|
||||
LLVM by setting `llvm.download-ci-llvm = true`.
|
||||
Otherwise, you'll need LLVM installed and `llvm-config` in your path.
|
||||
See [the rustc-dev-guide for more info][sysllvm].
|
||||
|
||||
[sysllvm]: https://rustc-dev-guide.rust-lang.org/building/new-target.html#using-pre-built-llvm
|
||||
|
||||
|
||||
### Building on a Unix-like system
|
||||
|
||||
#### Build steps
|
||||
|
||||
1. Clone the [source] with `git`:
|
||||
|
||||
```sh
|
||||
git clone https://github.com/rust-lang/rust.git
|
||||
cd rust
|
||||
```
|
||||
|
||||
[source]: https://github.com/rust-lang/rust
|
||||
|
||||
2. Configure the build settings:
|
||||
|
||||
```sh
|
||||
./configure
|
||||
```
|
||||
|
||||
If you plan to use `x.py install` to create an installation, it is
|
||||
recommended that you set the `prefix` value in the `[install]` section to a
|
||||
directory: `./configure --set install.prefix=<path>`
|
||||
|
||||
3. Build and install:
|
||||
|
||||
```sh
|
||||
./x.py build && ./x.py install
|
||||
```
|
||||
|
||||
When complete, `./x.py install` will place several programs into
|
||||
`$PREFIX/bin`: `rustc`, the Rust compiler, and `rustdoc`, the
|
||||
API-documentation tool. By default, it will also include [Cargo], Rust's
|
||||
package manager. You can disable this behavior by passing
|
||||
`--set build.extended=false` to `./configure`.
|
||||
|
||||
[Cargo]: https://github.com/rust-lang/cargo
|
||||
|
||||
#### Configure and Make
|
||||
|
||||
This project provides a configure script and makefile (the latter of which just
|
||||
invokes `x.py`). `./configure` is the recommended way to programmatically
|
||||
generate a `config.toml`. `make` is not recommended (we suggest using `x.py`
|
||||
directly), but it is supported and we try not to break it unnecessarily.
|
||||
|
||||
```sh
|
||||
./configure
|
||||
make && sudo make install
|
||||
```
|
||||
|
||||
`configure` generates a `config.toml` which can also be used with normal `x.py`
|
||||
invocations.
|
||||
|
||||
### Building on Windows
|
||||
|
||||
On Windows, we suggest using [winget] to install dependencies by running the
|
||||
following in a terminal:
|
||||
|
||||
```powershell
|
||||
winget install -e Python.Python.3
|
||||
winget install -e Kitware.CMake
|
||||
winget install -e Git.Git
|
||||
```
|
||||
|
||||
Then edit your system's `PATH` variable and add: `C:\Program Files\CMake\bin`.
|
||||
See
|
||||
[this guide on editing the system `PATH`](https://www.java.com/en/download/help/path.html)
|
||||
from the Java documentation.
|
||||
|
||||
[winget]: https://github.com/microsoft/winget-cli
|
||||
|
||||
There are two prominent ABIs in use on Windows: the native (MSVC) ABI used by
|
||||
Visual Studio and the GNU ABI used by the GCC toolchain. Which version of Rust
|
||||
you need depends largely on what C/C++ libraries you want to interoperate with.
|
||||
Use the MSVC build of Rust to interop with software produced by Visual Studio
|
||||
and the GNU build to interop with GNU software built using the MinGW/MSYS2
|
||||
toolchain.
|
||||
|
||||
#### MinGW
|
||||
|
||||
[MSYS2][msys2] can be used to easily build Rust on Windows:
|
||||
|
||||
[msys2]: https://www.msys2.org/
|
||||
|
||||
1. Download the latest [MSYS2 installer][msys2] and go through the installer.
|
||||
|
||||
2. Run `mingw32_shell.bat` or `mingw64_shell.bat` from the MSYS2 installation
|
||||
directory (e.g. `C:\msys64`), depending on whether you want 32-bit or 64-bit
|
||||
Rust. (As of the latest version of MSYS2 you have to run `msys2_shell.cmd
|
||||
-mingw32` or `msys2_shell.cmd -mingw64` from the command line instead.)
|
||||
|
||||
3. From this terminal, install the required tools:
|
||||
|
||||
```sh
|
||||
# Update package mirrors (may be needed if you have a fresh install of MSYS2)
|
||||
pacman -Sy pacman-mirrors
|
||||
|
||||
# Install build tools needed for Rust. If you're building a 32-bit compiler,
|
||||
# then replace "x86_64" below with "i686". If you've already got Git, Python,
|
||||
# or CMake installed and in PATH you can remove them from this list.
|
||||
# Note that it is important that you do **not** use the 'python2', 'cmake',
|
||||
# and 'ninja' packages from the 'msys2' subsystem.
|
||||
# The build has historically been known to fail with these packages.
|
||||
pacman -S git \
|
||||
make \
|
||||
diffutils \
|
||||
tar \
|
||||
mingw-w64-x86_64-python \
|
||||
mingw-w64-x86_64-cmake \
|
||||
mingw-w64-x86_64-gcc \
|
||||
mingw-w64-x86_64-ninja
|
||||
```
|
||||
|
||||
4. Navigate to Rust's source code (or clone it), then build it:
|
||||
|
||||
```sh
|
||||
python x.py setup user && python x.py build && python x.py install
|
||||
```
|
||||
|
||||
#### MSVC
|
||||
|
||||
MSVC builds of Rust additionally require an installation of Visual Studio 2017
|
||||
(or later) so `rustc` can use its linker. The simplest way is to get
|
||||
[Visual Studio], check the "C++ build tools" and "Windows 10 SDK" workload.
|
||||
|
||||
[Visual Studio]: https://visualstudio.microsoft.com/downloads/
|
||||
|
||||
(If you're installing CMake yourself, be careful that "C++ CMake tools for
|
||||
Windows" doesn't get included under "Individual components".)
|
||||
|
||||
With these dependencies installed, you can build the compiler in a `cmd.exe`
|
||||
shell with:
|
||||
|
||||
```sh
|
||||
python x.py setup user
|
||||
python x.py build
|
||||
```
|
||||
|
||||
Right now, building Rust only works with some known versions of Visual Studio.
|
||||
If you have a more recent version installed and the build system doesn't
|
||||
understand, you may need to force rustbuild to use an older version.
|
||||
This can be done by manually calling the appropriate vcvars file before running
|
||||
the bootstrap.
|
||||
|
||||
```batch
|
||||
CALL "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat"
|
||||
python x.py build
|
||||
```
|
||||
|
||||
#### Specifying an ABI
|
||||
|
||||
Each specific ABI can also be used from either environment (for example, using
|
||||
the GNU ABI in PowerShell) by using an explicit build triple. The available
|
||||
Windows build triples are:
|
||||
- GNU ABI (using GCC)
|
||||
- `i686-pc-windows-gnu`
|
||||
- `x86_64-pc-windows-gnu`
|
||||
- The MSVC ABI
|
||||
- `i686-pc-windows-msvc`
|
||||
- `x86_64-pc-windows-msvc`
|
||||
|
||||
The build triple can be specified by either specifying `--build=<triple>` when
|
||||
invoking `x.py` commands, or by creating a `config.toml` file (as described in
|
||||
[Building on a Unix-like system](#building-on-a-unix-like-system)), and passing
|
||||
`--set build.build=<triple>` to `./configure`.
|
||||
|
||||
## Building Documentation
|
||||
|
||||
If you'd like to build the documentation, it's almost the same:
|
||||
|
||||
```sh
|
||||
./x.py doc
|
||||
```
|
||||
|
||||
The generated documentation will appear under `doc` in the `build` directory for
|
||||
the ABI used. That is, if the ABI was `x86_64-pc-windows-msvc`, the directory
|
||||
will be `build\x86_64-pc-windows-msvc\doc`.
|
||||
|
||||
## Notes
|
||||
|
||||
Since the Rust compiler is written in Rust, it must be built by a precompiled
|
||||
"snapshot" version of itself (made in an earlier stage of development).
|
||||
As such, source builds require an Internet connection to fetch snapshots, and an
|
||||
OS that can execute the available snapshot binaries.
|
||||
|
||||
See https://doc.rust-lang.org/nightly/rustc/platform-support.html for a list of
|
||||
supported platforms.
|
||||
Only "host tools" platforms have a pre-compiled snapshot binary available; to
|
||||
compile for a platform without host tools you must cross-compile.
|
||||
|
||||
You may find that other platforms work, but these are our officially supported
|
||||
build environments that are most likely to work.
|
||||
If you really want to install from source (though this is not recommended), see [INSTALL.md](INSTALL.md).
|
||||
|
||||
## Getting Help
|
||||
|
||||
|
||||
@ -786,7 +786,7 @@ impl<'a, 'tcx> Resolver<'a, 'tcx> {
|
||||
ResolutionError::SelfImportOnlyInImportListWithNonEmptyPrefix => {
|
||||
self.dcx().create_err(errs::SelfImportOnlyInImportListWithNonEmptyPrefix { span })
|
||||
}
|
||||
ResolutionError::FailedToResolve { last_segment, label, suggestion, module } => {
|
||||
ResolutionError::FailedToResolve { segment, label, suggestion, module } => {
|
||||
let mut err =
|
||||
struct_span_code_err!(self.dcx(), span, E0433, "failed to resolve: {}", &label);
|
||||
err.span_label(span, label);
|
||||
@ -801,9 +801,9 @@ impl<'a, 'tcx> Resolver<'a, 'tcx> {
|
||||
|
||||
if let Some(ModuleOrUniformRoot::Module(module)) = module
|
||||
&& let Some(module) = module.opt_def_id()
|
||||
&& let Some(last_segment) = last_segment
|
||||
&& let Some(segment) = segment
|
||||
{
|
||||
self.find_cfg_stripped(&mut err, &last_segment, module);
|
||||
self.find_cfg_stripped(&mut err, &segment, module);
|
||||
}
|
||||
|
||||
err
|
||||
@ -981,12 +981,7 @@ impl<'a, 'tcx> Resolver<'a, 'tcx> {
|
||||
}
|
||||
VisResolutionError::FailedToResolve(span, label, suggestion) => self.into_struct_error(
|
||||
span,
|
||||
ResolutionError::FailedToResolve {
|
||||
last_segment: None,
|
||||
label,
|
||||
suggestion,
|
||||
module: None,
|
||||
},
|
||||
ResolutionError::FailedToResolve { segment: None, label, suggestion, module: None },
|
||||
),
|
||||
VisResolutionError::ExpectedFound(span, path_str, res) => {
|
||||
self.dcx().create_err(errs::ExpectedFound { span, res, path_str })
|
||||
@ -2450,7 +2445,7 @@ impl<'a, 'tcx> Resolver<'a, 'tcx> {
|
||||
pub(crate) fn find_cfg_stripped(
|
||||
&mut self,
|
||||
err: &mut Diagnostic,
|
||||
last_segment: &Symbol,
|
||||
segment: &Symbol,
|
||||
module: DefId,
|
||||
) {
|
||||
let local_items;
|
||||
@ -2469,7 +2464,7 @@ impl<'a, 'tcx> Resolver<'a, 'tcx> {
|
||||
};
|
||||
|
||||
for &StrippedCfgItem { parent_module, name, ref cfg } in symbols {
|
||||
if parent_module != module || name.name != *last_segment {
|
||||
if parent_module != module || name.name != *segment {
|
||||
continue;
|
||||
}
|
||||
|
||||
|
||||
@ -1381,13 +1381,9 @@ impl<'a, 'tcx> Resolver<'a, 'tcx> {
|
||||
continue;
|
||||
}
|
||||
}
|
||||
return PathResult::failed(
|
||||
ident.span,
|
||||
false,
|
||||
finalize.is_some(),
|
||||
module,
|
||||
|| ("there are too many leading `super` keywords".to_string(), None),
|
||||
);
|
||||
return PathResult::failed(ident, false, finalize.is_some(), module, || {
|
||||
("there are too many leading `super` keywords".to_string(), None)
|
||||
});
|
||||
}
|
||||
if segment_idx == 0 {
|
||||
if name == kw::SelfLower {
|
||||
@ -1419,7 +1415,7 @@ impl<'a, 'tcx> Resolver<'a, 'tcx> {
|
||||
|
||||
// Report special messages for path segment keywords in wrong positions.
|
||||
if ident.is_path_segment_keyword() && segment_idx != 0 {
|
||||
return PathResult::failed(ident.span, false, finalize.is_some(), module, || {
|
||||
return PathResult::failed(ident, false, finalize.is_some(), module, || {
|
||||
let name_str = if name == kw::PathRoot {
|
||||
"crate root".to_string()
|
||||
} else {
|
||||
@ -1515,7 +1511,7 @@ impl<'a, 'tcx> Resolver<'a, 'tcx> {
|
||||
));
|
||||
} else {
|
||||
return PathResult::failed(
|
||||
ident.span,
|
||||
ident,
|
||||
is_last,
|
||||
finalize.is_some(),
|
||||
module,
|
||||
@ -1541,24 +1537,18 @@ impl<'a, 'tcx> Resolver<'a, 'tcx> {
|
||||
}
|
||||
}
|
||||
|
||||
return PathResult::failed(
|
||||
ident.span,
|
||||
is_last,
|
||||
finalize.is_some(),
|
||||
module,
|
||||
|| {
|
||||
self.report_path_resolution_error(
|
||||
path,
|
||||
opt_ns,
|
||||
parent_scope,
|
||||
ribs,
|
||||
ignore_binding,
|
||||
module,
|
||||
segment_idx,
|
||||
ident,
|
||||
)
|
||||
},
|
||||
);
|
||||
return PathResult::failed(ident, is_last, finalize.is_some(), module, || {
|
||||
self.report_path_resolution_error(
|
||||
path,
|
||||
opt_ns,
|
||||
parent_scope,
|
||||
ribs,
|
||||
ignore_binding,
|
||||
module,
|
||||
segment_idx,
|
||||
ident,
|
||||
)
|
||||
});
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@ -886,6 +886,7 @@ impl<'a, 'tcx> Resolver<'a, 'tcx> {
|
||||
PathResult::Failed {
|
||||
is_error_from_last_segment: false,
|
||||
span,
|
||||
segment_name,
|
||||
label,
|
||||
suggestion,
|
||||
module,
|
||||
@ -895,7 +896,7 @@ impl<'a, 'tcx> Resolver<'a, 'tcx> {
|
||||
self.report_error(
|
||||
span,
|
||||
ResolutionError::FailedToResolve {
|
||||
last_segment: None,
|
||||
segment: Some(segment_name),
|
||||
label,
|
||||
suggestion,
|
||||
module,
|
||||
|
||||
@ -4054,11 +4054,12 @@ impl<'a: 'ast, 'b, 'ast, 'tcx> LateResolutionVisitor<'a, 'b, 'ast, 'tcx> {
|
||||
label,
|
||||
suggestion,
|
||||
module,
|
||||
segment_name,
|
||||
} => {
|
||||
return Err(respan(
|
||||
span,
|
||||
ResolutionError::FailedToResolve {
|
||||
last_segment: None,
|
||||
segment: Some(segment_name),
|
||||
label,
|
||||
suggestion,
|
||||
module,
|
||||
|
||||
@ -213,7 +213,7 @@ enum ResolutionError<'a> {
|
||||
SelfImportOnlyInImportListWithNonEmptyPrefix,
|
||||
/// Error E0433: failed to resolve.
|
||||
FailedToResolve {
|
||||
last_segment: Option<Symbol>,
|
||||
segment: Option<Symbol>,
|
||||
label: String,
|
||||
suggestion: Option<Suggestion>,
|
||||
module: Option<ModuleOrUniformRoot<'a>>,
|
||||
@ -396,12 +396,14 @@ enum PathResult<'a> {
|
||||
suggestion: Option<Suggestion>,
|
||||
is_error_from_last_segment: bool,
|
||||
module: Option<ModuleOrUniformRoot<'a>>,
|
||||
/// The segment name of target
|
||||
segment_name: Symbol,
|
||||
},
|
||||
}
|
||||
|
||||
impl<'a> PathResult<'a> {
|
||||
fn failed(
|
||||
span: Span,
|
||||
ident: Ident,
|
||||
is_error_from_last_segment: bool,
|
||||
finalize: bool,
|
||||
module: Option<ModuleOrUniformRoot<'a>>,
|
||||
@ -409,7 +411,14 @@ impl<'a> PathResult<'a> {
|
||||
) -> PathResult<'a> {
|
||||
let (label, suggestion) =
|
||||
if finalize { label_and_suggestion() } else { (String::new(), None) };
|
||||
PathResult::Failed { span, label, suggestion, is_error_from_last_segment, module }
|
||||
PathResult::Failed {
|
||||
span: ident.span,
|
||||
segment_name: ident.name,
|
||||
label,
|
||||
suggestion,
|
||||
is_error_from_last_segment,
|
||||
module,
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@ -773,7 +773,7 @@ impl<'a, 'tcx> Resolver<'a, 'tcx> {
|
||||
self.report_error(
|
||||
span,
|
||||
ResolutionError::FailedToResolve {
|
||||
last_segment: path.last().map(|segment| segment.ident.name),
|
||||
segment: path.last().map(|segment| segment.ident.name),
|
||||
label,
|
||||
suggestion,
|
||||
module,
|
||||
|
||||
@ -3,6 +3,8 @@
|
||||
/// descriptors.
|
||||
mod pal;
|
||||
|
||||
mod personality;
|
||||
|
||||
// FIXME(117276): remove this, move feature implementations into individual
|
||||
// submodules.
|
||||
pub use pal::*;
|
||||
|
||||
@ -23,7 +23,6 @@
|
||||
#![allow(missing_debug_implementations)]
|
||||
|
||||
pub mod common;
|
||||
mod personality;
|
||||
|
||||
cfg_if::cfg_if! {
|
||||
if #[cfg(unix)] {
|
||||
|
||||
@ -82,13 +82,29 @@ rustup target add x86_64-unknown-uefi
|
||||
cargo build --target x86_64-unknown-uefi
|
||||
```
|
||||
|
||||
### Building a driver
|
||||
|
||||
There are three types of UEFI executables: application, boot service
|
||||
driver, and runtime driver. All of Rust's UEFI targets default to
|
||||
producing applications. To build a driver instead, pass a
|
||||
[`subsystem`][linker-subsystem] linker flag with a value of
|
||||
`efi_boot_service_driver` or `efi_runtime_driver`.
|
||||
|
||||
Example:
|
||||
|
||||
```toml
|
||||
# In .cargo/config.toml:
|
||||
[build]
|
||||
rustflags = ["-C", "link-args=/subsystem:efi_runtime_driver"]
|
||||
```
|
||||
|
||||
## Testing
|
||||
|
||||
UEFI applications can be copied into the ESP on any UEFI system and executed
|
||||
via the firmware boot menu. The qemu suite allows emulating UEFI systems and
|
||||
executing UEFI applications as well. See its documentation for details.
|
||||
|
||||
The [uefi-run](https://github.com/Richard-W/uefi-run) rust tool is a simple
|
||||
The [uefi-run] rust tool is a simple
|
||||
wrapper around `qemu` that can spawn UEFI applications in qemu. You can install
|
||||
it via `cargo install uefi-run` and execute qemu applications as
|
||||
`uefi-run ./application.efi`.
|
||||
@ -132,19 +148,19 @@ have been developed to provide access to UEFI protocols and make UEFI
|
||||
programming more ergonomic in rust. The following list is a short overview (in
|
||||
alphabetical ordering):
|
||||
|
||||
- **efi**: *Ergonomic Rust bindings for writing UEFI applications*. Provides
|
||||
- **[efi][efi-crate]**: *Ergonomic Rust bindings for writing UEFI applications*. Provides
|
||||
_rustified_ access to UEFI protocols, implements allocators and a safe
|
||||
environment to write UEFI applications.
|
||||
- **r-efi**: *UEFI Reference Specification Protocol Constants and Definitions*.
|
||||
- **[r-efi]**: *UEFI Reference Specification Protocol Constants and Definitions*.
|
||||
A pure transpose of the UEFI specification into rust. This provides the raw
|
||||
definitions from the specification, without any extended helpers or
|
||||
_rustification_. It serves as baseline to implement any more elaborate rust
|
||||
UEFI layers.
|
||||
- **uefi-rs**: *Safe and easy-to-use wrapper for building UEFI apps*. An
|
||||
- **[uefi-rs]**: *Safe and easy-to-use wrapper for building UEFI apps*. An
|
||||
elaborate library providing safe abstractions for UEFI protocols and
|
||||
features. It implements allocators and provides an execution environment to
|
||||
UEFI applications written in rust.
|
||||
- **uefi-run**: *Run UEFI applications*. A small wrapper around _qemu_ to spawn
|
||||
- **[uefi-run]**: *Run UEFI applications*. A small wrapper around _qemu_ to spawn
|
||||
UEFI applications in an emulated `x86_64` machine.
|
||||
|
||||
## Example: Freestanding
|
||||
@ -311,3 +327,9 @@ pub fn main() {
|
||||
The current implementation of std makes `BootServices` unavailable once `ExitBootServices` is called. Refer to [Runtime Drivers](https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/7_driver_entry_point/711_runtime_drivers) for more information regarding how to handle switching from using physical addresses to using virtual addresses.
|
||||
|
||||
Note: It should be noted that it is up to the user to drop all allocated memory before `ExitBootServices` is called.
|
||||
|
||||
[efi-crate]: https://github.com/gurry/efi
|
||||
[linker-subsystem]: https://learn.microsoft.com/en-us/cpp/build/reference/subsystem
|
||||
[r-efi]: https://github.com/r-efi/r-efi
|
||||
[uefi-rs]: https://github.com/rust-osdev/uefi-rs
|
||||
[uefi-run]: https://github.com/Richard-W/uefi-run
|
||||
|
||||
@ -46,8 +46,8 @@ const EXCEPTION_PATHS: &[&str] = &[
|
||||
// we must use `#[cfg(windows)]` to conditionally compile the
|
||||
// correct `VaList` structure for windows.
|
||||
"library/core/src/ffi/mod.rs",
|
||||
"library/std/src/sys/pal/", // Platform-specific code for std lives here.
|
||||
"library/std/src/os", // Platform-specific public interfaces
|
||||
"library/std/src/sys", // Platform-specific code for std lives here.
|
||||
"library/std/src/os", // Platform-specific public interfaces
|
||||
// Temporary `std` exceptions
|
||||
// FIXME: platform-specific code should be moved to `sys`
|
||||
"library/std/src/io/copy.rs",
|
||||
|
||||
@ -14,9 +14,9 @@ fn main() {
|
||||
|
||||
// The module isn't found - we would like to get a diagnostic, but currently don't due to
|
||||
// the awkward way the resolver diagnostics are currently implemented.
|
||||
// FIXME(Nilstrieb): Also add a note to the cfg diagnostic here
|
||||
cfged_out::inner::doesnt_exist::hello(); //~ ERROR failed to resolve
|
||||
//~^ NOTE could not find `doesnt_exist` in `inner`
|
||||
//~| NOTE found an item that was configured out
|
||||
|
||||
// It should find the one in the right module, not the wrong one.
|
||||
cfged_out::inner::right::meow(); //~ ERROR cannot find function
|
||||
|
||||
@ -1,8 +1,14 @@
|
||||
error[E0433]: failed to resolve: could not find `doesnt_exist` in `inner`
|
||||
--> $DIR/diagnostics-cross-crate.rs:18:23
|
||||
--> $DIR/diagnostics-cross-crate.rs:17:23
|
||||
|
|
||||
LL | cfged_out::inner::doesnt_exist::hello();
|
||||
| ^^^^^^^^^^^^ could not find `doesnt_exist` in `inner`
|
||||
|
|
||||
note: found an item that was configured out
|
||||
--> $DIR/auxiliary/cfged_out.rs:6:13
|
||||
|
|
||||
LL | pub mod doesnt_exist {
|
||||
| ^^^^^^^^^^^^
|
||||
|
||||
error[E0425]: cannot find function `uwu` in crate `cfged_out`
|
||||
--> $DIR/diagnostics-cross-crate.rs:7:16
|
||||
|
||||
@ -4,7 +4,7 @@ pub mod inner {
|
||||
//~^ NOTE found an item that was configured out
|
||||
|
||||
#[cfg(FALSE)]
|
||||
pub mod doesnt_exist {
|
||||
pub mod doesnt_exist { //~ NOTE found an item that was configured out
|
||||
pub fn hello() {}
|
||||
}
|
||||
|
||||
@ -34,7 +34,6 @@ fn main() {
|
||||
|
||||
// The module isn't found - we would like to get a diagnostic, but currently don't due to
|
||||
// the awkward way the resolver diagnostics are currently implemented.
|
||||
// FIXME(Nilstrieb): Also add a note to the cfg diagnostic here
|
||||
inner::doesnt_exist::hello(); //~ ERROR failed to resolve
|
||||
//~| NOTE could not find `doesnt_exist` in `inner`
|
||||
|
||||
|
||||
@ -1,8 +1,14 @@
|
||||
error[E0433]: failed to resolve: could not find `doesnt_exist` in `inner`
|
||||
--> $DIR/diagnostics-same-crate.rs:38:12
|
||||
--> $DIR/diagnostics-same-crate.rs:37:12
|
||||
|
|
||||
LL | inner::doesnt_exist::hello();
|
||||
| ^^^^^^^^^^^^ could not find `doesnt_exist` in `inner`
|
||||
|
|
||||
note: found an item that was configured out
|
||||
--> $DIR/diagnostics-same-crate.rs:7:13
|
||||
|
|
||||
LL | pub mod doesnt_exist {
|
||||
| ^^^^^^^^^^^^
|
||||
|
||||
error[E0425]: cannot find function `uwu` in module `inner`
|
||||
--> $DIR/diagnostics-same-crate.rs:32:12
|
||||
@ -17,7 +23,7 @@ LL | pub fn uwu() {}
|
||||
| ^^^
|
||||
|
||||
error[E0425]: cannot find function `meow` in module `inner::right`
|
||||
--> $DIR/diagnostics-same-crate.rs:42:19
|
||||
--> $DIR/diagnostics-same-crate.rs:41:19
|
||||
|
|
||||
LL | inner::right::meow();
|
||||
| ^^^^ not found in `inner::right`
|
||||
@ -36,7 +42,7 @@ LL | uwu();
|
||||
| ^^^ not found in this scope
|
||||
|
||||
error[E0425]: cannot find function `vanished` in this scope
|
||||
--> $DIR/diagnostics-same-crate.rs:49:5
|
||||
--> $DIR/diagnostics-same-crate.rs:48:5
|
||||
|
|
||||
LL | vanished();
|
||||
| ^^^^^^^^ not found in this scope
|
||||
|
||||
@ -22,6 +22,7 @@ allow-unauthenticated = [
|
||||
"perf-*",
|
||||
"AsyncAwait-OnDeck",
|
||||
"needs-triage",
|
||||
"has-merge-commits",
|
||||
]
|
||||
|
||||
[review-submitted]
|
||||
|
||||
Loading…
Reference in New Issue
Block a user