Auto merge of #41168 - Shizmob:jemalloc-musl, r=alexcrichton
Fix jemalloc support for musl
Just like DragonFlyBSD, using the same symbols as the system allocator will result in a segmentation fault at runtime due to allocator mismatches. As such, it's better to prefix the jemalloc symbols instead, avoiding crashes.
We encountered this problem on a dynamically-linked musl target (with patches to Rust to make that possible, see #40113). It may not show up immediately obviously on the current statically-linked CRT targets.
Auto merge of #41174 - estebank:issue-41155, r=nikomatsakis
Point at only one char on `Span::next_point`
Avoid pointing at two chars so the diagnostic output doesn't display a
multiline span when starting beyond a line end.
Fix #41155.
Instead of
```rust
error: expected one of `(`, `const`, `default`, `extern`, `fn`, `type`, or `unsafe`, found `}`
--> <anon>:3:1
|
1 | impl S { pub
| _____________- starting here...
2 | |
| | ...ending here: expected one of 7 possible tokens here
3 | }
| ^ unexpected token
```
show
```rust
error: expected one of `(`, `const`, `default`, `extern`, `fn`, `type`, or `unsafe`, found `}`
--> <anon>:13:1
|
12 | pub
| - expected one of 7 possible tokens here
13 | }
| ^ unexpected token
```
Auto merge of #40565 - estebank:binops-help, r=arielb1
Explicit help message for binop type mismatch
When trying to do `1 + Some(2)`, or some other binary operation on two
types different types without an appropriate trait implementation, provide
an explicit help message:
```rust
help: `{integer} + std::option::Option<{integer}>` has no implementation
```
This PR is an alternative to rust-lang/rust#36120 (internal lld linker). The
main goal of this PR is to make it *possible* to use LLD as a linker to allow
out of tree experimentation. Now that LLD is going to be shipped with LLVM 4.0,
it should become easier to get a hold of LLD (hopefully, it will be packaged by
Linux distros soon).
Since LLD is a multiarch linker, it has the potential to make cross compilation
easier (less tools need to be installed). Supposedly, LLD is also faster than
the gold linker so LLD may improve build times where link times are significant
(e.g. 100% incremental compilation reuse).
The place where LLD shines is at linking Rust programs that don't depend on
system libraries. For example, here's how you would link a bare metal ARM
Cortex-M program:
$ file target/thumbv7m-none-eabi/debug/app
app: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped, with debug_info
```
This doesn't require installing the `arm-none-eabi-gcc` toolchain.
Even cooler (but I'm biased) is that you can link Rust programs that use
[`steed`] (`steed` is a `std` re-implementation free of C dependencies for Linux
systems) instead of `std` for a bunch of different architectures without having
to install a single cross toolchain.
$ file target/aarch64-unknown-linux-steed/release/examples/hello
hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, not stripped, with debug_info
```
All these targets (architectures) worked with LLD:
The case where lld is unergonomic is linking binaries that depend on system
libraries. Like "Hello, world" for `x86_64-unknown-linux-gnu`. Because you have
to pass as linker arguments: the path to the startup objects, the path to the
dynamic linker and the library search paths. And all those are system specific
so they can't be encoded in the target itself.
Another case where `-Z linker-flavor` may come in handy is directly calling
Solaris' linker which is also a multiarch linker (or so I have heard). cc
@binarycrusader
cc @alexcrichton
Heads up: [breaking-change] due to changes in the target specification format.
Auto merge of #41179 - mandeep:add-fmtresult-example, r=frewsxcv
Added doc comments for fmt::Result
Added doc comments for fmt::Result in regards to item 3 in issue #29355. I'm not certain that this is all that's needed but I think it's a good starting point on this item.
Auto merge of #41178 - llogiq:collections-doc-markdown, r=frewsxcv
Apply clippy's doc_markdown improvements to libcollections
Since my last PR led to linker failure, I'm now taking much smaller steps.
This only fixes some doc_markdown warnings; as they are in comments only,
we shouldn't get any problems building.
Andre Bogus [Mon, 10 Apr 2017 03:53:10 +0000 (05:53 +0200)]
Apply clippy's doc_markdown improvements to libcollections
Since my last PR led to linker failure, I'm now taking much smaller steps.
This only fixes some doc_markdown warnings; as they are in comments only,
we shouldn't get any problems building.
Auto merge of #41084 - QuietMisdreavus:rustdoc-format-redux, r=frewsxcxv,GuillaumeGomez
rustdoc: update formatting of fn signatures and where clauses to match style rfcs
Recent updates to style RFCs ([where clauses](https://github.com/rust-lang-nursery/fmt-rfcs/issues/38), [function definitions](https://github.com/rust-lang-nursery/fmt-rfcs/issues/39)) changed the "canonical" style for these items, so this is a rustdoc update to make it emit that style where necessary. This is mainly a conversion from visual indent to block indent, which helps out in situations where there was excessive indent causing lines to wrap regardless.
Auto merge of #40829 - mgattozzi:ChildStderr, r=steveklabnik
Update ChildStderr docs to be clearer
Before the docs only had a line about where it was found and that it was
a handle to stderr. This commit changes it so that the summary second line is
removed and that it's a bit clearer about what can be done with it. Part of
#29370
Auto merge of #40658 - eddyb:lay-more-out, r=arielb1
Use ty::layout for ABI computation instead of LLVM types.
This is the first step in creating a backend-agnostic library for computing call ABI details from signatures.
I wanted to open the PR *before* attempting to move `cabi_*` from trans to avoid rebase churn in #39999.
**EDIT**: As I suspected, #39999 needs this PR to fully work (see https://github.com/rust-lang/rust/pull/39999#issuecomment-287723379).
The first 3 commits add more APIs to `ty::layout` and replace non-ABI uses of `sizing_type_of`.
These APIs are probably usable by other backends, and miri too (cc @stoklund @solson).
The last commit rewrites `rustc_trans::cabi_*` to use `ty::layout` and new `rustc_trans::abi` APIs.
Also, during the process, a couple trivial bugs were identified and fixed:
* `msp430`, `nvptx`, `nvptx64`: type sizes *in bytes* were compared with `32` and `64`
* `x86` (`fastcall`): `f64` was incorrectly not treated the same way as `f32`
Although not urgent, this PR also uses the more general "homogenous aggregate" logic to fix #32045.
Auto merge of #41092 - jonhoo:std-fence-intrinsics, r=alexcrichton
Add safe wrapper for atomic_compilerfence intrinsics
This PR adds a proposed safe wrapper for the `atomic_singlethreadfence_*` intrinsics introduced by [RFC #888](https://github.com/rust-lang/rfcs/pull/888). See #41091 for further discussion.
Just like DragonFlyBSD, using the same symbols as the system allocator will
result in a segmentation fault at runtime due to allocator mismatches.
As such, prefix the jemalloc symbols instead.
Auto merge of #41148 - arielb1:dead-unwind, r=nagisa
borrowck::mir::dataflow: ignore unwind edges of empty drops
This avoids creating drop flags in many unnecessary situations.
Fixes #41110.
r? @nagisa
beta-nominating because regression. However, that is merely a small perf regression and codegen changes are always risky, so we might let this slide for 1.17.
Auto merge of #41055 - Archytaus:compile-fail/const-match-pattern-arm, r=arielb1
Fixed ICEs with pattern matching in const expression
Fixed 2 ICEs with when pattern matching inside a constant expression.
Both of these ICEs now resolve to an appropriate compiler error.
1. ICE was caused by a compiler bug to implement discriminant const qualify.
I removed this intentionally thrown bug and changed it to a FIXME as the unimplemented expression type is handled as a compiler error elsewhere.
2. ICE was caused during a drop check when checking if a variable lifetime outlives the current scope if there was no parent scope .
I've changed it to stop checking if there is no parent scope for the current scope. It is valid syntax for a const variable to be assigned a match expression with no enclosing scope.
The ICE seemed to mainly be used as a defensive check for bugs elsewhere.
Auto merge of #40887 - estebank:ty-placeholder, r=petrochenkov
Introduce `TyErr` independent from `TyInfer`
Add a `TyErr` type to represent unknown types in places where
parse errors have happened, while still able to build the AST.
Initially only used to represent incorrectly written fn arguments and
avoid "expected X parameters, found Y" errors when called with the
appropriate amount of parameters. We cannot use `TyInfer` for this as
`_` is not allowed as a valid argument type.
Example output:
```rust
error: expected one of `:` or `@`, found `,`
--> file.rs:12:9
|
12 | fn bar(x, y: usize) {}
| ^
error[E0061]: this function takes 2 parameters but 3 parameters were supplied
--> file.rs:19:9
|
12 | fn bar(x, y) {}
| --------------- defined here
...
19 | bar(1, 2, 3);
| ^^^^^^^ expected 2 parameters
```
Auto merge of #40775 - estebank:variant-as-type, r=petrochenkov
Suggest using enum when a variant is used as a type
Given a file:
```rust
enum Fruit {
Apple(i64),
Orange(i64),
}
fn should_return_fruit() -> Apple {
Apple(5)
}
```
Provide the following output:
```rust
error[E0412]: cannot find type `Apple` in this scope
--> file.rs:16:29
|
16 | fn should_return_fruit() -> Apple {
| ^^^^^ not found in this scope
|
help: there is an enum variant `Fruit::Apple`, did you mean to use `Fruit`?
--> file.rs:12:5
|
12 | Apple(i64),
| ^^^^^^^^^^
error[E0425]: cannot find function `Apple` in this scope
--> file.rs:17:5
|
17 | Apple(5)
| ^^^^^ not found in this scope
|
= help: possible candidate is found in another module, you can import it into scope:
`use Fruit::Apple;`
```
Jorge Aparicio [Tue, 21 Feb 2017 19:47:15 +0000 (14:47 -0500)]
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
Rollup merge of #41131 - euclio:collapse-animation, r=GuillaumeGomez
rustdoc: collapse docblock before showing label
The animation for collapsing descriptions is currently pretty jarring, as the label starts fading in as the description is collapsing. This causes the description to jump down a line (and sometimes change indentation) while animating.
This PR modifies this behavior to collapse the block entirely before starting to fade in the collapse button label.
While this PR works well for descriptions of structs, traits, etc., it still does not look ideal for attributes. I'd appreciate any suggestions for improving that animation. Perhaps we want to optimize for the single-attribute case, and try not to collapse the attribute list entirely before fading in the label?
Rollup merge of #41130 - petrhosek:fuchsia-ci-upstream, r=alexcrichton
travis: Use upstream LLVM repositories for Fuchsia
The Fuchsia copies of LLVM repositories contain additional patches
for work-in-progress features and there is some amount of churn that
may break Rust. Use upstream LLVM repositories instead for building
the toolchain used by the Fuchsia builder.
Rollup merge of #41080 - cuviper:generic-powerpc, r=alexcrichton
dist-powerpc-linux: use a pure 32-bit CPU profile
With `-mcpu=power4`, code might use instructions like `fcfid`, excluding
older CPUs like the PowerPC G4, which apparently some users would like
to use. The generic `-mcpu=powerpc` should stick to pure 32-bit PowerPC
instructions.
Rollup merge of #41075 - aidanhs:aphs-enable-appveyor-cache, r=alexcrichton
Re-enable appveyor cache
After breaking the queue last time, I'm cautiously back with a PR to re-enable caching on appveyor.
If you look at https://ci.appveyor.com/project/rust-lang/rust/build/1.0.2623/job/46o90by4ari6gege (one of the multiple runs that started failed, there are actually two errors - one for restoring the cache, one right at the bottom for creating a directory. I only noticed the restore error at the time as I was a bit rushed to revert and didn't stop to wonder why it continued - turns out appveyor [does not abort on cache restore failure](https://github.com/appveyor/ci/issues/723).
Turns out the cause of the build failures was the cache directory existing and me being thinking that because mkdir on windows is [recursive by default](http://stackoverflow.com/a/905239/2352259), it ignores the error if the directory already exists. Apparently this is not true, so now it checks if the directory exists before attempting to create.
In addition, I've added some more paranoia to double check everything is sane.
Rollup merge of #41061 - arielb1:parent-lock, r=eddyb
cstore: return an immutable borrow from `visible_parent_map`
This prevents an ICE when `visible_parent_map` is called multiple times, for example when an item referenced in an impl signature is imported from an `extern crate` statement occurs within an impl.
Rollup merge of #41056 - michaelwoerister:central-defpath-hashes, r=nikomatsakis
Handle DefPath hashing centrally as part of DefPathTable (+ save work during SVH calculation)
In almost all cases where we construct a `DefPath`, we just hash it and throw it away again immediately.
With this PR, the compiler will immediately compute and store the hash for each `DefPath` as it is allocated. This way we
+ can get rid of any subsequent `DefPath` hash caching (e.g. the `DefPathHashes`),
+ don't need to allocate a transient `Vec` for holding the `DefPath` (although I'm always surprised how little these small, dynamic allocations seem to hurt performance), and
+ we don't hash `DefPath` prefixes over and over again.
That last part is because we construct the hash for `prefix::foo` by hashing `(hash(prefix), foo)` instead of hashing every component of prefix.
The last commit of this PR is pretty neat, I think:
```
The SVH (Strict Version Hash) of a crate is currently computed
by hashing the ICHes (Incremental Computation Hashes) of the
crate's HIR. This is fine, expect that for incr. comp. we compute
two ICH values for each HIR item, one for the complete item and
one that just includes the item's interface. The two hashes are
are needed for dependency tracking but if we are compiling
non-incrementally and just need the ICH values for the SVH,
one of them is enough, giving us the opportunity to save some
work in this case.
```
r? @nikomatsakis
This PR depends on https://github.com/rust-lang/rust/pull/40878 to be merged first (you can ignore the first commit for reviewing, that's just https://github.com/rust-lang/rust/pull/40878).
Rollup merge of #41047 - cuviper:src_is_git, r=alexcrichton
Only use cargo-vendor if building from git sources
The only time we need to vendor sources is when building from git. If one is
building from a rustc source tarball, everything should already be in place.
This also matters for distros which do offline builds, as they can't install
cargo-vendor this way.
This adds a common `Build::src_is_git` flag, and then uses it in the dist-src
target to decide whether to install or use `cargo-vendor` at all.
SVH: Don't hash the HIR twice when once is enough.
The SVH (Strict Version Hash) of a crate is currently computed
by hashing the ICHes (Incremental Computation Hashes) of the
crate's HIR. This is fine, expect that for incr. comp. we compute
two ICH values for each HIR item, one for the complete item and
one that just includes the item's interface. The two hashes are
are needed for dependency tracking but if we are compiling
non-incrementally and just need the ICH values for the SVH,
one of them is enough, giving us the opportunity to save some
work in this case.
Auto merge of #40873 - cramertj:on-demandify-queries, r=nikomatsakis
On demandify reachability
cc https://github.com/rust-lang/rust/issues/40746
I tried following this guidance from #40746:
> The following tasks currently execute before a tcx is built, but they could be easily converted into queries that are requested after tcx is built. The main reason they are the way they are was to avoid a gratuitious refcell (but using the refcell map seems fine)...
but the result of moving `region_maps` out of `TyCtxt` and into a query caused a lot of churn, and seems like it could potentially result in a rather large performance hit, since it means a dep-graph lookup on every use of `region_maps` (rather than just a field access). Possibly `TyCtxt` could store a `RefCell<Option<RegionMap>>` internally and use that to prevent repeat lookups, but that feels like it's duplicating the work of the dep-graph. @nikomatsakis What did you have in mind for this?
Petr Hosek [Fri, 7 Apr 2017 01:49:41 +0000 (18:49 -0700)]
travis: Use upstream LLVM repositories for Fuchsia
The Fuchsia copies of LLVM repositories contain additional patches
for work-in-progress features and there is some amount of churn that
may break Rust. Use upstream LLVM repositories instead for building
the toolchain used by the Fuchsia builder.
(For an explanation of what this feature does, read the commit message)
I'd like to propose landing this as an experimental feature (experimental as in:
no clear stabilization path -- like `asm!`, `#[linkage]`) as it's low
maintenance (I think) and relevant to the "Usage in resource-constrained
environments" exploration area.
The main use case I see is running code before `main`. This could be used, for
instance, to cheaply initialize an allocator before `main` where the alternative
is to use `lazy_static` to initialize the allocator on its first use which it's
more expensive (atomics) and doesn't work on ARM Cortex-M0 microcontrollers (no
`AtomicUsize` on that platform)
In general, this pattern could be used to let *dependencies* run code before
`main` (which sounds like it could go very wrong in some cases). There are
probably other use cases; I hope that the people I have cc-ed can comment on
those.
Note that I'm personally unsure if the above pattern is something we want to
promote / allow and that's why I'm proposing this feature as experimental. If
this leads to more footguns than benefits then we can just axe the feature.
cc @nikomatsakis ^ I know you have some thoughts on having a process for
experimental features though I'm fine with writing an RFC before landing this.
- `dead_code` lint will have to be updated to special case `#[used]` symbols.
- Should we extend `#[used]` to work on non-generic functions?
cc rust-lang/rfcs#1002
cc rust-lang/rfcs#1459
cc @dpc @JinShil
Auto merge of #40863 - eddyb:coerce-only-once, r=arielb1
Avoid type-checking addition and indexing twice.
Fixes #40610 by moving the common `check_expr_coercable_to_type` call before the error reporting logic for binops and removing the one from `check_str_addition`.
Fixes #40861 by removing an unnecessary `check_expr_coercable_to_type` call.
Rollup merge of #41112 - ollie27:rustdoc_pull, r=GuillaumeGomez
rustdoc: Use pulldown-cmark for Markdown HTML rendering
Instead of rendering all of the HTML in rustdoc this relies on
pulldown-cmark's `push_html` to do most of the work. A few iterator
adapters are used to make rustdoc specific modifications to the output.
This also fixes MarkdownHtml and link titles in plain_summary_line.
https://ollie27.github.io/rust_doc_test/ is the docs built with this change and #41111.
Rollup merge of #41111 - ollie27:docs_markdown_fix, r=GuillaumeGomez
Fix Markdown issues in the docs
* Since the switch to pulldown-cmark reference links need a blank line
before the URLs. (#40912)
* Reference link references are not case sensitive.
* Doc comments need to be indented uniformly otherwise rustdoc gets
confused.
Rollup merge of #41090 - rap2hpoutre:patch-2, r=steveklabnik
Add example to std::process::abort
This is a second step in order to complete this issue: https://github.com/rust-lang/rust/issues/29370
I submitted this PR with the help of @steveklabnik again. Thanks to him! More info here: https://github.com/rust-lang/rust/issues/29370#issuecomment-290653877
Rollup merge of #40878 - michaelwoerister:dmh, r=nikomatsakis
Introduce HashStable trait and base ICH implementations on it.
This PR introduces the `HashStable` trait which marks that a type can be hashed in a way that is stable across multiple compilation sessions. The PR also moves HIR incr. comp. hashing over to implementations of this trait instead of doing this via a HIR visitor. It also provides many `HashStable` implementations that are not used yet (e.g. for MIR types) but soon will be used when we directly hash crate metadata for incr. comp.
I've only done superficial performance measurements but it looks like the new implementation is a bit faster than the current one (due, I suppose, to some bugs I fixed and some unnecessary inefficiencies I removed). Here is the time in seconds for the `compute_incremental_hashes_map` pass for various crates:
Some notes regarding the implementation:
* Most `HashStable` implementations are provided via the `impl_hash_stable_for!` macro (as suggested by @nikomatsakis). This works out quite well. A custom_derive would have been better but Macros 1.1 are not available in the compiler.
* The trait implementation take care to exhaustively destructure everything they hash so that fields added in the future don't fall through the cracks. This is a bit verbose but I think it's well worth the trouble since we've had quite a few issues with missing fields or visitor callbacks in this area in the past. Most of it is behind the macro anyway.
projects / rust.git / log