Auto merge of #51702 - ecstatic-morse:infinite-loop-detection, r=oli-obk
Infinite loop detection for const evaluation
Resolves #50637.
An `EvalContext` stores the transient state (stack, heap, etc.) of the MIRI virtual machine while it executing code. As long as MIRI only executes pure functions, we can detect if a program is in a state where it will never terminate by periodically taking a "snapshot" of this transient state and comparing it to previous ones. If any two states are exactly equal, the machine must be in an infinite loop.
Instead of fully cloning a snapshot every time the detector is run, we store a snapshot's hash. Only when a hash collision occurs do we fully clone the interpreter state. Future snapshots which cause a collision will be compared against this clone, causing the interpreter to abort if they are equal.
At the moment, snapshots are not taken until MIRI has progressed a certain amount. After this threshold, snapshots are taken every `DETECTOR_SNAPSHOT_PERIOD` steps. This means that an infinite loop with period `P` will be detected after a maximum of `2 * P * DETECTOR_SNAPSHOT_PERIOD` interpreter steps. The factor of 2 arises because we only clone a snapshot after it causes a hash collision.
This is done using the ipcd daemon. It's not exactly like unix sockets because there is not actually a physical file for the path, but it's close enough for a basic implementation :)
This allows mio-uds and tokio-uds to work with a few modifications as well, which is exciting!
Auto merge of #51230 - nikic:no-verify-lto, r=pnkfelix
Disable LLVM verification by default
Currently -Z no-verify only controls IR verification prior to LLVM codegen, while verification is performed unconditionally both before and after linking with (Thin)LTO.
Also wondering what the sentiment is on disabling verification by default (and e.g. only enabling it on ALT builds with assertions). This does not seem terribly useful outside of rustc development and it does seem to show up in profiles (at something like 3%).
**EDIT:** A table showing the various configurations and what is enabled when.
| Configuration | Dynamic verification performed | LLVM static assertions compiled in |
| --- | --- | --- |
| alt builds | | yes |
| nightly builds | | no |
| stable builds | | no |
| CI builds | | |
| dev builds in a checkout | | |
Auto merge of #51966 - alexcrichton:llvm7, r=michaelwoerister
Upgrade to LLVM's master branch (LLVM 7)
### Current status
~~Blocked on a [performance regression](https://github.com/rust-lang/rust/pull/51966#issuecomment-402320576). The performance regression has an [upstream LLVM issue](https://bugs.llvm.org/show_bug.cgi?id=38047) and has also [been bisected](https://reviews.llvm.org/D44282) to an LLVM revision.~~
Ready to merge!
---
This commit upgrades the main LLVM submodule to LLVM's current master branch.
The LLD submodule is updated in tandem as well as compiler-builtins.
Along the way support was also added for LLVM 7's new features. This primarily
includes the support for custom section concatenation natively in LLD so we now
add wasm custom sections in LLVM IR rather than having custom support in rustc
itself for doing so.
Some other miscellaneous changes are:
* We now pass `--gc-sections` to `wasm-ld`
* The optimization level is now passed to `wasm-ld`
* A `--stack-first` option is passed to LLD to have stack overflow always cause
a trap instead of corrupting static data
* The wasm target for LLVM switched to `wasm32-unknown-unknown`.
* The syntax for aligned pointers has changed in LLVM IR and tests are updated
to reflect this.
* ~~The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug]~~
Nowadays we've been mostly only upgrading whenever there's a major release of
LLVM but enough changes have been happening on the wasm target that there's been
growing motivation for quite some time now to upgrade out version of LLD. To
upgrade LLD, however, we need to upgrade LLVM to avoid needing to build yet
another version of LLVM on the builders.
The revision of LLVM in use here is arbitrarily chosen. We will likely need to
continue to update it over time if and when we discover bugs. Once LLVM 7 is
fully released we can switch to that channel as well.
I don't see why MC should fail on well-formed code, so it might be a
better idea to just add a `delay_span_bug` there (anyone remember the
`cat_expr Errd` bug from the 1.0 days?).
However, I don't think this is a good idea to backport a new delay_span_bug
into stable and this code is going away soon-ish anyway.
Rollup merge of #52195 - alexcrichton:no-tmp, r=pnkfelix
rustc: Avoid /tmp/ in graphviz writing
This issue was reported to security@rust-lang.org by Sebastien Marie following
our recent [security advisory][1]. Because `/tmp` is typically globally writable
it's possible for one user to place symlinks in `/tmp` pointing to files in
another user's directories, causing `rustc` to overwrite the contents of
innocent files by accident.
This patch instead defaults the output path here to the cwd which should avoid
this issue.
Rollup merge of #52171 - bharrisau:fsub-count, r=estebank
Correct some codegen stats counter inconsistencies
I noticed some possible typos/inconsistencies in the codegen counters. For example, `fsub` was getting counted as an integer `sub`, whereas `fadd` was counted as an add. And `addincoming` was only being counted on the initial call.
Only remaining inconsistencies I can see are things like `fadd_fast` are counted as `fadd`. But the vector versions like `vector_reduce_fmax_fast` are counted as `vector.reduce.fmax_fast` not as their 'base' versions (`vector_reduce_fmax` is counted as `vector.reduce.fmax`).
Rollup merge of #52149 - willmo:transparent-atomics, r=cramertj
Add #[repr(transparent)] to Atomic* types
This allows them to be used in `#[repr(C)]` structs without warnings. Since rust-lang/rfcs#1649 and rust-lang/rust#35603 they are already documented to have "the same in-memory representation as" their corresponding primitive types. This just makes that explicit.
This was briefly part of #51395, but was controversial and therefore dropped. But it turns out that it's essentially already documented (which I had forgotten).
Rollup merge of #52064 - Valloric:patch-1, r=cramertj
Clarifying how the alignment of the struct works
The docs were not specifying how to compute the alignment of the struct, so I had to spend some time trying to figure out how that works. Found the answer [on this page](http://camlorn.net/posts/April%202017/rust-struct-field-reordering.html):
> The total size of this struct is 5, but the most-aligned field is b with alignment 2, so we round up to 6 and give the struct an alignment of 2 bytes.
Rollup merge of #51612 - ashtneoi:51515-missing-first-char, r=pnkfelix
NLL: fix E0594 "change to mutable ref" suggestion
Fix #51515.
Fix #51879.
Questions:
- [x] Is this the right place to fix this? It feels brittle, being so close to the frontend. **It's probably fine.**
- [ ] Have I missed any other cases that trigger this behavior?
- [x] Is it okay to use HELP and SUGGESTION in the UI test? **Yes.**
- [x] Do I need more tests for this? **No.**
Alex Crichton [Fri, 1 Jun 2018 17:20:00 +0000 (10:20 -0700)]
Upgrade to LLVM's master branch (LLVM 7)
This commit upgrades the main LLVM submodule to LLVM's current master branch.
The LLD submodule is updated in tandem as well as compiler-builtins.
Along the way support was also added for LLVM 7's new features. This primarily
includes the support for custom section concatenation natively in LLD so we now
add wasm custom sections in LLVM IR rather than having custom support in rustc
itself for doing so.
Some other miscellaneous changes are:
* We now pass `--gc-sections` to `wasm-ld`
* The optimization level is now passed to `wasm-ld`
* A `--stack-first` option is passed to LLD to have stack overflow always cause
a trap instead of corrupting static data
* The wasm target for LLVM switched to `wasm32-unknown-unknown`.
* The syntax for aligned pointers has changed in LLVM IR and tests are updated
to reflect this.
* The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug]
Nowadays we've been mostly only upgrading whenever there's a major release of
LLVM but enough changes have been happening on the wasm target that there's been
growing motivation for quite some time now to upgrade out version of LLD. To
upgrade LLD, however, we need to upgrade LLVM to avoid needing to build yet
another version of LLVM on the builders.
The revision of LLVM in use here is arbitrarily chosen. We will likely need to
continue to update it over time if and when we discover bugs. Once LLVM 7 is
fully released we can switch to that channel as well.
Auto merge of #51612 - ashtneoi:51515-missing-first-char, r=pnkfelix
NLL: fix E0594 "change to mutable ref" suggestion
Fix #51515.
Fix #51879.
Questions:
- [x] Is this the right place to fix this? It feels brittle, being so close to the frontend. **It's probably fine.**
- [ ] Have I missed any other cases that trigger this behavior?
- [x] Is it okay to use HELP and SUGGESTION in the UI test? **Yes.**
- [x] Do I need more tests for this? **No.**
Auto merge of #52196 - ollie27:rustdoc_ctor_imports, r=QuietMisdreavus
rustdoc: Hide struct and enum variant constructor imports
This is fallout from #51425. The duplicate variant imports can be seen [here](https://doc.rust-lang.org/nightly/std/prelude/v1/index.html) for example.
This is fixing a regression so could be backported to beta.
Auto merge of #52191 - SimonSapin:alloc_error_handler, r=alexcrichton
Implement #[alloc_error_handler]
This to-be-stable attribute is equivalent to `#[lang = "oom"]`. It is required when using the `alloc` crate without the `std` crate. It is called by `handle_alloc_error`, which is in turned called by "infallible" allocations APIs such as `Vec::push`.
Auto merge of #52168 - nikomatsakis:nll-region-name, r=estebank
find and highlight the `&` or `'_` in `region_name`
Before:
```
--> $DIR/dyn-trait-underscore.rs:18:5
|
LL | fn a<T>(items: &[T]) -> Box<dyn Iterator<Item=&T>> {
- | ----- lifetime `'1` appears in this argument
LL | Box::new(items.iter()) //~ ERROR cannot infer an appropriate lifetime
| ^^^^^^^^^^^^^^^^^^^^^^ cast requires that `'1` must outlive `'static`
```
After:
```
--> $DIR/dyn-trait-underscore.rs:18:5
|
LL | fn a<T>(items: &[T]) -> Box<dyn Iterator<Item=&T>> {
+ | - let's call the lifetime of this reference `'1`
LL | Box::new(items.iter()) //~ ERROR cannot infer an appropriate lifetime
| ^^^^^^^^^^^^^^^^^^^^^^ cast requires that `'1` must outlive `'static`
```
Not intended as the final end point necessarily in any sense. I intentionally left some to-do points to fill in later:
- Does not apply to upvars in closures yet (should be relatively easy)
- Does not handle the case where we can't find a precise match very well
- And of course we can still tweak wording
but shows the basic idea of how to make the `Ty` and `hir::Ty` to find a good spot to highlight.
Auto merge of #52177 - ljedrz:bare_gcc_warning, r=alexcrichton
Warn windows-gnu users that the bundled gcc can't compile
Add a `DO NOT USE THIS gcc.exe FOR COMPILATION.txt` file to `lib\rustlib\*-pc-windows-gnu\bin` folders in `windows-gnu` installations in order to warn against attempting to use the bundled `gcc.exe` as a C compiler. I'm pretty sure that location is usually found manually, so this should be easily noticeable.
This mistake has been made plenty of times and has lead to misunderstandings:
Rust: [Bundled gcc (windows x64) is unable to build any c file](https://github.com/rust-lang/rust/issues/24418)
gtk-rs: [Compiling on windows](https://github.com/gtk-rs/gtk/issues/625)
bzip2-rs: [Build failure at gcc level: blocksort.c not found](https://github.com/alexcrichton/bzip2-rs/issues/30)
Alternatives: rename the bundled `gcc.exe` to e.g. `rustc-gcc.exe` or `gcc-linker.exe`. This might require a more comprehensive change or break crates already using it as a linker.
Auto merge of #51583 - cuviper:packed_pair-bool, r=Mark-Simulacrum
Store scalar pair bools as i8 in memory
We represent `bool` as `i1` in a `ScalarPair`, unlike other aggregates,
to optimize IR for checked operators and the like. With this patch, we
still do so when the pair is an immediate value, but we use the `i8`
memory type when the value is loaded or stored as an LLVM aggregate.
So `(bool, bool)` looks like an `{ i1, i1 }` immediate, but `{ i8, i8 }`
in memory. When a pair is a direct function argument, `PassMode::Pair`,
it is still passed using the immediate `i1` type, but as a return value
it will use the `i8` memory type. Also, `bool`-like` enum tags will now
use scalar pairs when possible, where they were previously excluded due
to optimization issues.
Auto merge of #52100 - nielx:fix/rust_driver-stacklimit, r=cramertj
Haiku: work around the lack of setrlimit
The default Unix codepath fails, because Haiku does not implement
setrlimit for stack size. Thus we create an additional path.
By default, Haiku has the desired 16 MB stack, therefore in general
we do not have to spawn a new thread. The code has been written in
such a way that any changes in Haiku or in Rust will be adapted to.
Alex Crichton [Mon, 9 Jul 2018 22:26:57 +0000 (15:26 -0700)]
rustc: Avoid /tmp/ in graphviz writing
This issue was reported to security@rust-lang.org by Sebastien Marie following
our recent [security advisory][1]. Because `/tmp` is typically globally writable
it's possible for one user to place symlinks in `/tmp` pointing to files in
another user's directories, causing `rustc` to overwrite the contents of
innocent files by accident.
This patch instead defaults the output path here to the cwd which should avoid
this issue.
Simon Sapin [Fri, 6 Jul 2018 13:49:52 +0000 (15:49 +0200)]
Implement #[alloc_error_handler]
This to-be-stable attribute is equivalent to `#[lang = "oom"]`.
It is required when using the alloc crate without the std crate.
It is called by `handle_alloc_error`, which is in turned called
by "infallible" allocations APIs such as `Vec::push`.
Auto merge of #52159 - SimonSapin:alloc-prelude, r=alexcrichton
Add the `alloc::prelude` module
It contains the re-exports that are in `std::prelude::v1` but not in `core::prelude::v1`.
Calling it prelude is somewhat of a misnomer since (unlike those modules in `std` or `core`) its contents are never implicitly imported in modules. Rather it is intended to be used with an explicit glob import like `use alloc::prelude::*;`. However there is precedent for the same misnomer with `std::io::prelude`, for example.
This new module is unstable with the same feature name as the `alloc` care. They are proposed for stabilization together in RFC https://github.com/rust-lang/rfcs/pull/2480.
Auto merge of #52166 - orlp:master, r=joshtriplett
Performance improvement of Vec's swap_remove.
The old implementation *literally* swapped and then removed, which resulted in unnecessary move instructions. The new implementation does use unsafe code, but is easy to see that it is correct.
Auto merge of #52106 - PramodBisht:issue/52049, r=oli-obk
Don't suggest `let` bindings if they don't help with borrows
@oli-obk I have added a condition to address #52049, right now, this is on WIP because I think code change is also required on `error_reporting.rs`. Plus I need to check if any test cases fail.
I will ping you again if everything passes
This allows them to be used in #[repr(C)] structs without warnings. Since rust-lang/rfcs#1649 and rust-lang/rust#35603 they are already documented to have "the same in-memory representation as" their corresponding primitive types. This just makes that explicit.
Auto merge of #51955 - zackmdavis:item_semi, r=oli-obk
clarify why we're suggesting removing semicolon after braced items
Previously (issue #46186, pull-request #46258), a suggestion was added
to remove the semicolon after we fail to parse an item, but issue #51603
complains that it's still insufficiently obvious why. Let's add a note.
Simon Sapin [Fri, 6 Jul 2018 22:43:11 +0000 (00:43 +0200)]
Add the `alloc::prelude` module
It contains the re-exports that are in `std::prelude::v1`
but not in `core::prelude::v1`.
Calling it prelude is somewhat of a misnomer since (unlike those modules
in `std` or `core`) its contents are never implicitly imported in modules.
Rather it is intended to be used with an explicit glob import like
`use alloc::prelude::*;`.
However there is precedent for the same misnomer with `std::io::prelude`,
for example.
This new module is unstable with the same feature name as the `alloc` care.
They are proposed for stabilization together in RFC
https://github.com/rust-lang/rfcs/pull/2480
Auto merge of #52109 - michaelwoerister:ir-objs, r=alexcrichton
When doing linker-plugin based LTO, write LLVM bitcode obj-files instead of embedding the bitcode into the regular object file.
This PR makes the compiler emit LLVM bitcode object files instead of regular object files with the IR embed when compiling for linker-plugin-based LTO. The reasoning for switching the strategy is this:
- Embedding bitcode in a section of the object file actually makes us save bitcode twice in rlibs and Rust dylibs, once for linker-based LTO and once for rustc-based LTO. That's a waste of space.
- When compiling for plugin-based LTO, one usually has no use for the machine code also present in the object file. Generating it is a waste of time.
- When compiling for plugin-based LTO, `rustc` will skip running ThinLTO because the linker will do that anyway. This has the side effect of then generating poorly optimized machine code, which makes it even less useful (and may lead to users not knowing why their code is slow instead of getting an error).
- Not having machine code available makes it impossible for the linker to silently fall back to not inlining stuff across language boundaries.
- This is what Clang does and according to [the documentation](https://llvm.org/docs/BitCodeFormat.html#native-object-file-wrapper-format) is the better supported option.
- The current behavior (minus the runtime performance problems) is still available via `-Z embed-bitcode` (we might want to do this for `libstd` at some point).
projects / rust.git / log