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.
Part of #28710
Landing pads during stage0 are now enabled by defaullt. Since this has its downsides and upsides either way, I made it possible to change the option through configure.
I had to fix a few things. Notable changes:
1. I removed the MIR support for constants, instead falling back to the existing `ConstVal`. I still think we ought to reform how we handle constants, but it's not clear to me that the approach I was taking is correct, and anyway I think we ought to do it separately.
2. I adjusted how we handle bindings in matches: we now *declare* all the bindings up front, rather than doing it as we encounter them. This is not only simpler, since we don't have to check if a binding has already been declared, it avoids ICEs if any of the arms turn out to be unreachable.
3. I do MIR construction *after* `check_match`, because it detects various broken cases. I'd like for `check_match` to be subsumed by MIR construction, but we can do that as a separate PR (if indeed it makes sense).
I did a crater run and found no regressions in the wild: https://gist.github.com/nikomatsakis/0038f90e10c8ad00f2f8
and track which arms are reached (though in fact we don't make use of
this right now -- we might later if we absorb the checking of patterns
into MIR, as I would like)
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 output of rustdoc includes resources licensed under the SIL Open
Font License, the MIT license, and the Apache License 2.0. All of these
licenses permit redistribution provided that the license text is also
redistributed. Previously this was not the case, making rustdoc output
unsuitable for distribution by default. This resolves that problem by
including the license texts in rustdoc output.
See also: https://users.rust-lang.org/t/licensing-rustdoc-output/2880
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.
"Rust Inside Other Languages" in the Rust book includes a library example. The reference specifies printing "done!" when the code finishes running, and the language examples (Ruby, Python, JS) all do this in their code.
However, the Rust library example code *also* does this, so that the examples as written would output "done!" twice.
This commit removes the "done!" from the Rust example code to tidy up the output to match expectations.
The "Rust Inside Other Languages" page includes a library example. The
reference specifies printing "done!" when the code finishes running, and
the language examples (Ruby, Python, JS) all do this in their code.
However, the Rust library example code *also* does this, so that the
examples as written would output "done!" twice.
This removes the "done!" from the Rust example code to clarify the docs.
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.
libcore.rlib reduced from 19121 kiB to 15934 kiB - 20% win.
The librustc encoded AST is 9013500 bytes long - for the record, librustc consists of about 2254126 characters. Might be worth looking at.
r? @eddyb
