In #28864, @aarzee submitted some whitespace fixes. I r+'d it. But
@retp998 noticed[1] that this file is explicitly a test of this kind of
whitespace, and so I shouldn't have changed it. This restores the old
line endings.
1: https://github.com/rust-lang/rust/pull/28864#discussion_r41332279
In #28864, @aarzee submitted some whitespace fixes. I r+'d it. But
@retp998 noticed[1] that this file is explicitly a test of this kind of
whitespace, and so I shouldn't have changed it. This restores the old
line endings.
1: https://github.com/rust-lang/rust/pull/28864#discussion_r41332279
This turned up as part of #3170. When constructing an `undef` value to
return in the error case, we were trying to get the element type of the
Rust-level value being indexed instead of the underlying array; when
indexing a slice, that's not an array and the LLVM assertion failure
reflects this.
The regression test is a lightly altered copy of `const-array-oob.rs`.
This lint warning was originally intended to help against misuse of the old Rust
`int` and `uint` types in FFI bindings where the Rust `int` was not equal to the
C `int`. This confusion no longer exists (as Rust's types are now `isize` and
`usize`), and as a result the need for this lint has become much less over time.
Additionally, starting with [the RFC for libc][rfc] it's likely that `isize` and
`usize` will be quite common in FFI bindings (e.g. they're the definition of
`size_t` and `ssize_t` on many platforms).
[rfc]: https://github.com/rust-lang/rfcs/pull/1291
This commit disables these lints to instead consider `isize` and `usize` valid
types to have in FFI signatures.
This turned up as part of #3170. When constructing an `undef` value to
return in the error case, we were trying to get the element type of the
Rust-level value being indexed instead of the underlying array; when
indexing a slice, that's not an array and the LLVM assertion failure
reflects this.
The regression test is a lightly altered copy of `const-array-oob.rs`.
The reason this was not failing is fascinating. The variable $(rustc)
is empty, so the make recipe was expanded as " -o foo foo.rs". make
interpreted this as an instruction to run the command "o foo foo.rs"
and ignore any failure that occurred, because it uses a leading '-' on
a command to signal that behavior.
By RFC1214:
> Before calling a fn, we check that its argument and return types are WF.
The previous code only checked the trait-ref, which was not enough
in several cases.
As this is a soundness fix, it is a [breaking-change]. Some new annotations are needed, which I think are because of #18653 and the imperfection of `projection_must_outlive` (that can probably be worked around by moving the wf obligation later).
Fixes#28609
r? @nikomatsakis
The reason this was not failing is fascinating. The variable $(rustc)
is empty, so the make recipe was expanded as " -o foo foo.rs". make
interpreted this as an instruction to run the command "o foo foo.rs"
and ignore any failure that occurred, because it uses a leading '-' on
a command to signal that behavior.
By RFC1214:
Before calling a fn, we check that its argument and return types are WF. This check takes place after all higher-ranked lifetimes have been instantiated. Checking the argument types ensures that the implied bounds due to argument types are correct. Checking the return type ensures that the resulting type of the call is WF.
The previous code only checked the trait-ref, which was not enough
in several cases.
As this is a soundness fix, it is a [breaking-change].
Fixes#28609
This PR closes out #28716 and #28735 by making two changes to the compiler:
1. The `--emit` flag to the compiler now supports the ability to specify the output file name of a partuclar emit type. For example `--emit dep-info=bar.d,asm=foo.s,link` is now accepted.
2. The dep-info emission now emits a dummy target for all input file names to protect against deleted files.
The behavior here isn't really ideal, but we can't really do much better
given the current state of constant evaluation.
The changes to ExprUseVisitor are to avoid a compile error; apparently
that bit of code is extremely sensitive to changes in other areas of the
compiler.
Fixes#28670, and probably a bunch of duplicates.
This commit swaps the order of linking local native libraries and upstream
native libraries on the linker command line. Detail of bugs this can cause can
be found in #28595, and this change also invalidates the test case that was
added for #12446 which is now considered a bug because the downstream dependency
would need to declare that it depends on the native library somehow.
Closes#28595
The behavior here isn't really ideal, but we can't really do much better
given the current state of constant evaluation.
Fixes#28670, and probably a bunch of duplicates.
This lint warning was originally intended to help against misuse of the old Rust
`int` and `uint` types in FFI bindings where the Rust `int` was not equal to the
C `int`. This confusion no longer exists (as Rust's types are now `isize` and
`usize`), and as a result the need for this lint has become much less over time.
Additionally, starting with [the RFC for libc][rfc] it's likely that `isize` and
`usize` will be quite common in FFI bindings (e.g. they're the definition of
`size_t` and `ssize_t` on many platforms).
[rfc]: https://github.com/rust-lang/rfcs/pull/1291
This commit disables these lints to instead consider `isize` and `usize` valid
types to have in FFI signatures.
Currently the compiler supports the ability to emit multiple output types as
part of one compilation (e.g. asm, LLVM IR, bytecode, link, dep-info, etc). It
does not, however, support the ability to customize the output filename for each
of these output types. The `-o` flag is ignored if multiple emit types are
specified (and the compiler emits a warning about this).
Normally this doesn't matter too much, but in the case of `dep-info` it can lead
to a number of problems (e.g. see #28716). By allowing customization of the
output filename for each emit type we're able to solve the problems in that
issue.
This commit adds support for the `--emit` option to the compiler to look like:
rustc foo.rs --emit dep-info=.deps/foo.d,link
This indicates that the `dep-info` output type will be placed at `.deps/foo.d`
and the `link` output type will otherwise be determined via the `--out-dir` and
`-o` flags.
Closes#28716
Travis CI has new infrastructure using the Google Compute Engine which has both
faster CPUs and more memory, and we've been encouraged to switch as it should
help our build times! The only downside currently, however, is that IPv6 is
disabled, causing a number of standard library tests to fail.
Consequently this commit tweaks our travis config in a few ways:
* ccache is disabled as it's not working on GCE just yet
* Docker is used to run tests inside which reportedly will get IPv6 working
* A system LLVM installation is used instead of building LLVM itself. This is
primarily done to reduce build times, but we want automation for this sort of
behavior anyway and we can extend this in the future with building from source
as well if needed.
* gcc-specific logic is removed as the docker image for Ubuntu gives us a
recent-enough gcc by default.
I just removed the num_cpus dependency (because we don't want that in there), using 4 threads instead.
I should add that Veedrac asked me to submit this here in his name.
