The targets are:
- `arm-unknown-linux-musleabi`
- `arm-unknown-linux-musleabihf`
- `armv7-unknown-linux-musleabihf`
These mirror the existing `gnueabi` targets.
All of these targets produce fully static binaries, similar to the
x86 MUSL targets.
For now these targets can only be used with `--rustbuild` builds, as
https://github.com/rust-lang/compiler-rt/pull/22 only made the
necessary compiler-rt changes in the CMake configs, not the plain
GNU Make configs.
I've tested these targets GCC 5.3.0 compiled again musl-1.1.12
(downloaded from http://musl.codu.org/). An example `./configure`
invocation is:
```
./configure \
--enable-rustbuild
--target=arm-unknown-linux-musleabi \
--musl-root="$MUSL_ROOT"
```
where `MUSL_ROOT` points to the `arm-linux-musleabi` prefix.
Usually that path will be of the form
`/foobar/arm-linux-musleabi/arm-linux-musleabi`.
Usually the cross-compile toolchain will live under
`/foobar/arm-linux-musleabi/bin`. That path should either by added
to your `PATH` variable, or you should add a section to your
`config.toml` as follows:
```
[target.arm-unknown-linux-musleabi]
cc = "/foobar/arm-linux-musleabi/bin/arm-linux-musleabi-gcc"
cxx = "/foobar/arm-linux-musleabi/bin/arm-linux-musleabi-g++"
```
As a prerequisite you'll also have to put a cross-compiled static
`libunwind.a` library in `$MUSL_ROOT/lib`. This is similar to [how
the x86_64 MUSL targets are built]
(https://doc.rust-lang.org/book/advanced-linking.html).
This is to pull in changes to support ARM MUSL targets.
This change also commits a couple of other cargo-generated changes
to other dependencies in the various Cargo.toml files.
syntax_ext: format: fix ICE with bad named arguments
Fixes#35082 by guarding against a new case of malformed invocation not previously covered.
r? @alexcrichton
Revert "Remove unused methods from MultiSpan"
This reverts commit f7019a4e2f.
That commit removed the only way to make a suggestion with more than one substitute. That feature is not used directly by rustc but exists and is used by Clippy. Bring it back until we come up with a better solution (suggestions don't use span labels, so it would make sense for them to use their own type).
Rational there: https://github.com/Manishearth/rust-clippy/pull/1119.
r? @jonathandturner
Cc @Manishearth
Rename _ to {integer} and {float} for unknown numeric types
This PR renames _ to {integer} or {float} for unknown numeric types, to help people parse error messages that have numeric types that haven't been nailed down.
Example:
```rust
fn main() {
let x: String = 4;
}
```
Before:
```
error[E0308]: mismatched types
--> quicktest.rs:2:21
|
2 | let x: String = 4;
| ^ expected struct `std::string::String`, found integral variable
|
= note: expected type `std::string::String`
= note: found type `_`
error: aborting due to previous error
```
after:
```
error[E0308]: mismatched types
--> quicktest.rs:2:21
|
2 | let x: String = 4;
| ^ expected struct `std::string::String`, found integral variable
|
= note: expected type `std::string::String`
= note: found type `{integer}`
error: aborting due to previous error
```
```
resolve: Exclude inaccessible names from single imports
If a single import resolves to an inaccessible name in some but not all namespaces, avoid importing the name in the inaccessible namespaces.
Currently, the inaccessible namespaces are imported but cause a privacy error when used.
r? @nrc
Add non-panicking abs() functions to all signed integer types.
Currently, calling abs() on one of the signed integer types might panic (in
debug mode at least) because the absolute value of the largest negative value
can not be represented in that signed type. Unlike all other integer
operations, there is currently not a non-panicking version on this function.
This seems to just be an oversight in the design, therefore just adding it now.
rustbuild: make backtraces (RUST_BACKTRACE) optional
but keep them enabled by default to maintain the status quo.
When disabled shaves ~56KB off every x86_64-unknown-linux-gnu
binary.
To disable backtraces you have to use a config.toml (see
src/bootstrap/config.toml.example for details) when building rustc/std:
$ python bootstrap.py --config=config.toml
---
r? @alexcrichton
cc rust-lang/rfcs#1417
Implement ARM personality routine in Rust.
Remove the `eh_personality_catch` lang item.
Use a simplified version of `cfg_if!` in libunwind.
Closes#34786
Better attribute and metaitem encapsulation throughout the compiler
This PR refactors most (hopefully all?) of the `MetaItem` interactions outside of `libsyntax` (and a few inside) to interact with MetaItems through the provided traits instead of directly creating / destruct / matching against them. This is a necessary first step to eventually converting `MetaItem`s to internally use `TokenStream` representations (which will make `MetaItem` interactions much nicer for macro writers once the new macro system is in place).
r? @nrc
book/ffi: nullable pointer cleanup
Expand the "nullable pointer optimization" section with a code example. Fixes#34250.
I also noticed that many of the examples use the libc crate just for types such as `c_char` and `c_int`, which are now available through `std::os::raw`. I changed the ones that don't need to rely on libc. I'm glad to revert that part of the commit if it's unwanted churn.
We don't actually officially support this at all, and the execution engine
support in LLVM we've had to gut as it's not compiling on MinGW, so just delete
this test for now.
Previously the C type LLVMRelocMode (available as RelocMode in Rust)
was passed as is to the function.
However createTargetMachine expects a Reloc::Model, which is an enum
just one value short.
Additionally, the function was marked as requiring Reloc::Model in the
C code, but RelocMode on the Rust-side.
We now use the correct C type LLVMRelocMode and convert it to an
Optional<Reloc::Model> as expected by the createTargetMachine call the
same the original LLVMCreateTargetMachine function does.
See
c9b262bfbd/lib/Target/TargetMachineC.cpp (L104-L121)
This was found by @eddyb.
