Remove unnecessary LLVMRustPersonalityFn binding
LLVM Core C bindings provide this function for all the versions back to what we support (3.7), and
helps to avoid this unnecessary builder->function transition every time. Also a negative diff.
Fixes#38462 (although it was pretty much fixed already)
Improve doc cfg(test) and tests directory
Hi,
I was facing a problem with my code organisation. I was using a tests directory and i defined some `#[cfg(test)]` in my `src/`. But i was not able to use it in my `tests` folder.
```bash
.
├── Cargo.lock
├── Cargo.toml
├── src
│ ├── lib.rs
│ └── test.rs
└── tests
└── x.rs
```
> src/lib.rs
```rust
pub mod test;
fn tesst() {
assert!(test::t());
}
```
> src/test.rs
```rust
pub fn t() -> bool { true }
```
> test/x.rs
```rust
extern crate testt;
use testt::test;
fn tesst() {
assert!(test::t());
}
```
I was unable to compile using `cargo test`:
```bash
error[E0432]: unresolved import `testt::test`
--> tests/x.rs:3:5
|
3 | use testt::test;
| ^^^^^^^^^^^ no `test` in `testt`
```
If i remove the `tests` directory everything works fine. To use an utils module in your `tests` directory, you need to create a module in the directory (like `tests/utils.rs`). My `tests/x.rs` look like this now:
```rust
extern crate testt;
mod utils;
fn tesst() {
assert!(utils::t());
}
```
And my tree:
```bash
.
├── Cargo.lock
├── Cargo.toml
├── src
│ └── lib.rs
└── tests
├── utils.rs
└── x.rs
```
I think that thing must be documented in the book.
Ping:
- @badboy : Because he's the one who showed me the path
- @shahn : Because he helped me too to find the solution
Signed-off-by: Freyskeyd <simon.paitrault@iadvize.com>
Use less syscalls in `anon_pipe()`
Save a `ENOSYS` failure from `pipe2` and don't try again.
Use `cvt` instead of `cvt_r` for `pipe2` - `EINTR` is not an error
`pipe2` can return.
Add clearer error message using `&str + &str`
This is the first part of #39018. One of the common things for new users
coming from more dynamic languages like JavaScript, Python or Ruby is to
use `+` to concatenate strings. However, this doesn't work that way in
Rust unless the first type is a `String`. This commit adds a check for
this use case and outputs a new error as well as a suggestion to guide
the user towards the desired behavior. It also adds a new test case to
test the output of the error.
Privatize constructors of tuple structs with private fields
This PR implements the strictest version of such "privatization" - it just sets visibilities for struct constructors, this affects everything including imports.
```
visibility(struct_ctor) = min(visibility(struct), visibility(field_1), ..., visibility(field_N))
```
Needs crater run before proceeding.
Resolves https://github.com/rust-lang/rfcs/issues/902
r? @nikomatsakis
The old code created a flat listing of "HIR -> WorkProduct" edges.
While perfectly general, this could lead to a lot of repetition if the
same HIR nodes affect many work-products. This is set to be a problem
when we start to skip typeck, since we will be adding a lot more
"work-product"-like nodes.
The newer code uses an alternative strategy: it "reduces" the graph
instead. Basically we walk the dep-graph and convert it to a DAG, where
we only keep intermediate nodes if they are used by multiple
work-products.
This DAG does not contain the same set of nodes as the original graph,
but it is guaranteed that (a) every output node is included in the graph
and (b) the set of input nodes that can reach each output node is
unchanged.
(Input nodes are basically HIR nodes and foreign metadata; output nodes
are nodes that have assocaited state which we will persist to disk in
some way. These are assumed to be disjoint sets.)
Fix backtraces on i686-pc-windows-gnu by disabling FPO
This might have performance implications. But do note that MSVC
disables FPO by default nowadays and it's use is limited in exception
heavy languages like C++.
See discussion in: #39234Closes: #28218
rustdoc: Suppress warnings/errors with --test
Threads spawned by the test framework have their output captured by default, so
for `rustdoc --test` threads this propagates that capturing to the spawned
thread that we now have.
Closes#39327
travis: Gate on some minimal support for incremental compilation.
This commit adds a travis job that
1. builds a stage2 compiler in incremental mode (but with empty incremental compilation cache), and
2. builds and runs the run-pass test suite also in incremental mode.
Building incrementally with an empty cache makes sure that the compiler doesn't crash in dependency tracking during bootstrapping. Executing the incrementally built test suite gives some measure of confidence that we generate valid code.
Note, however, that the above does not give strong guarantees about the validity of incremental compilation, it just provides a basis for being able to rely on from-scratch incr. comp. builds as reference values in further tests (which then do actual incremental compilation).
r? @alexcrichton
