File cannot be written, for example, if directory does not exist.
Before this commit:
```
% rustc -o nonexistent/program program.rs
error: could not write output: No such file or directory
```
With this commit:
```
% rustc -o nonexistent/program program.rs
error: could not write output to nonexistent/program.0.o: No such file or directory
```
This is useful when full rust command is not displayed, or when last error is followed by thousands of warnings.
So far, the source location an LLVM instruction was linked to was controlled by
`debuginfo::set_source_location()` and `debuginfo::clear_source_location()`.
This interface mimicked how LLVM's `IRBuilder` handles debug location
assignment. While this interface has some theoretical performance benefits, it
also makes things terribly unstable: One sets some quasi-global state and then
hopes that it is still correct when a given instruction is emitted---an
assumption that has been proven to not hold a bit too often.
This patch requires the debug source location to be passed to the actual
instruction emitting function. This makes source location assignment explicit
and will prevent future changes to `trans` from accidentally breaking things in
the majority of cases.
This patch does not yet implement the new principle for all instruction kinds
but the stepping experience should have improved significantly nonetheless
already.
This commit is an implementation of [RFC 565][rfc] which is a stabilization of
the `std::fmt` module and the implementations of various formatting traits.
Specifically, the following changes were performed:
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0565-show-string-guidelines.md
* The `Show` trait is now deprecated, it was renamed to `Debug`
* The `String` trait is now deprecated, it was renamed to `Display`
* Many `Debug` and `Display` implementations were audited in accordance with the
RFC and audited implementations now have the `#[stable]` attribute
* Integers and floats no longer print a suffix
* Smart pointers no longer print details that they are a smart pointer
* Paths with `Debug` are now quoted and escape characters
* The `unwrap` methods on `Result` now require `Display` instead of `Debug`
* The `Error` trait no longer has a `detail` method and now requires that
`Display` must be implemented. With the loss of `String`, this has moved into
libcore.
* `impl<E: Error> FromError<E> for Box<Error>` now exists
* `derive(Show)` has been renamed to `derive(Debug)`. This is not currently
warned about due to warnings being emitted on stage1+
While backwards compatibility is attempted to be maintained with a blanket
implementation of `Display` for the old `String` trait (and the same for
`Show`/`Debug`) this is still a breaking change due to primitives no longer
implementing `String` as well as modifications such as `unwrap` and the `Error`
trait. Most code is fairly straightforward to update with a rename or tweaks of
method calls.
[breaking-change]
Closes#21436
After PR #19766 added implicit coersions `*mut T -> *const T`, the explicit casts can be removed.
(The number of such casts turned out to be relatively small).
This commit aims to stabilize the `TypeId` abstraction by moving it out of the
`intrinsics` module into the `any` module of the standard library. Specifically,
* `TypeId` is now defined at `std::any::TypeId`
* `TypeId::hash` has been removed in favor of an implementation of `Hash`.
This commit also performs a final pass over the `any` module, confirming the
following:
* `Any::get_type_id` remains unstable as *usage* of the `Any` trait will likely
never require this, and the `Any` trait does not need to be implemented for
any other types. As a result, this implementation detail can remain unstable
until associated statics are implemented.
* `Any::downcast_ref` is now stable
* `Any::downcast_mut` is now stable
* `BoxAny` remains unstable. While a direct impl on `Box<Any>` is allowed today
it does not allow downcasting of trait objects like `Box<Any + Send>` (those
returned from `Thread::join`). This is covered by #18737.
* `BoxAny::downcast` is now stable.
This commit modifies resolve to prevent conflicts with typedef names in the same
method that conflits are prevented with enum names. This is a breaking change
due to the differing semantics in resolve, and any errors generated on behalf of
this change require that a conflicting typedef, module, or structure to be
renamed so they do not conflict.
[breaking-change]
Closes#6936
LLVM gets overwhelmed when presented with a zeroinitializer for a large
type. In unoptimised builds, it generates a long sequence of stores to
memory. In optmised builds, it manages to generate a standard memset of
zero values, but takes a long time doing so.
Call out to the `llvm.memset` function to zero out the memory instead.
Fixes#21264
This commit aims to stabilize the `TypeId` abstraction by moving it out of the
`intrinsics` module into the `any` module of the standard library. Specifically,
* `TypeId` is now defined at `std::any::TypeId`
* `TypeId::hash` has been removed in favor of an implementation of `Hash`.
This commit also performs a final pass over the `any` module, confirming the
following:
* `Any::get_type_id` remains unstable as *usage* of the `Any` trait will likely
never require this, and the `Any` trait does not need to be implemented for
any other types. As a result, this implementation detail can remain unstable
until associated statics are implemented.
* `Any::downcast_ref` is now stable
* `Any::downcast_mut` is now stable
* `BoxAny` remains unstable. While a direct impl on `Box<Any>` is allowed today
it does not allow downcasting of trait objects like `Box<Any + Send>` (those
returned from `Thread::join`). This is covered by #18737.
* `BoxAny::downcast` is now stable.
LLVM gets overwhelmed when presented with a zeroinitializer for a large
type. In unoptimised builds, it generates a long sequence of stores to
memory. In optmised builds, it manages to generate a standard memset of
zero values, but takes a long time doing so.
Call out to the `llvm.memset` function to zero out the memory instead.
File cannot be written, for example, if directory does not exist.
Before this commit:
```
% rustc -o nonexistent/program program.rs
error: could not write output: No such file or directory
```
With this commit:
```
% rustc -o nonexistent/program program.rs
error: could not write output to nonexistent/program.0.o: No such file or directory
```
This is useful when full rust command is not displayed, or when last
error is preceded by thousands of warnings.
This stops the compiler ICEing on the use of SIMD types in FFI signatures. It emits correct code for LLVM intrinsics, but I am quite unsure about the ABI handling in general so I've added a new feature gate `simd_ffi` to try to ensure people don't use it without realising there's a non-trivial risk of codegen brokenness.
Closes#20043.
I don't know if this handling of SIMD types is correct for the C ABI on
all platforms, so lets add an even finer feature gate than just the
`simd` one.
The `simd` one can be used with (relatively) little risk of complete
nonsense, the reason for it is that it is likely that things will
change. Using the types in FFI with an incorrect ABI will at best give
absolute nonsense results, but possibly cause serious breakage too, so
this is a step up in badness, hence a new feature gate.
With the addition of separate search paths to the compiler, it was intended that
applications such as Cargo could require a `--extern` flag per `extern crate`
directive in the source. The system can currently be subverted, however, due to
the `existing_match()` logic in the crate loader.
When loading crates we first attempt to match an `extern crate` directive
against all previously loaded crates to avoid reading metadata twice. This "hit
the cache if possible" step was erroneously leaking crates across the search
path boundaries, however. For example:
extern crate b;
extern crate a;
If `b` depends on `a`, then it will load crate `a` when the `extern crate b`
directive is being processed. When the compiler reaches `extern crate a` it will
use the previously loaded version no matter what. If the compiler was not
invoked with `-L crate=path/to/a`, it will still succeed.
This behavior is allowing `extern crate` declarations in Cargo without a
corresponding declaration in the manifest of a dependency, which is considered
a bug.
This commit fixes this problem by keeping track of the origin search path for a
crate. Crates loaded from the dependency search path are not candidates for
crates which are loaded from the crate search path.
With the addition of separate search paths to the compiler, it was intended that
applications such as Cargo could require a `--extern` flag per `extern crate`
directive in the source. The system can currently be subverted, however, due to
the `existing_match()` logic in the crate loader.
When loading crates we first attempt to match an `extern crate` directive
against all previously loaded crates to avoid reading metadata twice. This "hit
the cache if possible" step was erroneously leaking crates across the search
path boundaries, however. For example:
extern crate b;
extern crate a;
If `b` depends on `a`, then it will load crate `a` when the `extern crate b`
directive is being processed. When the compiler reaches `extern crate a` it will
use the previously loaded version no matter what. If the compiler was not
invoked with `-L crate=path/to/a`, it will still succeed.
This behavior is allowing `extern crate` declarations in Cargo without a
corresponding declaration in the manifest of a dependency, which is considered
a bug.
This commit fixes this problem by keeping track of the origin search path for a
crate. Crates loaded from the dependency search path are not candidates for
crates which are loaded from the crate search path.
As a result of this fix, this is a likely a breaking change for a number of
Cargo packages. If the compiler starts informing that a crate can no longer be
found, it likely means that the dependency was forgotten in your Cargo.toml.
[breaking-change]
This seems to match what clang does on arm, but I cannot do any
experimentation with mips, but it matches how the LLVM intrinsics are
defined in any case...
Unlike the intrinics in C, this types the SSE values base on integer
size. This matches the LLVM intrinsics which have concrete vector types
(`<4 x i32>` etc.), and is no loss of expressivity: if one is using a C
function that really takes an untyped integral SSE value, just give it
whatever Rust type makes most sense.
While it's unstable and will probably be replaced or "reformed" at some point, it's useful in the mean time to be able to introspect the type system when debugging, and not be limited to sized types.
Fixes#21058
There are two places left where we used to only know the byte
size of/offset into an array and had to cast to i8 and back to get the
right addresses. But by now, we always know the sizes in terms of the
number of elements in the array. In fact we have to add an extra Mul
instruction so we can use the weird cast-to-u8 code. So we should really
just embrace our new knowledge and use simple GEPs to do the address
calculations.
Fixes#3729
