Auto merge of #48647 - alexcrichton:update-sccache, r=kennytm
Update sccache to its master branch
Ideally I'd like to soon enable sccache for rustbuild itself and some of the
stage0 tools, but for that to work we'll need some better Rust support than the
pretty old version we were previously using!
Auto merge of #49447 - pnkfelix:remove-cfg-const-pat-hack-47295, r=nikomatsakis
Remove adjacent all-const match arm hack.
An old fix for moves-in-guards had a hack for adjacent all-const match arms.
The hack was explained in a comment, which you can see here:
https://github.com/rust-lang/rust/pull/22580/files#diff-402a0fa4b3c6755c5650027c6d4cf1efR497
But hack was incomplete (and thus unsound), as pointed out here:
https://github.com/rust-lang/rust/issues/47295#issuecomment-357108458
Plus, it is likely to be at least tricky to reimplement this hack in
the new NLL borrowck.
So rather than try to preserve the hack, we want to try to just remove
it outright. (At least to see the results of a crater run.)
[breaking-change]
This is a breaking-change, but our hope is that no one is actually
relying on such an extreme special case. (We hypothesize the hack was
originally added to accommodate a file in our own test suite, not code
in the wild.)
Auto merge of #49098 - matklad:find_map, r=KodrAus
Add Iterator::find_map
I'd like to propose to add `find_map` method to the `Iterator`: an occasionally useful utility, which relates to `filter_map` in the same way that `find` relates to `filter`.
`find_map` takes an `Option`-returning function, applies it to the elements of the iterator, and returns the first non-`None` result. In other words, `find_map(f) == filter_map(f).next()`.
Why do we want to add a function to the `Iterator`, which can be trivially expressed as a combination of existing ones? Observe that `find(f) == filter(f).next()`, so, by the same logic, `find` itself is unnecessary!
The more positive argument is that desugaring of `find[_map]` in terms of `filter[_map]().next()` is not super obvious, because the `filter` operation reads as if it is applies to the whole collection, although in reality we are interested only in the first element. That is, the jump from "I need a **single** result" to "let's use a function which maps **many** values to **many** values" is a non-trivial speed-bump, and causes friction when reading and writing code.
Does the need for `find_map` arise in practice? Yes!
* Anecdotally, I've more than once searched the docs for the function with `[T] -> (T -> Option<U>) -> Option<U>` signature.
* The direct cause for this PR was [this](https://github.com/rust-lang/cargo/pull/5187/files/1291c50e86ed4b31db0c76de03a47a5d0074bbd7#r174934173) discussion in Cargo, which boils down to "there's some pattern that we try to express here, but current approaches looks non-pretty" (and the pattern is `filter_map`
* There are several `filter_map().next` combos in Cargo: [[1]](https://github.com/rust-lang/cargo/blob/545a4a2c930916cc9c3dc1716fb7a33299e4062b/src/cargo/ops/cargo_new.rs#L585), [[2]](https://github.com/rust-lang/cargo/blob/545a4a2c930916cc9c3dc1716fb7a33299e4062b/src/cargo/core/resolver/mod.rs#L1130), [[3]](https://github.com/rust-lang/cargo/blob/545a4a2c930916cc9c3dc1716fb7a33299e4062b/src/cargo/ops/cargo_rustc/mod.rs#L1086).
* I've also needed similar functionality in `Kotlin` several times. There, it is expressed as `mapNotNull {}.firstOrNull`, as can be seen [here](https://github.com/intellij-rust/intellij-rust/blob/ee8bdb4e073fd07142fc6e1853ca288c57495e69/src/main/kotlin/org/rust/cargo/project/model/impl/CargoProjectImpl.kt#L154), [here](https://github.com/intellij-rust/intellij-rust/blob/ee8bdb4e073fd07142fc6e1853ca288c57495e69/src/main/kotlin/org/rust/lang/core/resolve/ImplLookup.kt#L444) [here](https://github.com/intellij-rust/intellij-rust/blob/ee8bdb4e073fd07142fc6e1853ca288c57495e69/src/main/kotlin/org/rust/ide/inspections/RsLint.kt#L38) and [here](https://github.com/intellij-rust/intellij-rust/blob/ee8bdb4e073fd07142fc6e1853ca288c57495e69/src/main/kotlin/org/rust/cargo/toolchain/RustToolchain.kt#L74) (and maybe in some other cases as well)
Note that it is definitely not among the most popular functions (it definitely is less popular than `find`), but, for example it (in case of Cargo) seems to be more popular than `rposition` (1 occurrence), `step_by` (zero occurrences) and `nth` (three occurrences as `nth(0)` which probably should be replaced with `next`).
Do we necessary need this function in `std`? Could we move it to itertools? That is possible, but observe that `filter`, `filter_map`, `find` and `find_map` together really form a complete table:
It would be somewhat unsatisfying to have one quarter of this table live elsewhere :) Also, if `Itertools` adds an `find_map` method, it would be more difficult to move it to std due to name collision.
Hm, at this point I've searched for `filter_map` the umpteenth time, and, strangely, this time I do find this RFC: https://github.com/rust-lang/rfcs/issues/1801. I guess this could be an implementation though? :)
To sum up:
Pro:
- complete the symmetry with existing method
- codify a somewhat common non-obvious pattern
Contra:
- niche use case
- we can, and do, live without it
Alex Crichton [Thu, 1 Mar 2018 22:50:50 +0000 (14:50 -0800)]
Update sccache to its master branch
Ideally I'd like to soon enable sccache for rustbuild itself and some of the
stage0 tools, but for that to work we'll need some better Rust support than the
pretty old version we were previously using!
Auto merge of #49124 - abonander:attr-macro-stmt-expr, r=abonander
Expand Attributes on Statements and Expressions
This enables attribute-macro expansion on statements and expressions while retaining the `stmt_expr_attributes` feature requirement for attributes on expressions.
closes #41475
cc #38356 @petrochenkov @jseyfried
r? @nrc
Auto merge of #49580 - glandium:core-heap, r=SimonSapin
Use Alloc and Layout from core::heap.
94d1970bba87f2d2893f6e934e4c3f02ed50604d moved the alloc::allocator
module to core::heap, moving e.g. Alloc and Layout out of the alloc
crate. While alloc::heap reexports them, it's better to use them from
where they really come from.
Mike Hommey [Mon, 2 Apr 2018 07:05:30 +0000 (16:05 +0900)]
Use Alloc and Layout from core::heap.
94d1970bba87f2d2893f6e934e4c3f02ed50604d moved the alloc::allocator
module to core::heap, moving e.g. Alloc and Layout out of the alloc
crate. While alloc::heap reexports them, it's better to use them from
where they really come from.
Mark Simulacrum [Sun, 1 Apr 2018 16:04:54 +0000 (18:04 +0200)]
Rollup merge of #49451 - QuietMisdreavus:epoch-doctests, r=GuillaumeGomez
rustdoc: add an --edition flag to compile docs/doctests with a certain edition
To correspond with the 2018 edition, this adds a (currently unstable) `--edition` flag to rustdoc that makes it compile crates and doctests with the given edition. Once this lands, Cargo should be updated to pass this flag when the edition configuration option is given.
Auto merge of #49478 - Phlosioneer:fix-windows-file-not-found, r=petrochenkov
Fix escaped backslash in windows file not found message
When a module is declared, but no matching file exists, rustc gives
an error like `help: name the file either foo.rs or foo/mod.rs inside
the directory "src/bar"`. However, at on windows, the backslash was
double-escaped when naming the directory.
It did this because the string was printed in debug mode (`"{:?}"`) to
surround it with quotes. However, it should just be printed like any
other directory in an error message and surrounded by escaped quotes,
rather than relying on the debug print to add quotes (`"\"{}\""`).
I also checked the test suite to see if this output is being correctly tested. It's not - it only tests up to the word "directory". Presumably this is so that the test is not dependent on its exact position in the source tree. I don't know a better way to test this, unless the test suite supports regex?
Auto merge of #49545 - alexcrichton:proc-macro-fixes, r=eddyb
proc_macro: Tweak doc comments and negative literals
This commit tweaks the tokenization of a doc comment to use `#[doc = "..."]`
like `macro_rules!` does (instead of treating it as a `Literal` token).
Additionally it fixes treatment of negative literals in the compiler, for
exapmle `Literal::i32(-1)`. The current fix is a bit of a hack around the
current compiler implementation, providing a fix at the proc-macro layer rather
than the libsyntax layer.
Auto merge of #49530 - petrhosek:empty-extra-flags, r=cramertj
Only include space in RUSTFLAGS extra flags if not empty
When the RUSTFLAGS_STAGE_{1,2} is not set, including a space means
the string will always be non-empty and RUSTFLAGS will be always be
reset which breaks other ways of setting these such as through config
in CARGO_HOME.
Auto merge of #49527 - petrhosek:fast-submodules, r=alexcrichton
Handle fast-submodules option correctly
This option was introduced in 72cb109bec8, but it uses two different
spellings (`fast-submodule` in `bootstrap.py` vs `fast-submodules` in
`config.toml.example`) and isn't handled by Rust bootstrap which means
that any attempt to set this flag fails.
Alex Crichton [Fri, 30 Mar 2018 09:55:54 +0000 (02:55 -0700)]
proc_macro: Tweak doc comments and negative literals
This commit tweaks the tokenization of a doc comment to use `#[doc = "..."]`
like `macro_rules!` does (instead of treating it as a `Literal` token).
Additionally it fixes treatment of negative literals in the compiler, for
exapmle `Literal::i32(-1)`. The current fix is a bit of a hack around the
current compiler implementation, providing a fix at the proc-macro layer rather
than the libsyntax layer.
bors [Sat, 31 Mar 2018 04:09:43 +0000 (04:09 +0000)]
Auto merge of #49472 - nikomatsakis:nll-optimize-constraint-prop-1, r=pnkfelix
optimize NLL constraint propagation a little
Removes a bone-headed hot spot in NLL constant propagation; we were re-allocating the stack vector and hashmap as we repeated the DFS. This change shares those resources across each call.
It also modifies the constraint list to be a linked list; arguably I should revert that, though, as this didn't turn out to be a perf hit and perhaps the old code was clearer? (Still, the new style appeals to me.)
Petr Hosek [Sat, 31 Mar 2018 02:37:08 +0000 (19:37 -0700)]
Only include space in RUSTFLAGS extra flags if not empty
When the RUSTFLAGS_STAGE_{1,2} is not set, including a space means
the string will always be non-empty and RUSTFLAGS will be always be
reset which breaks other ways of setting these such as through config
in CARGO_HOME.
Petr Hosek [Fri, 30 Mar 2018 23:42:57 +0000 (16:42 -0700)]
Handle fast-submodules option correctly
This option was introduced in 72cb109bec8, but it uses two different
spellings (fast-submodule vs fast-submodules) and isn't handled by
Rust bootstrap which means that any attempt to set this flag fails.
This addition landed in https://github.com/rust-lang/rust/pull/49305 and turned out to break crates that had their own copy of `TryFrom` in order to use it on the Stable channel :(
We’ll explore the possibility of the 2018 edition having a different prelude that includes this traits. However per the editions RFC this requires implementing a warning in the 2015 edition for code that *would* break.
bors [Fri, 30 Mar 2018 14:11:35 +0000 (14:11 +0000)]
Auto merge of #49425 - alexcrichton:disallow-inline-always, r=petrochenkov
rustc: Forbid #[inline(always)] with #[target_feature]
Once a target feature is enabled for a function that means that it in general
can't be inlined into other functions which don't have that target feature
enabled. This can cause both safety and LLVM issues if we were to actually
inline it, so `#[inline(always)]` both can't be respected and would be an error
if we did so!
Today LLVM doesn't inline functions with different `#[target_feature]`
annotations, but it turns out that if one is tagged with `#[inline(always)]`
it'll override this and cause scary LLVM error to arise!
This commit fixes this issue by forbidding these two attributes to be used in
conjunction with one another.
kennytm [Thu, 29 Mar 2018 23:31:16 +0000 (01:31 +0200)]
Rollup merge of #49466 - glandium:master, r=rkruppe
Use f{32,64}::to_bits for is_zero test in vec::SpecFromElem
vec::SpecFromElem provides an optimization to use calloc to fill a Vec
when the element given to fill the Vec is represented by 0.
For floats, the test for that currently used is `x == 0. &&
x.is_sign_positive()`. When compiled in a standalone function, rustc
generates the following assembly:
```
xorps xmm1, xmm1
ucomisd xmm0, xmm1
setnp al
sete cl
and cl, al
movq rax, xmm0
test rax, rax
setns al
and al, cl
ret
```
A simpler test telling us whether the value is represented by 0, is
`x.to_bits() == 0`, which rustc compiles to:
```
movq rax, xmm0
test rax, rax
sete al
ret
```
Not that the test is hot in any way, but it also makes it clearer what
the intent in the rust code is.
kennytm [Thu, 29 Mar 2018 23:31:15 +0000 (01:31 +0200)]
Rollup merge of #49464 - ollie27:rustbuild_junction_handle_leak, r=alexcrichton
rustbuild: Don't leak file handles when creating junctions on Windows
This fixes building the compiler docs because stage1-rustc\x86_64-pc-windows-msvc\doc is used twice which doesn't work if we still have a handle from the first time.
bors [Thu, 29 Mar 2018 23:19:52 +0000 (23:19 +0000)]
Auto merge of #49316 - alexcrichton:start-group-end-group, r=michaelwoerister
rustc: Group linked libraries where needed
This commit fixes a longstanding issue with the compiler with circular
dependencies between libcore and libstd. The `core` crate requires at least one
symbol, the ability to unwind. The `std` crate is the crate which actually
defines this symbol, but the `std` crate also depends on the `core` crate.
This circular dependency is in general disallowed in Rust as crates cannot have
cycles amongst them. A special exception is made just for core/std, but this is
also unfortunately incompatible with how GNU linkers work. GNU linkers will
process undefined symbols in a left-to-right fashion, only actually linking an
rlib like libstd if there are any symbols used from it. This strategy is
incompatible with circular dependencies because if we otherwise don't use
symbols from libstd we don't discover that we needed it until we're later
processing libcore's symbols!
To fix this GNU linkers support the `--start-group` and `--end-group` options
which indicate "libraries between these markers may have circular dependencies
amongst them. The linker invocation has been updated to automatically pass these
arguments when we're invoking a GNU linker and automatically calculate where the
arguments need to go (around libstd and libcore)
Alex Crichton [Fri, 23 Mar 2018 21:33:22 +0000 (14:33 -0700)]
rustc: Group linked libraries where needed
This commit fixes a longstanding issue with the compiler with circular
dependencies between libcore and libstd. The `core` crate requires at least one
symbol, the ability to unwind. The `std` crate is the crate which actually
defines this symbol, but the `std` crate also depends on the `core` crate.
This circular dependency is in general disallowed in Rust as crates cannot have
cycles amongst them. A special exception is made just for core/std, but this is
also unfortunately incompatible with how GNU linkers work. GNU linkers will
process undefined symbols in a left-to-right fashion, only actually linking an
rlib like libstd if there are any symbols used from it. This strategy is
incompatible with circular dependencies because if we otherwise don't use
symbols from libstd we don't discover that we needed it until we're later
processing libcore's symbols!
To fix this GNU linkers support the `--start-group` and `--end-group` options
which indicate "libraries between these markers may have circular dependencies
amongst them. The linker invocation has been updated to automatically pass these
arguments when we're invoking a GNU linker and automatically calculate where the
arguments need to go (around libstd and libcore)
bors [Thu, 29 Mar 2018 11:34:17 +0000 (11:34 +0000)]
Auto merge of #49163 - SimonSapin:range-bounds, r=alexcrichton
Rename RangeArgument to RangeBounds, move it and Bound to libcore
As proposed in the tracking issue: https://github.com/rust-lang/rust/issues/30877
Changes to *stable* items:
* `core::ops::Bound` / `std::ops::Bound` is new
* `std::collections::Bound` is a deprecated reexport of it (does this actually cause a warning?)
Changes to *unstable* items
* `alloc::Bound` is gone
* `alloc::range::RangeArgument` is moved to `core::ops::RangeBounds` / `std::ops::RangeBounds`
* `alloc::range` is gone
* `std::collections::range::RangeArgument` is deprecated reexport, to be removed later
* `std::collections::range` is deprecated, to be removed later
* `impl RangeBounds<T> for Range{,From,To,Inclusive,ToInclusive}<&T>` are added
The idea of replacing this trait with a type to be used with `Into<_>` is left for future consideration / work.
Phlosioneer [Thu, 29 Mar 2018 11:03:24 +0000 (07:03 -0400)]
Fix escaped backslash in windows file not found message
When a module is declared, but no matching file exists, rustc gives
an error like 'help: name the file either foo.rs or foo/mod.rs inside
the directory "src/bar"'. However, at on windows, the backslash was
double-escaped when naming the directory.
It did this because the string was printed in debug mode ( "{:?}" ) to
surround it with quotes. However, it should just be printed like any
other directory in an error message and surrounded by escaped quotes,
rather than relying on the debug print to add quotes ( "\"{}\"" ).
bors [Thu, 29 Mar 2018 05:44:40 +0000 (05:44 +0000)]
Auto merge of #49313 - sgrif:sg-revert-stuff, r=nikomatsakis
Remove universes from `ty::ParamEnv`
This change was never meant to land. #48407 takes an alternate approach. However, that PR is now blocked on some issues with canonicalization, and rebasing these reverts gets harder each time, so let's just get this bit out of the way now.
Mike Hommey [Thu, 29 Mar 2018 00:34:39 +0000 (09:34 +0900)]
Use f{32,64}::to_bits for is_zero test in vec::SpecFromElem
vec::SpecFromElem provides an optimization to use calloc to fill a Vec
when the element given to fill the Vec is represented by 0.
For floats, the test for that currently used is `x == 0. &&
x.is_sign_positive()`. When compiled in a standalone function, rustc
generates the following assembly:
```
xorps xmm1, xmm1
ucomisd xmm0, xmm1
setnp al
sete cl
and cl, al
movq rax, xmm0
test rax, rax
setns al
and al, cl
ret
```
A simpler test telling us whether the value is represented by 0, is
`x.to_bits() == 0`, which rustc compiles to:
```
movq rax, xmm0
test rax, rax
sete al
ret
```
Not that the test is hot in any way, but it also makes it clearer what
the intent in the rust code is.
projects / rust.git / log