Fix `fmt::Debug` for strings, e.g. for Chinese characters
The problem occured due to lines like
```
3400;<CJK Ideograph Extension A, First>;Lo;0;L;;;;;N;;;;;
4DB5;<CJK Ideograph Extension A, Last>;Lo;0;L;;;;;N;;;;;
```
in `UnicodeData.txt`, which the script previously interpreted as two
characters, although it represents the whole range.
Fixes#34318.
Add tests for incremental reuse scenarios
These are microbenchmarks checking that we achieve the expected reuse in the scenarios covered by incremental beta.
r? @michaelwoerister
Add std::process::abort
This calls libc abort on Unix and fastfail on Windows, first running
cleanups to do things like flush stdout buffers. This matches with libc
abort's behavior, which flushes open files.
r? @alexcrichton
For a given code:
```rust
vec![0.0].iter().map(|s| s as i16).collect::<Vec<i16>>();
```
display:
```nocode
error: casting `&f64` as `i16` is invalid
--> foo.rs:2:35
|
2 | vec![0.0].iter().map(|s| s as i16).collect::<Vec<i16>>();
| - ^^^ cannot cast `&f64` as `i16`
| |
| did you mean `*s`?
```
instead of:
```nocode
error: casting `&f64` as `i16` is invalid
--> <anon>:2:30
|
2 | vec![0.0].iter().map(|s| s as i16).collect();
| ^^^^^^^^
|
= help: cast through a raw pointer first
```
Use a simpler loop to count the `char` of a string: count the
number of non-continuation bytes. Use `count += <conditional>` which the
compiler understands well and can apply loop optimizations to.
[LLVM 4.0] Use llvm::Attribute APIs instead of "raw value" APIs
The latter will be removed in LLVM 4.0 (see 4a6fc8bacf).
The librustc_llvm API remains mostly unchanged, except that llvm::Attribute is no longer a bitflag but represents only a *single* attribute.
The ability to store many attributes in a small number of bits and modify them without interacting with LLVM is only used in rustc_trans::abi and closely related modules, and only attributes for function arguments are considered there.
Thus rustc_trans::abi now has its own bit-packed representation of argument attributes, which are translated to rustc_llvm::Attribute when applying the attributes.
cc #37609
Show a better error when using --test with #[proc_macro_derive]
Fixes https://github.com/rust-lang/rust/issues/37480
Currently using `--test` with a crate that contains a `#[proc_macro_derive]` attribute causes an error. This PR doesn't attempt to fix the issue itself, or determine what tesing of a proc_macro_derive crate should be - just to provide a better error message.
For some reason only on enum and macro pages, the stability version is
rendered after the summary unlike all other pages. As it is already
displayed at the top of the page for all items, this removes it for
consistency and to prevent it from overlapping the summary text.
rustbuild: allow dynamically linking LLVM
The makefiles and `mklldeps.py` called `llvm-config --shared-mode` to
find out if LLVM defaulted to shared or static libraries, and just went
with that. But under rustbuild, `librustc_llvm/build.rs` was assuming
that LLVM should be static, and even forcing `--link-static` for 3.9+.
Now that build script also uses `--shared-mode` to learn the default,
which should work better for pre-3.9 configured for dynamic linking, as
it wasn't possible back then to choose differently via `llvm-config`.
Further, the configure script now has a new `--enable-llvm-link-shared`
option, which allows one to manually override `--link-shared` on 3.9+
instead of forcing static.
Update: There are now four static/shared scenarios that can happen
for the supported LLVM versions:
- 3.9+: By default use `llvm-config --link-static`
- 3.9+ and `--enable-llvm-link-shared`: Use `--link-shared` instead.
- 3.8: Use `llvm-config --shared-mode` and go with its answer.
- 3.7: Just assume static, maintaining the status quo.
fix `extern "aapcs" fn`
to actually use the AAPCS calling convention
closes#37810
This is technically a [breaking-change] because it changes the ABI of
`extern "aapcs"` functions that (a) involve `f32`/`f64` arguments/return
values and (b) are compiled for arm-eabihf targets from
"aapcs-vfp" (wrong) to "aapcs" (correct).
Appendix:
What these ABIs mean?
- In the "aapcs-vfp" ABI or "hard float" calling convention: Floating
point values are passed/returned through FPU registers (s0, s1, d0, etc.)
- Whereas, in the "aapcs" ABI or "soft float" calling convention:
Floating point values are passed/returned through general purpose
registers (r0, r1, etc.)
Mixing these ABIs can cause problems if the caller assumes that the
routine is using one of these ABIs but it's actually using the other
one.
---
r? @alexcrichton We are going this `extern "aapcs" fn` thing to implement some intrinsics (floatundidf) for the eabihf targets in order to comply with LLVM's calling convention of intrinsics.
Oh, and the value of the enum came from [here](http://llvm.org/docs/doxygen/html/namespacellvm_1_1CallingConv.html).
cc @TimNN @parched
instantiate closures on demand
this should fix compilation with `-C codegen-units=4` - tested locally
with `RUSTFLAGS='-C codegen-units=4' ../x.py test`
r? @michaelwoerister
ICH: Handle MacroDef HIR instances.
As of recently, `hir::MacroDef` instances are exported in crate metadata, which means we also store their ICH when doing incremental compilation. Even though exported macro definitions should not (yet) interact with incremental compilation, the ICH is also used for the general purpose crate hash, where macros should be included.
This PR implements ICH computation for `MacroDef`. In theory, the ICH of these MacroDefs is less stable than that of other HIR items, since I opted to just call the compiler-generated `Hash::hash()` for `Token::Interpolated` variants. `Token::Interpolated` contains AST data structures and it would have been a lot of effort to expand ICH computation to the AST too. Since quasi-quoting is rarely used *and* it would only make a difference if incremental compilation was extended to macros, the simpler implementation seemed like a good idea.
This fixes the problem reported in https://github.com/rust-lang/rust/issues/37756. The test still fails because of broken codegen-unit support though.
r? @nikomatsakis
Tidy is not the right place to do this. Tidy is for running lints.
We should instead be running the lexer/grammar tests as part of the test
suite.
This may fix nightly breakage, but I don't know why.
To resume stack unwinding, the LLVM `resume` instruction must be used.
In order to use this instruction, the calling function must have an
exception handling personality set.
LLVM 4.0 adds a new IR validation check to ensure a personality is
always set in these cases.
This was introduced in [r277360](https://reviews.llvm.org/rL277360).
Improvements to the #[should_panic] feature
Add more error checking for the `#[should_panic]` attribute, and print the expected panic string when it does not match.
Fixes https://github.com/rust-lang/rust/issues/29000
Eg:
```running 3 tests
test test2 ... ok
test test1 ... FAILED
: Panic did not include expected string 'foo'
test test3 ... FAILED
failures:
---- test1 stdout ----
thread 'test1' panicked at 'bar', test.rs:7
note: Run with `RUST_BACKTRACE=1` for a backtrace.
---- test3 stdout ----
thread 'test3' panicked at 'bar', test.rs:18
```
The problem occured due to lines like
```
3400;<CJK Ideograph Extension A, First>;Lo;0;L;;;;;N;;;;;
4DB5;<CJK Ideograph Extension A, Last>;Lo;0;L;;;;;N;;;;;
```
in `UnicodeData.txt`, which the script previously interpreted as two
characters, although it represents the whole range.
Fixes#34318.
rustbuild: Allow configuration of python interpreter
Add a configuration key to `config.toml`, read it from `./configure`, and add
auto-detection if none of those were specified.
Closes#35760
