check target abi support
This PR checks for each extern function / block whether the ABI / calling convention used is supported by the current target.
This was achieved by adding an `abi_blacklist` field to the target specifications, listing the calling conventions unsupported for that target.
Chain can do something interesting here where it passes on the fold
into its inner iterators.
The lets the underlying iterator's custom fold() be used, and skips the
regular chain logic in next.
Disallow Unsized Enums
Fixes#16812.
This PR is a potential fix for #16812, an issue which is reported [again](https://github.com/rust-lang/rust/issues/36801) and [again](https://github.com/rust-lang/rust/issues/36975), with over a dozen duplicates by now.
This PR is mainly meant to promoted discussion about the issue and the correct way to fix it.
This is a [breaking-change] since the error is now reported during wfchecking, so that even the definition of a (potentially) unsized enum will cause an error (whereas it would previously cause an ICE at trans time if the enum was used in an unsized manner).
Link to PathBuf from the Path docs
I got stuck trying to use `Path` when `PathBuf` was what I needed. Hopefully this makes `PathBuf` and the module docs a bit easier to find for others.
r? @steveklabnik
debuginfo: Use TypeIdHasher for generating global debuginfo type IDs.
The only requirement for debuginfo type IDs is that they are globally unique. The `TypeIdHasher` (which is used for `std::intrinsic::type_id()` provides that, so we can get rid of some redundancy by re-using it for debuginfo. Values produced by the `TypeIdHasher` are also more stable than the current `UniqueTypeId` generation algorithm produces -- these incorporate the `NodeId`s, which is not good for incremental compilation.
@alexcrichton @eddyb : Could you take a look at the endianess adaptations that I made to the `TypeIdHasher`?
Also, are we sure that a 64 bit hash is wide enough for something that is supposed to be globally unique? For debuginfo I'm using 160 bits to make sure that we don't run into conflicts there.
trans: Make names of internal symbols independent of CGU translation order
Every codegen unit gets its own local counter for generating new symbol names. This makes bitcode and object files reproducible at the binary level even when incremental compilation is used.
The PR also solves a rare ICE resulting from a naming conflict between a user defined name and a generated one. E.g. try compiling the following program with 1.12.1 stable:
```rust
pub fn str7233() -> &'static str { "foo" }
```
This results in:
> error: internal compiler error: ../src/librustc_trans/common.rs:979: symbol `str7233` is already defined
Running into this is not very likely but it's also easily avoidable.
Fix a error of 'book/deref-coercions.html'
The original sentence is:
> This example has two conversions: `Rc<String>` to `String` and then `String` to `&str`.
But it should be
> This example has two conversions: `Rc<String>` to `String` and then `String` to `str`.
or
> This example has two conversions: `&Rc<String>` to `&String` and then `&String` to `&str`.
I think the latter is more clearly.
r? @steveklabnik
Use `SmallVector` in `CombineFields::instantiate`.
This avoids 4% of malloc calls when compiling
rustc-benchmarks/issue-32278-big-array-of-strings, and 1--2% for other
benchmarks. A small win, but an easy one.
This avoids 4% of malloc calls when compiling
rustc-benchmarks/issue-32278-big-array-of-strings, and 1--2% for other
benchmarks. A small win, but an easy one.
