This adds support for building the Rust compiler and standard
library for s390x-linux, allowing a full cross-bootstrap sequence
to complete. This includes:
- Makefile/configure changes to allow native s390x builds
- Full Rust compiler support for the s390x C ABI
(only the non-vector ABI is supported at this point)
- Port of the standard library to s390x
- Update the liblibc submodule to a version including s390x support
- Testsuite fixes to allow clean "make check" on s390x
Caveats:
- Resets base cpu to "z10" to bring support in sync with the default
behaviour of other compilers on the platforms. (Usually, upstream
supports all older processors; a distribution build may then chose
to require a more recent base version.) (Also, using zEC12 causes
failures in the valgrind tests since valgrind doesn't fully support
this CPU yet.)
- z13 vector ABI is not yet supported. To ensure compatible code
generation, the -vector feature is passed to LLVM. Note that this
means that even when compiling for z13, no vector instructions
will be used. In the future, support for the vector ABI should be
added (this will require common code support for different ABIs
that need different data_layout strings on the same platform).
- Two test cases are (temporarily) ignored on s390x to allow passing
the test suite. The underlying issues still need to be fixed:
* debuginfo/simd.rs fails because of incorrect debug information.
This seems to be a LLVM bug (also seen with C code).
* run-pass/union/union-basic.rs simply seems to be incorrect for
all big-endian platforms.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Fix argument to FIONBIO ioctl
The FIONBIO ioctl takes as argument a pointer to an integer, which
should be either 0 or 1 to indicate whether nonblocking mode is to
be switched off or on. The type of the pointed-to variable is "int".
However, the set_nonblocking routine in libstd/sys/unix/net.rs passes
a pointer to a libc::c_ulong variable. This doesn't matter on all
32-bit platforms and on all litte-endian platforms, but it will
break on big-endian 64-bit platforms.
Found while porting Rust to s390x (a big-endian 64-bit platform).
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Follow target ABI sign-/zero-extension rules for enum types
While attempting to port Rust to s390x, I ran into an ABI violation
(that caused rust_eh_personality to be miscompiled, breaking unwinding).
The problem is that this function returns an enum type, which is
supposed to be sign-extended according to the s390x ABI. However,
common code would ignore target sign-/zero-extension rules for any
types that do not satisfy is_integral(), which includes enums.
For the general case of Rust enum types, which map to structure types
with a discriminant, that seems correct. However, in the special case
of simple enums that map directly to C enum types (i.e. LLVM integers),
this is incorrect; we must follow the target extension rules for those.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Changes the definition for opaque structs to look like `pub struct Vec<T>
{ /* fields omitted */ }` to save space on the page.
Also only use one line for empty braced structs.
Due to missing noalias annotations for &mut T in general (issue #31681),
in larger programs extend_from_slice and extend_with_element may both
compile very poorly. What is observed is that the .set_len() calls are
not lifted out of the loop, even for `Vec<u8>`.
Use a local length variable for the Vec length instead, and use a scope
guard to write this value back to self.len when the scope ends or on
panic. Then the alias analysis is easy.
This affects extend_from_slice, extend_with_element, the vec![x; n]
macro, Write impls for Vec<u8>, BufWriter, etc (but may / may not
have triggered since inlining can be enough for the compiler to get it right).
Fix soundness bug described in #29859
This is an attempt at fixing the problems described in #29859 based on an IRC conversation between @nikomatsakis and I today. I'm waiting on a full build to come back, otherwise both tests trigger the correct error.
Removing the extraneous not_equal implementation for slices
Happened to stumble upon this one awhile back. Seemed a bit silly to have both the equals and not equals implementation when they're so similar.
macros: stackless expansion
After this PR, macro expansion cannot overflow the stack unless the expanded crate is too deep to fold.
Everything but the stackless placeholder expansion commit is also groundwork for macro modularization.
r? @nrc or @eddyb
rustbuild: per target musl-root
config.toml now accepts a target.$TARGET.musl-root key that lets you
override the "build" musl-root value, which is set via the --musl-root
flag or via the build.musl-root key.
With this change, it's now possible to compile std for several musl
targets at once. Here's are the sample commands to do such thing:
```
$ configure \
--enable-rustbuild \
--target=x86_64-unknown-linux-musl,arm-unknown-linux-musleabi \
--musl-root=/musl/x86_64-unknown-linux-musl/
$ edit config.toml && tail config.toml
[target.arm-unknown-linux-musleabi]
musl-root = "/x-tools/arm-unknown-linux-musleabi/arm-unknown-linux-musleabi/sysroot/usr"
$ make
```
r? @alexcrichton
With this we should be able to start producing releases of std for arm musl targets
rustdoc: Filter more incorrect methods inherited through Deref
Old code filtered out only static methods. This code also excludes &mut self methods if there is no DerefMut implementation.
Fixes#35169
The FIONBIO ioctl takes as argument a pointer to an integer, which
should be either 0 or 1 to indicate whether nonblocking mode is to
be switched off or on. The type of the pointed-to variable is "int".
However, the set_nonblocking routine in libstd/sys/unix/net.rs passes
a pointer to a libc::c_ulong variable. This doesn't matter on all
32-bit platforms and on all litte-endian platforms, but it will
break on big-endian 64-bit platforms.
Found while porting Rust to s390x (a big-endian 64-bit platform).
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
While attempting to port Rust to s390x, I ran into an ABI violation
(that caused rust_eh_personality to be miscompiled, breaking unwinding).
The problem is that this function returns an enum type, which is
supposed to be sign-extended according to the s390x ABI. However,
common code would ignore target sign-/zero-extension rules for any
types that do not satisfy is_integral(), which includes enums.
For the general case of Rust enum types, which map to structure types
with a discriminant, that seems correct. However, in the special case
of simple enums that map directly to C enum types (i.e. LLVM integers),
this is incorrect; we must follow the target extension rules for those.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
resolve: Suggest `use self` when import resolves
Improves errors messages by replacing "Maybe a missing `extern crate`" messages
with "Did you mean `self::...`" when the `self` import would succeed.
Fixes#34191.
Thank you for the help @jseyfried!
Fix "field is never used" warning to take unions into account
When compiling code containing a union with an unused field, rustc says
"struct field is never used".
Rather than saying "struct or union", or adding logic to determine the
type of the item, just change the message to "field is never used",
dropping the "struct".
Update tests accordingly.
Before:
```rust
error[E0106]: missing lifetime specifier
--> src/main.rs:10:10
|
10 | #[derive(Serialize, Deserialize)]
| ^ expected lifetime parameter
error[E0038]: the trait `T` cannot be made into an object
--> src/main.rs:15:15
|
15 | #[derive(Serialize, Deserialize)]
| ^^^^^^^^^^ the trait `T` cannot be made into an object
```
After:
```rust
error[E0106]: missing lifetime specifier
--> src/main.rs:11:1
|
11 | struct A {
| ^ expected lifetime parameter
error[E0038]: the trait `T` cannot be made into an object
--> src/main.rs:16:1
|
16 | struct B<'a> {
| ^ the trait `T` cannot be made into an object
```
incr. comp.: Take spans into account for ICH
This PR makes the ICH (incr. comp. hash) take spans into account when debuginfo is enabled.
A side-effect of this is that the SVH (which is based on the ICHs of all items in the crate) becomes sensitive to the tiniest change in a code base if debuginfo is enabled. Since we are not trying to model ABI compatibility via the SVH anymore (this is done via the crate disambiguator now), this should be not be a problem.
Fixes#33888.
Fixes#32753.
Updated E0559 to new format
Refactored a method that printed one suggested field name,
into a method that returns an `Option` of a suggestion
(Updated test cases accordingly)
r? @jonathandturner
Closes#36197
Update Error format for E0516, E0517, E0518
- E0518 Update error format #36111
- E0517 Update error format #36109
- E0516 Update error format #36108
- Part of #35233
r? @jonathandturner
Across crates only, converting a def-id into its def-key or def-path was
considered a read. This caused spurious reads when computing the symbol
name for some item.
The shadow graph supercedes the existing code that checked for
reads/writes without an active task and now adds the ability
to filter for specific edges.
It is useful to track down an errant edge that is being added. This is
not a perfect mechanism, since it doesn't consider (e.g.) if we are
in an ignored task, but it's helpful enough for now.
The goal here is to avoid writing to the `inherent_impls` map from
within the general `Coherence` task, and instead write to it as we
visit. Writing to it from the Coherence task is actually an information
leak; it happened to be safe because Coherence read from
`DepNode::Krate`, but that was very coarse.
I removed the `Rc` here because, upon manual inspection, nobody clones
the data in this table, and it meant that we can accumulate the data in
place. That said, the pattern that is used for the inherent impls map
is *generally* an anti-pattern (that is, holding the borrow lock for the
duration of using the contents), so it'd probably be better to
clone (and I doubt that would be expensive -- how many inherent impls
does a typical type have?).
config.toml now accepts a target.$TARGET.musl-root key that lets you
override the "build" musl-root value, which is set via the --musl-root
flag or via the build.musl-root key.
With this change, it's now possible to compile std for several musl
targets at once. Here's are the sample commands to do such thing:
```
$ configure \
--enable-rustbuild \
--target=x86_64-unknown-linux-musl,arm-unknown-linux-musleabi \
--musl-root=/musl/x86_64-unknown-linux-musl/
$ edit config.toml && tail config.toml
[target.arm-unknown-linux-musleabi]
musl-root = "/x-tools/arm-unknown-linux-musleabi/arm-unknown-linux-musleabi/sysroot/usr"
$ make
```
rustdoc: Fix associated consts in search results
Associated consts can appear in none trait impls so need to be treated
like methods when generating the search index.
Fixes#36031
Fix issue #36036.
Fix#36036.
We were treating an associated type as unsized even when the concrete instantiation was actually sized. Fix is to normalize before checking if it is sized.
Fix incorrect LLVM Linkage enum
Followup of #33994 to actually work.
The `Linkage` enum in librustc_llvm got out of sync with the version in LLVM and it caused two variants of the `#[linkage=""]` attribute to break.
This adds the functions `LLVMRustGetLinkage` and `LLVMRustSetLinkage` which convert between the Rust Linkage enum and the LLVM one, which should stop this from breaking every time LLVM changes it.
Possible remaining concerns:
1. There could be a codegen test to make sure that the attributes are applied correctly (I don't know how to do this).
2. ~~The test does not exercise the `appending` linkage. I can't figure out how to make a global static raw pointer to an array. This might not even be possible? If not we should probably remove appending linkage as its unusable in rust.~~ Appending linkage is not 'emittable' anyway.
3. The test only runs on Linux.
Fixes#33992
r? @alexcrichton
Typecheck refactor for `!`
Ping @nikomatsakis @eddyb. This is the PR for the typeck refactor for `!`. Is this what you guys had in mind? Is there anything else that needs doing on it?
We were treating an associated type as unsized even when the concrete
instantiation was actually sized. Fix is to normalize before checking
if it is sized.
Allow CompilerControllers to access rustc_plugin::registry::Registry
fixes#36064
I chose to put ructc_plugin::registry::Registry structure
into CompilerState structure, instead of Session structure.
This will preserve dependencies among librustc, libructc_driver, and libructc_plugin.
@jseyfried @sanxiyn
The `Linkage` enum in librustc_llvm got out of sync with the version in LLVM and it caused two variants of the #[linkage=""] attribute to break.
This adds the functions `LLVMRustGetLinkage` and `LLVMRustSetLinkage` which convert between the Rust Linkage enum and the LLVM one, which should stop this from breaking every time LLVM changes it.
Fixes#33992
Replace `_, _` with `..` in patterns
This is how https://github.com/rust-lang/rust/issues/33627 looks in action.
Looks especially nice in leftmost/rightmost positions `(first, ..)`/`(.., last)`.
I haven't touched libsyntax intentionally because the feature is still unstable.
rustbuild: add config.toml option to disable codegen tests
Fixes#36232.
I think it worked? Here's a build log where I tried to bootstrap, it crashed, then I added the setting to config.toml and it continued: https://gist.github.com/durka/cbf97cf04b8e065f1a2cfda4c1b6bf95
r? @alexcrichton
Update nightly docs supported Windows versions to match Getting Started page
https://doc.rust-lang.org/book/getting-started.html#tier-1 shows that Windows 7+ is officially supported (implying, for example Windows 10), but the nightly page only listed 7, 8, and Server 2008 R2).
Updated e0493 to new format (+ bonus).
Part of #35233.
Fixes#35999.
r? @jonathandturner
I'm not satisfied with the bonus part, there has to be an easier way to reach into the `Drop`'s span implementation. I'm all ears. :)
This option doesn't cause software FP routines
to be called it only changes the float ABI.
Additionally, this option is ignored by all targets,
except the ARM eabihf ones.
Add --Zsave-analysis-api
This is a save-analysis variation which can be used with libraries distributed without their source (e.g., libstd). It will allow IDEs and other tools to get info about types and create URLs to docs and source, without the unnecessary clutter of internal-only save-analysis info. I'm sure we'll iterate somewhat on the design, but this is a first draft.
Add --Zsave-analysis-api
This is a save-analysis variation which can be used with libraries distributed without their source (e.g., libstd). It will allow IDEs and other tools to get info about types and create URLs to docs and source, without the unnecessary clutter of internal-only save-analysis info. I'm sure we'll iterate somewhat on the design, but this is a first draft.
Fix optimization regressions for operations on [x; n]-initialized arrays.
Fixes#35662 by using `!=` instead of `<` as the stop condition for `[x; n]` initialization loops.
Also included is cc2009f02d, a hack to run the GVN pass twice, another time after InstCombine.
This hack results in removal of redundant `memset` and `memcpy` calls (from loops over arrays).
cc @nrc Can we get performance numbers on this? Not sure if it regresses anything else.
Rather than saying "struct or union" or adding logic to determine the
type of the item, just change the message to "field is never used",
dropping the "struct".
Update tests accordingly.
Implement untagged unions (RFC 1444)
cc https://github.com/rust-lang/rust/issues/32836
Notes:
- The RFC doesn't talk about `#[packed]` unions, this implementation supports them, packing changes union's alignment to 1 and removes trailing padding.
- The RFC doesn't talk about dynamically sized unions, this implementation doesn't support them and rejects them during wf-checking (similarly, dynamically sized enums are not supported as well).
- The lint for drop fields in unions can't work precisely before monomorphization, so it works pessimistically - non-`Copy` generic fields are reported, types not implementing `Drop` directly, but having non-trivial drop code are reported.
```
struct S(String); // Doesn't implement `Drop`
union U<T> {
a: S, // Reported
b: T, // Reported
}
```
- https://github.com/rust-lang/rust/pull/35764 was indeed helpful and landed timely, I didn't have to implement internal drop flags for unions.
- Unions are not permitted in constant patterns, because matching on union fields is unsafe, I didn't want unsafety checker to dig into all constants to uncover this possible unsafety.
- The RFC doesn't talk about `#[derive]`, generally trait impls cannot be derived for unions, but some of them can. I implemented only `#[derive(Copy)]` so far. In theory shallow `#[derive(Clone)]` can be derived as well if all union fields are `Copy`, I left it for later though, it requires changing how `Clone` impls are generated.
- Moving union fields is implemented as per https://github.com/rust-lang/rust/issues/32836#issuecomment-242511491.
- Testing strategy: union specific behavior is tested, sometimes very basically (e.g. debuginfo), behavior common for all ADTs (e.g. something like coherence
checks) is not generally tested.
r? @eddyb
rustc: Implement custom derive (macros 1.1)
This commit is an implementation of [RFC 1681] which adds support to the
compiler for first-class user-define custom `#[derive]` modes with a far more
stable API than plugins have today.
[RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md
The main features added by this commit are:
* A new `rustc-macro` crate-type. This crate type represents one which will
provide custom `derive` implementations and perhaps eventually flower into the
implementation of macros 2.0 as well.
* A new `rustc_macro` crate in the standard distribution. This crate will
provide the runtime interface between macro crates and the compiler. The API
here is particularly conservative right now but has quite a bit of room to
expand into any manner of APIs required by macro authors.
* The ability to load new derive modes through the `#[macro_use]` annotations on
other crates.
All support added here is gated behind the `rustc_macro` feature gate, both for
the library support (the `rustc_macro` crate) as well as the language features.
There are a few minor differences from the implementation outlined in the RFC,
such as the `rustc_macro` crate being available as a dylib and all symbols are
`dlsym`'d directly instead of having a shim compiled. These should only affect
the implementation, however, not the public interface.
This commit also ended up touching a lot of code related to `#[derive]`, making
a few notable changes:
* Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't
sure how to keep this behavior and *not* expose it to custom derive.
* Derive attributes no longer have access to unstable features by default, they
have to opt in on a granular level.
* The `derive(Copy,Clone)` optimization is now done through another "obscure
attribute" which is just intended to ferry along in the compiler that such an
optimization is possible. The `derive(PartialEq,Eq)` optimization was also
updated to do something similar.
---
One part of this PR which needs to be improved before stabilizing are the errors
and exact interfaces here. The error messages are relatively poor quality and
there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]`
not working by default. The custom attributes added by the compiler end up
becoming unstable again when going through a custom impl.
Hopefully though this is enough to start allowing experimentation on crates.io!
Introduce max_by/min_by on iterators
See https://github.com/rust-lang/rfcs/issues/1722 for reference.
It seems that there is `min`, `max` (simple computation of min/max), `min_by_key`, `max_by_key` (min/max by comparing mapped values) but no `min_by` and `max_by` (min/max according to comparison function). However, e.g. on vectors or slices there is `sort`, `sort_by_key` and `sort_by`.
Fixed E0529's label and unit test
Fixes#36195 part of #35233.
This is ready for review, but will likely fail Travis due to #36138. I changed the wording of the label, so feedback on that would be appreciated.
r? @jonathandturner
test: Add a min-llvm-version directive
We've got tests which require a particular version of LLVM to run as they're
testing bug fixes. Our build system, however, supports multiple LLVM versions,
so we can't run these tests on all LLVM versions.
This adds a new `min-llvm-version` directive for tests so they can opt out of
being run on older versions of LLVM. This then namely applies that logic to the
`issue-36023.rs` test case and...
Closes#36138
Update lifetime errors to specifically note temporaries
This PR updates the error message we give in the case of a temporary value not living long enough.
Before:
<img width="497" alt="screen shot 2016-08-31 at 10 02 47 am" src="https://cloud.githubusercontent.com/assets/547158/18138551/27a06794-6f62-11e6-9ee2-bdf8bed75ca7.png">
Now:
<img width="488" alt="screen shot 2016-08-31 at 10 03 01 am" src="https://cloud.githubusercontent.com/assets/547158/18138557/2e5cf322-6f62-11e6-9047-4a78abf3d78c.png">
Specifically, it makes the following changes:
* Detects if a temporary is being used. If so, it changes the labels to mention that a temporary value specifically is in question
* Simplifies wording of the existing labels to focus on lifetimes rather than values being valid
* Changes the help to a note, since the help+span wasn't as helpful (and sometimes more confusing) than just a note.
r? @nikomatsakis
Normalize the function signature of closures
Previously we didn't normalize the function signatures used for
closures. This didn't cause a problem in most cases, but caused an ICE
in during MIR type checking.
Fixes#36139
r? @eddyb
Document try!'s error conversion behaviour
try!'s documentation currently doesn't document the error conversion behaviour of the macro. This patch extends the documentation.
Open questions:
* is it worthwhile to have seperate examples with and without wrapping behaviour? It's not immediately obvious that From<T> for T is always defined. Though this is necessary for the macro to work in any case, is this the place to expect that knowledge.
This commit is an implementation of [RFC 1681] which adds support to the
compiler for first-class user-define custom `#[derive]` modes with a far more
stable API than plugins have today.
[RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md
The main features added by this commit are:
* A new `rustc-macro` crate-type. This crate type represents one which will
provide custom `derive` implementations and perhaps eventually flower into the
implementation of macros 2.0 as well.
* A new `rustc_macro` crate in the standard distribution. This crate will
provide the runtime interface between macro crates and the compiler. The API
here is particularly conservative right now but has quite a bit of room to
expand into any manner of APIs required by macro authors.
* The ability to load new derive modes through the `#[macro_use]` annotations on
other crates.
All support added here is gated behind the `rustc_macro` feature gate, both for
the library support (the `rustc_macro` crate) as well as the language features.
There are a few minor differences from the implementation outlined in the RFC,
such as the `rustc_macro` crate being available as a dylib and all symbols are
`dlsym`'d directly instead of having a shim compiled. These should only affect
the implementation, however, not the public interface.
This commit also ended up touching a lot of code related to `#[derive]`, making
a few notable changes:
* Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't
sure how to keep this behavior and *not* expose it to custom derive.
* Derive attributes no longer have access to unstable features by default, they
have to opt in on a granular level.
* The `derive(Copy,Clone)` optimization is now done through another "obscure
attribute" which is just intended to ferry along in the compiler that such an
optimization is possible. The `derive(PartialEq,Eq)` optimization was also
updated to do something similar.
---
One part of this PR which needs to be improved before stabilizing are the errors
and exact interfaces here. The error messages are relatively poor quality and
there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]`
not working by default. The custom attributes added by the compiler end up
becoming unstable again when going through a custom impl.
Hopefully though this is enough to start allowing experimentation on crates.io!
syntax-[breaking-change]
add mips64-gnu and mips64el-gnu targets
With this commit one can build no_core (and probably no_std as well)
Rust programs for these targets. It's not yet possible to cross compile
std for these targets because rust-lang/libc doesn't know about the
mips64 architecture.
These targets have been tested by cross compiling the "smallest hello"
program (see code below) and then running it under QEMU.
``` rust
extern {
fn puts(_: *const u8);
}
fn start(_: isize, _: *const *const u8) -> isize {
unsafe {
let msg = b"Hello, world!\0";
puts(msg as *const _ as *const u8);
}
0
}
trait Copy {}
trait Sized {}
```
cc #36015
r? @alexcrichton
cc @brson
The cabi stuff is likely wrong. I just copied cabi_mips source and changed some `4`s to `8`s and `32`s to `64`s. It was enough to get libc's `puts` to work but I'd like someone familiar with this module to check it.
implementing RFC 1623. This fixes#35897.
This is a work in progress. In particular, I want to add more tests,
especially the compile-fail test is very bare-bones.
Implement RFC 1560 behind `#![feature(item_like_imports)]`
This implements https://github.com/rust-lang/rfcs/pull/1560 (cc #35120) behind the `item_like_imports` feature gate.
The [RFC text](https://github.com/rust-lang/rfcs/blob/master/text/1560-name-resolution.md#changes-to-name-resolution-rules) describes the changes to name resolution enabled by `#, it improves performance quite a bit:
| phase | before | after |
| ----- | ------ | ----- |
| collection | 0.79s | 0.46s |
| translation | 6.8s | 3.2s |
| total | 11.92s | 7.15s |
r? @arielb1
Allow specification of the system V AMD64 ABI constraint.
This can be specified using `extern "sysV64" fn` on all platforms.
This ABI is used as the C ABI on unix platforms, but can only be specified there using extern "C". It was impossible to specify on other platforms. Meanwhile the win64 ABI, which was the extern "C" ABI on the windows platform could be specified on other platforms using extern "win64".
This pull request adds the the "sysV64" ABI constraint which exposes this calling convention on platforms where it is not the C ABI.
Turn the RFC1592 warnings into hard errors
The warnings have already reached stable, and I want to improve the trait error reporting code.
Turning warnings into errors, this is obviously a [breaking-change].
r? @nikomatsakis
cc @rust-lang/compiler
Implement std::convert traits for char
This is motivated by avoiding the `as` operator, which sometimes silently truncates, and instead use conversions that are explicitly lossless and infallible.
I’m less certain that `From<u8> for char` should be implemented: while it matches an existing behavior of `as`, it’s not necessarily the right thing to use for non-ASCII bytes. It effectively decodes bytes as ISO/IEC 8859-1 (since Unicode designed its first 256 code points to be compatible with that encoding), but that is not apparent in the API name.
Fix run-pass/signal-exit-status to not trigger UB by writing to NULL.
`run-pass/signal-exit-status` has had UB (NULL dereference) since it was introduced in #10109.
Fixes the test failure found by @camlorn while running under Windows Subsystem for Linux.
Update E0393 to new error format
Fixes#35632.
Part of #35233.
r? @jonathandturner
and a wired thing is that if i add another label
```rust
.span_label(span, &format!("missing reference to `{}`", def.name))
.span_label(span, &format!("because of the default `Self` reference, type parameters must be specified on object types"))
```
and add a new note in the test case like
```rust
trait A<T=Self> {}
fn together_we_will_rule_the_galaxy(son: &A) {}
//~^ ERROR E0393
//~| NOTE missing reference to `T`
//~| NOTE because of the default `Self` reference, type parameters must be specified on object types
```
it will complain that
```
running 1 test
test [compile-fail] compile-fail/E0393.rs ... FAILED
failures:
---- [compile-fail] compile-fail/E0393.rs stdout ----
error: /Users/zjh/Documents/rustspace/rust/src/test/compile-fail/E0393.rs:13: unexpected "error": '13:43: 13:44: the type parameter `T` must be explicitly specified [E0393]'
unexpected errors (from JSON output): [
Error {
line_num: 13,
kind: Some(
Error
),
msg: "13:43: 13:44: the type parameter `T` must be explicitly specified [E0393]"
}
]
```
it is a little bit confusing and through the blog post we can use `//~^` and `//~|` to support multiple notes, @jonathandturner am i missing something here?
Change E0259 to the new error format
Fixes#35514 as part of #35233.
Sorry about creating a new PR I was having a lot of troubles squashing the commit because I didn't properly branch the new feature.
r? @GuillaumeGomez
Implement synchronization scheme for incr. comp. directory
This PR implements a copy-on-write-based synchronization scheme for the incremental compilation cache directory. For technical details, see the documentation at the beginning of `rustc_incremental/persist/fs.rs`.
The PR contains unit tests for some functions but for testing whether the scheme properly handles races, a more elaborate test setup would be needed. It would probably involve a small tool that allows to manipulate the incremental compilation directory in a controlled way and then letting a compiler instance run against directories in different states. I don't know if it's worth the trouble of adding another test category to `compiletest`, but I'd be happy to do so.
Fixes#32754Fixes#34957
There were various places that we are invoking `drain_fulfillment_cx`
with a "result" of `()`. This is kind of pointless, since it amounts to
just a call to `select_all_or_error` along with some extra overhead.
Bonus format for E0194
Bonus fix for #35280. Part of #35233. Fixes#36057. Adding expanded notes/context for what trait a parameter shadows as part of E0194 error messages.
Errors for E0194 now look like this:
```
$> ./build/x86_64-apple-darwin/stage1/bin/rustc src/test/compile-fail/E0194.rs
error[E0194]: type parameter `T` shadows another type parameter of the same name
--> src/test/compile-fail/E0194.rs:13:26
|
11 | trait Foo<T> { //~ NOTE first `T` declared here
| - first `T` declared here
12 | fn do_something(&self) -> T;
13 | fn do_something_else<T: Clone>(&self, bar: T);
| ^ shadows another type parameter
error: aborting due to previous error
```
r? @jonathandturner
Add test for #14875
You can check this out in the playground https://is.gd/oVKC2T . It will fail on stable, but pass on nightly as @nagisa suggested on the issue.
Fixes#14875
add evocative examples for `BitOr` and `BitXor`
These are exactly equivalent to PR #35809, with one caveat: I do not believe there is a non-bitwise binary XOR operator in Rust, so here it's expressed as `(a || b) && !(a && b)`.
Alternative decompositions are `(a && !b) || (!a && b)` and `(a || b) && (!a || !b)`. Let me know if you think one of those would be clearer.
r? @GuillaumeGomez
accumulate vector and assert for RangeFrom and RangeInclusive examples
PR #35695 for `Range` was merged, so it seems that this side-effect-free style is preferred for Range* examples. This PR performs the same translation for `RangeFrom` and `RangeInclusive`. It also removes what looks to be an erroneously commented line for `#![feature(step_by)]`, and an unnecessary primitive-type annotation in `0u8..`.
gdb: Fix pretty-printing special-cased Rust types
gdb trunk now reports fully qualified type names, just like lldb. Move lldb code for extracting unqualified names to shared file.
For current releases of gdb, `extract_type_name` should just be a no-op.
Fixes#35155
Previously we didn't normalize the function signatures used for
closures. This didn't cause a problem in most cases, but caused an ICE
in during MIR type checking.
Fixes#36139
Use monotonic time in condition variables.
Configure condition variables to use monotonic time using
pthread_condattr_setclock on systems where this is possible.
This fixes the issue when thread waiting on condition variable is
woken up too late when system time is moved backwards.
These are exactly equivalent to PR #35809, with one caveat: I do not believe there is a non-bitwise binary "xor" operator in Rust, so here it's expressed as (a || b) && !(a && b).
r? @GuillaumeGomez
improved documentation a la PR #35993
Update E0194 to new error format
Fixes#35280 to update E0194 to support new error message format. Part of #35233.
A separate Github issue #36057 tracks the bonus portion of the original ticket.
r? @jonathandturner
improve `BitAnd` trait documentation
This pull request is based on the discussion in PR #35927.
Add a module-level note that `&&` and `||` are short-circuiting operators and not overloadable.
Add a simple `Scalar` example that lifts the `&` operator to a trivial struct tuple.
Make `BooleanVector` a struct tuple.
Derive `PartialEq` for `BooleanVector` instead of implementing it.
Adds a `fn main` wrapper so that the example can integrate with Rust Playground.
Updated code sample in chapter on syntax extensions.
The affected API apparently had changed with commit d59accfb06.
---
Further more I had to add
```toml
[lib]
name = "roman_numerals"
crate-type = ["dylib"]
```
to `Cargo.toml` as I otherwise got this compiler error (despite `#![crate_type="dylib"]`):
[E0457]: plugin `roman_numerals` only found in rlib format, but must be available in dylib format
Might be worth adding a note about that?
improve documentation for `Fn*` traits
This PR is not yet a serious attempt at contribution. Rather, I'm opening this for discussion. I can think of a few things we may want to accomplish with the documentation of the `Fn`, `FnMut`, and `FnOnce` traits:
- the relationship between these traits and the closures that implement them
- examples of non-closure implementations
- the relationship between these traits and Rust's ownership semantics
show how iterating over `RangeTo` and `RangeToInclusive` fails
Feedback on PR #35701 seems to be positive, so this does the same thing for `RangeTo` and `RangeToInclusive`.
Doc: explain why Box/Rc/Arc methods do not take self
This can be confusing for newcomers, especially due to the argument name `this` that is used for Rc and Arc.
Batch up libsyntax breaking changes
Batch of the following syntax-[breaking-change] changes:
- #35591: Add a field `span: Span` to `ast::Generics`.
- #35618: Remove variant `Mod` of `ast::PathListItemKind` and refactor the remaining variant `ast::PathListKind::Ident` to a struct `ast::PathListKind_`.
- #35480: Change uses of `Constness` in the AST to `Spanned<Constness>`.
- c.f. `MethodSig`, `ItemKind`
- #35728: Refactor `cx.pat_enum()` into `cx.pat_tuple_struct()` and `cx.pat_path()`.
- #35850: Generalize the elements of lists in attributes from `MetaItem` to a new type `NestedMetaItem` that can represent a `MetaItem` or a literal.
- #35917: Remove traits `AttrMetaMethods`, `AttributeMethods`, and `AttrNestedMetaItemMethods`.
- Besides removing imports of these traits, this won't cause fallout.
- Add a variant `Union` to `ItemKind` to future proof for `union` (c.f. #36016).
- Remove inherent methods `attrs` and `fold_attrs` of `Annotatable`.
- Use methods `attrs` and `map_attrs` of `HasAttrs` instead.
r? @Manishearth
