| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Implement `?` macro repetition
See rust-lang/rfcs#2298 (with disposition merge)
|
|
The following submodules have been updated for a new version of LLVM:
- `src/llvm`
- `src/libcompiler_builtins` - transitively contains compiler-rt
- `src/dlmalloc`
This also updates the docker container for dist-i686-freebsd as the old 16.04
container is no longer capable of building LLVM. The
compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without
much interesting happening, but the LLVM update here is of particular note.
Unlike previous updates I haven't cherry-picked all existing patches we had on
top of our LLVM branch as we have a [huge amount][patches4] and have at this
point forgotten what most of them are for. Instead I started from the current
`release_60` branch in LLVM and only applied patches that were necessary to get
our tests working and building.
The current set of custom rustc-specific patches included in this LLVM update are:
* rust-lang/llvm@1187443 - this is how we actually implement
`cfg(target_feature)` for now and continues to not be upstreamed. While a
hazard for SIMD stabilization this commit is otherwise keeping the status
quo of a small rustc-specific feature.
* rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't
upstreamed, notably teaching LLVM about our allocation-related routines (which
aren't malloc/free). Once we stabilize the global allocator routines we will
likely want to upstream this patch, but for now it seems reasonable to keep it
on our fork.
* rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in
our 32-bit linux container. I'm not really sure why it's necessary but my
guess is that it's because of the absolutely ancient glibc that we're using.
In any case it's only updating pieces we're not actually using in LLVM so I'm
hoping it'll turn out alright. This doesn't seem like something we'll want to
upstream.c
* rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our
i686-freebsd container, I'm not really sure what's going on but we for sure
probably don't want to upstream this and otherwise it seems not too bad for
now at least.
* rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug]
which although diagnosed to a particular revision isn't currently fixed
upstream (and the bug itself doesn't seem too active). This commit is a
partial revert of the suspected cause of this regression (found via a
bisection). I'm sort of hoping that this eventually gets fixed upstream with a
similar fix (which we can replace in our branch), but for now I'm also hoping
it's a relatively harmless change to have.
After applying these patches (plus one [backport] which should be [backported
upstream][llvm-back]) I believe we should have all tests working on all
platforms in our current test suite. I'm like 99% sure that we'll need some more
backports as issues are reported for LLVM 6 when this propagates through
nightlies, but that's sort of just par for the course nowadays!
In any case though some extra scrutiny of the patches here would definitely be
welcome, along with scrutiny of the "missing patches" like a [change to pass
manager order](rust-lang/llvm@27174447533), [another change to pass manager
order](rust-lang/llvm@c782febb7b9), some [compile fixes for
sparc](rust-lang/llvm@1a83de63c42), and some [fixes for
solaris](rust-lang/llvm@c2bfe0abb).
[patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1
[backport]: https://github.com/rust-lang/llvm/commit/5c54c252db
[llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114
[upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096
---
The update to LLVM 6 is desirable for a number of reasons, notably:
* This'll allow us to keep up with the upstream wasm backend, picking up new
features as they start landing.
* Upstream LLVM has fixed a number of SIMD-related compilation errors,
especially around AVX-512 and such.
* There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed
in the LLVM 4 branch we're using.
* Overall it's not a great idea to stagnate with our codegen backend!
This update is mostly powered by #47730 which is allowing us to update LLVM
*independent* of the version of LLVM that Emscripten is locked to. This means
that when compiling code for Emscripten we'll still be using the old LLVM 4
backend, but when compiling code for any other target we'll be using the new
LLVM 6 target. Once Emscripten updates we may no longer need this distinction,
but we're not sure when that will happen!
Closes #43370
Closes #43418
Closes #47015
Closes #47683
Closes rust-lang-nursery/stdsimd#157
Closes rust-lang-nursery/rust-wasm#3
|
|
r=petrochenkov
Stabilize use_nested_groups
As requested in #44494. Documentation PRs already sent.
|
|
|
|
Fix overflow when performing drop check calculations in NLL
Clearing out the infcx's region constraints after processing each type
ends up interacting badly with normalizing associated types. This commit
keeps all region constraints intact until the end of
TypeLivenessGenerator.add_drop_live_constraint, ensuring that normalized
types are able to re-use existing inference variables.
Fixes #47589
|
|
Fix ref-to-ptr coercions not working with NLL in certain cases
Implicit coercions from references to pointers were lowered to slightly
different Mir than explicit casts (e.g. 'foo as *mut T'). This resulted
in certain uses of self-referential structs compiling correctly when an
explicit cast was used, but not when the implicit coercion was used.
To fix this, this commit adds an outer 'Use' expr when applying a
raw-ptr-borrow adjustment. This makes the lowered Mir for coercions
identical to that of explicit coercions, allowing the original code to
compile regardless of how the raw ptr cast occurs.
Fixes #47722
|
|
Turn `type_id` into a constant intrinsic
https://github.com/rust-lang/rust/issues/27745
The method `get_type_id` in `Any` is intended to support reflection. It's currently unstable in favor of using an associated constant instead. This PR makes the `type_id` intrinsic a constant intrinsic, the same as `size_of` and `align_of`, allowing `TypeId::of` to be a `const fn`, which will allow using an associated constant in `Any`.
|
|
r=petrochenkov
Stabilize feature(match_beginning_vert)
With this feature stabilized, match expressions can optionally have a `|` at the beginning of each arm.
Reference PR: rust-lang-nursery/reference#231
Closes #44101
|
|
Use a range to identify SIGSEGV in stack guards
Previously, the `guard::init()` and `guard::current()` functions were
returning a `usize` address representing the top of the stack guard,
respectively for the main thread and for spawned threads. The `SIGSEGV`
handler on `unix` targets checked if a fault was within one page below that
address, if so reporting it as a stack overflow.
Now `unix` targets report a `Range<usize>` representing the guard memory,
so it can cover arbitrary guard sizes. Non-`unix` targets which always
return `None` for guards now do so with `Option<!>`, so they don't pay any
overhead.
For `linux-gnu` in particular, the previous guard upper-bound was
`stackaddr + guardsize`, as the protected memory was *inside* the stack.
This was a glibc bug, and starting from 2.27 they are moving the guard
*past* the end of the stack. However, there's no simple way for us to know
where the guard page actually lies, so now we declare it as the whole range
of `stackaddr ± guardsize`, and any fault therein will be called a stack
overflow. This fixes #47863.
|
|
Generator bugfixes
r? @nikomatsakis
|
|
when assigning references to a static mut with NLL is_unsafe_place only filters out statics in the rhs, not the lhs. Since it's possible to reach that 'Place::Static', we handle statics the same way as we do locals. Fixes #47789
|
|
Add rustc_const_unstable attribute for `any::TypeId::of`
Add test for `const fn TypeId::of`
|
|
remove intercrate ambiguity hints
The scheme was causing overflows during coherence checking (e.g. #47139). This is sort of a temporary fix; the proper fix I think involves reworking trait selection in deeper ways.
cc @sgrif -- this *should* fix diesel
cc @qnighy -- I'd like to discuss you with alternative techniques for achieving the same end. =) Actually, it might be good to put some energy into refactoring traits first.
r? @eddyb
|
|
Clearing out the infcx's region constraints after processing each type
ends up interacting badly with normalizing associated types. This commit
keeps all region constraints intact until the end of
TypeLivenessGenerator.add_drop_live_constraint, ensuring that normalized
types are able to re-use existing inference variables.
Fixes #47589
|
|
|
|
rustc_trans: keep LLVM types for trait objects anonymous.
Fixes #47638 by reverting the addition of readable LLVM trait object type names.
r? @nikomatsakis
|
|
is_unsafe_place only filters out statics in the rhs, not the lhs. Since
it's possible to reach that 'Place::Static', we handle statics the same
way as we do locals.
Fixes #47789
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is a test of `target_feature`, which needs a rust-specific patch to
LLVM to add `MCSubtargetInfo::getFeatureTable()`.
|
|
Fixes #47736
|
|
r=nikomatsakis
Increase test coverage of use_nested_groups
r? @nikomatsakis
|
|
Make run-pass/env-home-dir.rs test more robust
Remove the assumption that home_dir always returns Some.
This allows the test to be executed with [cross](https://github.com/japaric/cross).
|
|
Implicit coercions from references to pointers were lowered to slightly
different Mir than explicit casts (e.g. 'foo as *mut T'). This resulted
in certain uses of self-referential structs compiling correctly when an
explicit cast was used, but not when the implicit coercion was used.
To fix this, this commit adds an outer 'Use' expr when applying a
raw-ptr-borrow adjustment. This makes the lowered Mir for coercions
identical to that of explicit coercions, allowing the original code to
compile regardless of how the raw ptr cast occurs.
Fixes #47722
|
|
Replace "lvalue" terminology with "place".
See #46425 for the previous PR (which only changed MIR-related code).
r? @nikomatsakis
|
|
|
|
Remove the assumption that home_dir always returns Some
This allows the test to be executed with
[cross](https://github.com/japaric/cross).
|
|
|
|
|
|
Fix ICE on const eval of union field
MIR's `Const::get_field()` attempts to retrieve the value for a given field in a constant. In the case of a union constant it was falling through to a generic `const_get_elt` based on the field index. As union fields don't have an index this caused an ICE in `llvm_field_index`.
Fix by simply returning the current value when accessing any field in a union. This works because all union fields start at byte offset 0.
The added test uses `const_fn` it ensure the field is extracted using MIR's const evaluation. The crash is reproducible without it, however.
Fixes #47788
r? @eddyb
|
|
Fix never-type rvalue ICE
This fixes #43061.
r? @nikomatsakis
A small post-mortem as a follow-up to our investigations in https://github.com/rust-lang/rust/pull/47291:
The problem as I understand it is that when `NeverToAny` coercions are made, the expression/statement that is coerced may be enclosed in a block. In our case, the statement `x;` was being transformed to something like: `NeverToAny( {x;} )`. Then, `NeverToAny` is transformed into an expression:
https://github.com/rust-lang/rust/blob/000fbbc9b8f88adc6a417f1caef41161f104250f/src/librustc_mir/build/expr/into.rs#L52-L59
Which ends up calling `ast_block_stmts` on the block `{x;}`, which triggers this condition:
https://github.com/rust-lang/rust/blob/000fbbc9b8f88adc6a417f1caef41161f104250f/src/librustc_mir/build/block.rs#L141-L147
In our case, there is no return expression, so `push_assign_unit` is called. But the block has already been recorded as _diverging_, meaning the result of the block will be assigned to a location of type `!`, rather than `()`. This causes the MIR error.
I'm assuming the `NeverToAny` coercion code is doing what it's supposed to (there don't seem to be any other problems), so fixing the issue simply consists of checking that the destination for the return value actually _is_ supposed to be a unit. (If no return value is given, the only other possible type for the return value is `!`, which can just be ignored, as it will be unreachable anyway.)
I checked the other cases of `push_assign_unit`, and it didn't look like they could be affected by the divergence issue (blocks are kind of special-cased in this regard as far as I can tell), so this should be sufficient to fix the issue.
|
|
|
|
MIR's `Const::get_field()` attempts to retrieve the value for a given
field in a constant. In the case of a union constant it was falling
through to a generic `const_get_elt` based on the field index. As union
fields don't have an index this caused an ICE in `llvm_field_index`.
Fix by simply returning the current value when accessing any field in a
union. This works because all union fields start at byte offset 0.
The added test uses `const_fn` it ensure the field is extracted using
MIR's const evaluation. The crash is reproducible without it, however.
Fixes #47788
|
|
Rollup of 19 pull requests
- Successful merges: #47415, #47437, #47439, #47453, #47460, #47502, #47529, #47600, #47607, #47618, #47626, #47656, #47668, #47696, #47701, #47705, #47710, #47711, #47719
- Failed merges: #47455, #47521
|
|
|
|
Fixes #47139
|
|
|
|
|
|
|
|
|
|
rollup
|
|
|
|
Print inlined functions on Windows
Split from https://github.com/rust-lang/rust/pull/45637
r? @alexcrichton
|
|
Fixes #47364
|
|
|
