Zero first byte of CString on drop
Hi! This is one more attempt to ameliorate `CString::new("...").unwrap().as_ptr()` problem (related RFC: https://github.com/rust-lang/rfcs/pull/1642).
One of the biggest problems with this code is that it may actually work in practice, so the idea of this PR is to proactively break such invalid code.
Looks like writing a `null` byte at the start of the CString should do the trick, and I think is an affordable cost: zeroing a single byte in `Drop` should be cheap enough compared to actual memory deallocation which would follow.
I would actually prefer to do something like
```Rust
impl Drop for CString {
fn drop(&mut self) {
let pattern = b"CTHULHU FHTAGN ";
let bytes = self.inner[..self.inner.len() - 1];
for (d, s) in bytes.iter_mut().zip(pattern.iter().cycle()) {
*d = *s;
}
}
}
```
because Cthulhu error should be much easier to google, but unfortunately this would be too expensive in release builds, and we can't implement things `cfg(debug_assertions)` conditionally in stdlib.
Not sure if the whole idea or my implementation (I've used ~~`transmute`~~ `mem::unitialized` to workaround move out of Drop thing) makes sense :)
Remove unnecessary `cmp::min` from BufWriter::write
The first branch of the if statement already checks if `buf.len() >= self.buf.capacity()`, which makes the `cmp::min(buf.len(), self.buf.capacity())` redundant: the result will always be `buf.len()`. Therefore, we can pass the `buf` slice directly into `Write::write`.
Update E0297 to new error format
Fixes#35521.
Part of #35233.
I didn't attempt the bonus of narrowing the span to focus on the "for `<pattern>`" piece (it's my first time contributing), but I'm happy to do so given some hints.
r? @jonathandturner
fix a few errant `Krate` edges
Exploring the effect of small changes on `syntex` reuse, I discovered the following sources of unnecessary edges from `Krate`
r? @michaelwoerister
Improve char_lit's readability and speed
This is my first contribution to rustc. Please let me know if I've done anything wrong. (I ran `make tidy` before making the pull request.)
This reduces the time taken to run
`rustc -Zparse-only rustc-benchmarks/issue-32278-big-array-of-strings`
from 0.18s to 0.15s on my machine, and reduces the number of
instructions (as measured by Cachegrind) from 1.34B to 1.01B.
With the change applied, the time to fully compile that benchmark is
1.96s, so this is a 1.5% improvement.
Work around pointer aliasing issue in Vec::extend_from_slice, extend_with_element
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).
Fixes#32155Fixes#33518Closes#17844
Point macros 1.1 errors to the input item
Moved from https://github.com/alexcrichton/rust/pull/6 to continue discussion. Fixes#36218.
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
```
Add s390x support
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>
The first branch of the if statement already checks if `buf.len() >= self.buf.capacity()`, which makes the `cmp::min(buf.len(), self.buf.capacity())` redundant: the result will always be `buf.len()`. Therefore, we can pass the `buf` slice directly into `Write::write`.
Update the wording for E0063. This will truncate the fields to 3.
Instead of listing every field it will now show missing `a`, `z`, `b`, and 1 other field
This is for #35218 as part of #35233
r? @jonathandturner
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>
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).
