| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Hoedown was removed in b96fef8411f
Also cleanup src/tools/tidy/src/main.rs
Signed-off-by: NODA, Kai <nodakai@gmail.com>
|
|
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.
|
|
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
```
|
|
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
```
Re: #39579, #38564, #37626, #39942, #34698.
|
|
When trying to do a binary operation with missing implementation, for
example `1 + Some(2)`, provide an explicit help message:
```
note: no implementation for `{integer} + std::option::Option<{integer}>`
```
Use `rustc_on_unimplemented` for the suggestions. Move cfail test to ui.
|
|
Avoid pointing at two chars so the diagnostic output doesn't display a
multiline span when starting beyond a line end.
|
|
-Z linker-flavor
(Please read the commit message first)
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:
```
$ xargo rustc --target thumbv7m-none-eabi -- -Z linker-flavor=ld -C linker=ld.lld -Z print-link-args
"ld.lld" \
"-L" \
"$XARGO_HOME/lib/rustlib/thumbv7m-none-eabi/lib" \
"$PWD/target/thumbv7m-none-eabi/debug/deps/app-de1f86df314ad68c.0.o" \
"-o" \
"$PWD/target/thumbv7m-none-eabi/debug/deps/app-de1f86df314ad68c" \
"--gc-sections" \
"-L" \
"$PWD/target/thumbv7m-none-eabi/debug/deps" \
"-L" \
"$PWD/target/debug/deps" \
"-L" \
"$XARGO_HOME/lib/rustlib/thumbv7m-none-eabi/lib" \
"-Bstatic" \
"-Bdynamic" \
"$XARGO_HOME/lib/rustlib/thumbv7m-none-eabi/lib/libcore-11670d2bd4951fa7.rlib"
$ 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.
[`steed`]: https://github.com/japaric/steed
```
$ xargo rustc --target aarch64-unknown-linux-steed --example hello --release -- -Z print-link-args
"ld.lld" \
"-L" \
"$XARGO_HOME/lib/rustlib/aarch64-unknown-linux-steed/lib" \
"$PWD/target/aarch64-unknown-linux-steed/release/examples/hello-80c130ad884c0f8f.0.o" \
"-o" \
"$PWD/target/aarch64-unknown-linux-steed/release/examples/hello-80c130ad884c0f8f" \
"--gc-sections" \
"-L" \
"$PWD/target/aarch64-unknown-linux-steed/release/deps" \
"-L" \
"$PWD/target/release/deps" \
"-L" \
"$XARGO_HOME/lib/rustlib/aarch64-unknown-linux-steed/lib" \
"-Bstatic" \
"-Bdynamic" \
"/tmp/rustc.lAybk9Ltx93Q/libcompiler_builtins-589aede02de78434.rlib"
$ 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:
- [aarch64-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/aarch64-unknown-linux-steed.json)
- [arm-unknown-linux-steedeabi](https://github.com/japaric/steed/blob/lld/docker/arm-unknown-linux-steedeabi.json)
- [arm-unknown-linux-steedeabihf](https://github.com/japaric/steed/blob/lld/docker/arm-unknown-linux-steedeabihf.json)
- [armv7-unknown-linux-steedeabihf](https://github.com/japaric/steed/blob/lld/docker/armv7-unknown-linux-steedeabihf.json)
- [i686-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/i686-unknown-linux-steed.json)
- [mips-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/mips-unknown-linux-steed.json)
- [mipsel-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/mipsel-unknown-linux-steed.json)
- [powerpc-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/powerpc-unknown-linux-steed.json)
- [powerpc64-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/powerpc64-unknown-linux-steed.json)
- [x86_64-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/x86_64-unknown-linux-steed.json)
---
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.
```
$ cargo \
rustc \
--release \
-- \
-C \
linker=ld.lld \
-Z \
linker-flavor=ld \
-C \
link-args='-dynamic-linker /lib64/ld-linux-x86-64.so.2 -L/usr/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1 /usr/lib/Scrt1.o /usr/lib/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/crtbeginS.o /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/crtendS.o /usr/lib/crtn.o'
```
---
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.
|
|
|
|
|
|
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.
|
|
Channel error docs
r? @steveklabnik
I'm going to need some help on this one, a few ambiguities.
|
|
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.
|
|
|
|
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.
|
|
Minor fix to mutex example
Presumably `N` was supposed to be used in both places.
|
|
Presumably `N` was supposed to be used in both places.
|
|
A couple minor improvements for tidy error handling.
None
|
|
Always show end line of multiline annotations
```rust
error[E0046]: not all trait items implemented, missing: `Item`
--> $DIR/issue-23729.rs:20:9
|
20 | impl Iterator for Recurrence {
| _________^ starting here...
21 | | //~^ ERROR E0046
22 | | //~| NOTE missing `Item` in implementation
23 | | //~| NOTE `Item` from trait: `type Item;`
... |
36 | | }
37 | | }
| |_________^ ...ending here: missing `Item` in implementation
|
= note: `Item` from trait: `type Item;`
```
instead of
```rust
error[E0046]: not all trait items implemented, missing: `Item`
--> $DIR/issue-23729.rs:20:9
|
20 | impl Iterator for Recurrence {
| ^ missing `Item` in implementation
|
= note: `Item` from trait: `type Item;`
```
|
|
```rust
error[E0046]: not all trait items implemented, missing: `Item`
--> $DIR/issue-23729.rs:20:9
|
20 | impl Iterator for Recurrence {
| _________^ starting here...
21 | | //~^ ERROR E0046
22 | | //~| NOTE missing `Item` in implementation
23 | | //~| NOTE `Item` from trait: `type Item;`
... |
36 | | }
37 | | }
| |_________^ ...ending here: missing `Item` in implementation
|
= note: `Item` from trait: `type Item;`
```
instead of
```rust
error[E0046]: not all trait items implemented, missing: `Item`
--> $DIR/issue-23729.rs:20:9
|
20 | impl Iterator for Recurrence {
| ^ missing `Item` in implementation
|
= note: `Item` from trait: `type Item;`
```
|
|
|
|
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.
Samples:
fixes #41025 and #40687
r? @rust-lang/docs
|
|
|
|
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
|
|
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.
|
|
|
|
Add as_c_str
Again, tying up some consistencies with `CString`.
|
|
Specify type libraries for llvm-config --ldflags
This matters on systems where static libraries and dynamic libraries reside in
different location
|
|
Implement .rfind() for slice iterators Iter and IterMut
Just like the forward case find, implement rfind explicitly for slice iterators Iter and IterMut.
|
|
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.
|
|
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.
|
|
This avoids creating drop flags in many unnecessary situations.
Fixes #41110.
|
|
documentation to channel() and sync_channel(); adding more links #29377
|
|
|
|
This matters on systems where static libraries and dynamic libraries reside in
different location
|
|
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.
Fixes #38199.
Fixes #31577.
Fixes #29093.
Fixes #40012.
|
|
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
```
Fix #34264.
|
|
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;`
```
Fix #35675.
|
|
bootstrap.py: fix armv7 detection
This matches the logic that was in `./configure` before f8ca805422db8.
|
|
pub(restricted) didn't make it into 1.17
Gets shipped in 1.18 instead.
|
|
Optimize AtomicBool::fetch_nand
This is an attempt to push the PR #40563 to completion.
Benchmark: [source](https://gist.github.com/stjepang/023f5025623f5474184f9f4dfd6379ae)
Improvement:
```
name old_ ns/iter new_ce_ ns/iter diff ns/iter diff %
1t 146,440 89,904 -56,536 -38.61%
2t 561,456 316,835 -244,621 -43.57%
4t 2,822,821 1,005,424 -1,817,397 -64.38%
```
r? @eddyb
cc @alexcrichton @nagisa
|
|
document some existing unstable features
"msp430-interrupt", "ptx-kernel" and #![compiler_builtins_lib]
r? @steveklabnik
|
|
Disable errexit for sanity checking git repo
Unblock appveyor
|
|
as there's no way to generate a `#![feature(linker_flavor)]` error
|
|
Just like the forward case find, implement rfind explicitly
|
|
|
