Here is my attempt to resolve issue #28822, @Manishearth.
Please let me know if it's fine. And if not, what should I do instead?
This issue felt like quite a good start for some rust contributions. It allows me to get used to the workflow and codebase of rust in an easy-to-swallow manner. Are there any other issues you would recommend me to look at? :) Would love to do some more stuff!
For enum variants, the default alignment for a specific variant might be
lower than the alignment of the enum type itself. In such cases we, for
example, generate memcpy calls with an alignment that's higher than the
alignment of the constant we copy from.
To avoid that, we need to explicitly set the required alignment on
constants.
Fixes#28912.
Previously, `/**/` was incorrectly regarded as a doc comment because it starts with `/**` and ends with `*/`. However, this caused an ICE because some code assumed that the length of a doc comment is at least 5. This commit adds an additional check to `is_block_doc_comment` that tests the length of the input.
Fixes#28844.
For enum variants, the default alignment for a specific variant might be
lower than the alignment of the enum type itself. In such cases we, for
example, generate memcpy calls with an alignment that's higher than the
alignment of the constant we copy from.
To avoid that, we need to explicitly set the required alignment on
constants.
Fixes#28912.
Previously, `/**/` was incorrectly regarded as a doc comment because it
starts with `/**` and ends with `*/`. However, this caused an ICE
because some code assumed that the length of a doc comment is at least
5. This commit adds an additional check to `is_block_doc_comment` that
tests the length of the input.
Fixes#28844.
Major revision to the dropck_legal_cycles test.
1. Added big comment block explaining the test framework.
2. Added tests exericising Rc and Arc. This was inspired by a comment
from eefriedman on PR #28861.
3. Made the cycle-detection not issue false-positives on acyclic dags.
Doing this efficiently required revising the framework; instead of
visiting all children (i.e. doing a traversal), now each test is
responsible for supplying the path that will act as a witness to
the cycle.
Luckily for me, all of the pre-existing tests worked with a trivial
path built from "always tke your first left", but new tests I added
did require other input paths (i.e., "first turn right, then left".
(The path representation is a bit-string and its branches are
n-ary, not word phrases and binary branches as you might think
from the outline above.)
cc PR #27185
1. Added big comment block explaining the test framework.
2. Added tests exericising Rc and Arc. This was inspired by a comment
from eefriedman on PR #28861.
3. Made the cycle-detection not issue false-positives on acyclic dags.
Doing this efficiently required revising the framework; instead of
visiting all children (i.e. doing a traversal), now each test is
responsible for supplying the path that will act as a witness to
the cycle.
Luckily for me, all of the pre-existing tests worked with a trivial
path built from "always tke your first left", but new tests I added
did require other input paths (i.e., "first turn right, then left".
(The path representation is a bit-string and its branches are
n-ary, not word phrases and binary branches as you might think
from the outline above.)
This new version takes inspiration from the C implementation of the benchmark, but instead of explicitly using SIMD operations which can't be done on stable, it instead arranges everything the same way and leaves the actual vectorization up to LLVM.
In addition to the ~20% speed gains (see below), this PR also adds some general niceties which showcase the language a little bit: a `Vec3` type to cut down on `(x, y, z)` repetition, using `while let` instead of `loop-if-break`, iterator adapters instead of for loops etc.
Here are the times in seconds of 10 runs each on my workstation:
```
before: 6.254, 6.260, 6.263, 6.264, 6.265, 6.267, 6.334, 6.341, 6.441, 6.509
before-min: 6.254
before-median: 6.266
before-max: 6.509
after: 4.823, 4.824, 4.826, 4.827, 4.837, 4.839, 4.881, 4.959, 4.990, 5.377
after-min: 4.823
after-median: 4.838
after-max: 5.377
gcc: 4.674, 4.676, 4.680, 4.682, 4.695, 4.696, 4.701, 4.708, 4.794, 5.297
gcc-min: 4.674
gcc-median: 4.696
gcc-max: 5.297
```
On my i7 laptop the speed up is less impressive, from ~5.4s to ~4.7s, but still significant. On my Vultr VPS the numbers look closer to the workstation results. Surprisingly my laptop beats both office workstation and VPS...
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`.
(It is not *exactly* the text from the RFC, but the only thing it adds
is a call to a no-op function that is just an attempt to make it clear
where the potential for impl specialization comes from.)
One just checks that we are feature-gating the UGEH attribute (as
usual for attributes associated with unstable features).
The other is adapted from the RFC 1238 text, except that it has been
extended somewhat to actually *illustrate* the scenario that we are
trying to prevent, namely observing the state of data, from safe code,
after the destructor for that data has been executed.
Illustrates cases that worked before and must continue to work, and a
case that shows how to use the `unsafe_destructor_blind_to_params`
attribute (aka "the UGEH attribute") to work around
cannot-assume-parametricity.
I needed it in `RawVec`, `Vec`, and `TypedArena` for `rustc` to
bootstrap; but of course that alone was not sufficient for `make
check`.
Later I added `unsafe_destructor_blind_to_params` to collections, in
particular `LinkedList` and `RawTable` (the backing representation for
`HashMap` and `HashSet`), to get the regression tests exercising
cyclic structure from PR #27185 building.
----
Note that the feature is `dropck_parametricity` (which is not the same
as the attribute's name). We will almost certainly vary our strategy
here in the future, so it makes some sense to have a not-as-ugly name
for the feature gate. (The attribute name was deliberately selected to
be ugly looking.)
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.
