The initial purpose is to workaround the LLVM bug
https://llvm.org/bugs/show_bug.cgi?id=26554 for OpenBSD.
By default, the `cpu' is defined to `generic`. But with a 64bit
processor, the optimization for `generic` will use invalid asm code as
NOP (the generated code for NOP isn't a NOP).
According to #20777, "x86-64" is the right thing to do for x86_64
builds.
Closes: #31363
This commit rebases our LLVM submodule on the most recent tip of the
`release_38` branch of LLVM. There's been a few fixes and this notably fixes the
assertion error in #31702.
Closes#31702
This commit rebases our LLVM submodule on the most recent tip of the
`release_38` branch of LLVM. There's been a few fixes and this notably fixes the
assertion error in #31702.
this improves typeck performance by 5% (LLVM times are still huge).
Basically fixes#25916 (still O(n^2), but the example takes <1s to
compile).
r? @nikomatsakis
This PR disallows non-inline modules without path annotations that are either in a block or in an inline module whose containing file is not a directory owner (fixes#29765).
This is a [breaking-change].
r? @nikomatsakis
This commit implements documentation generation of the nomicon, the book, the
style guide, and the standalone docs. New steps were added for each one as well
as appropriate makefile targets for each one as well.
The issue was that the const evaluator was returning an error because
the feature flag const_indexing wasn't turned on. The error was then
reported as a bug.
Fixes#29914
Thanks for catching this @tamird. Here's a quick fix. I didn't pick "let the linker link dead code" or "link dead code" because it would add no extra information to the flag name. Here's a another proposal.
r? @alexcrichton
Because we no longer use `GetFileAttributesExW` FileAttr is never created directly from `WIN32_FILE_ATTRIBUTE_DATA` anymore. So we should no longer store FileAttr's attributes in that c struct.
r? @alexcrichton
Is this what you had in mind?
use CXX value found at configure time inside run-make tests.
it permits OpenBSD to pass llvm-module-pass test (which use CXX
variable).
r? @alexcrichton
This follows the pattern already used for stat functions from #31551. Now
`ftruncate`, `lseek`, and `readdir_r` use their explicit 64-bit variants for
LFS support, using wider `off_t` and `dirent` types. This also updates to
`open64`, which uses no different types but implies the `O_LARGEFILE` flag.
Non-Linux platforms just map their normal functions to the 64-bit names.
r? @alexcrichton
This enables `*` in all type positions in doc searches, which I often
want in order to find functions that create or convert specific
types (e.g. `* -> vec`) but I don't actually know what kinds of input
they expect.
I actually started working on this because of #31598, but I've wanted it
several times when exploring new crates.
The first time I read the docs for `insert()`, I thought it was saying
it didn't update existing *values*, and I was confused. Reword the docs
to make it clear that `insert()` does update values.
Previously the docs suggested that '❤️' doesn't fit in a char because
it's 6 bytes. But that's misleading. 'a̚' also doesn't fit in a char,
even though it's only 3 bytes. The important thing is the number of code
points, not the number of bytes. Clarify the primitive char docs around
this.
This enables `*` in all type positions in doc searches, which I often
want in order to find functions that create or convert specific
types (e.g. `* -> vec`) but I don't actually know what kinds of input
they expect.
I actually started working on this because of #31598, but I've wanted it
several times when exploring new crates.
This allows obtaining a textual MIR dump for individual items or all items in the crate.
I haven't added any tests since ~~I'm too lazy~~ this is an unstable debugging option, but I'll add one if required.
MIR for a single function can now be dumped using `rustc -Zunstable-options --unpretty mir=my_function` and no longer requires the use of in-source `#[rustc_mir]` attributes.
Blocks rust-lang/rust-playpen#154 (if MIR dump support from the playpen is even wanted).
Example output:
```rust
fn main() {
let x = Some(0);
x.unwrap_or_else(|| 1);
}
```
```
MIR for expr || 1 (id=16)
fn(arg0: [closure@test.rs:3:22: 3:26]) -> i32 {
let mut tmp0: ();
bb0: {
return = const 1;
goto -> bb1;
}
bb1: {
return;
}
}
MIR for fn main::main (id=4)
fn() -> () {
let var0: core::option::Option<i32>; // x
let mut tmp0: ();
let mut tmp1: i32;
let mut tmp2: core::option::Option<i32>;
let mut tmp3: [closure@test.rs:3:22: 3:26];
bb0: {
var0 = core::option::Option::Some(const 0);
tmp2 = var0;
tmp3 = [closure@test.rs:3:22: 3:26];
tmp1 = core::option::Option<T>::unwrap_or_else(tmp2, tmp3) -> bb2;
}
bb1: {
return;
}
bb2: {
drop(tmp1) -> bb3;
}
bb3: {
return = ();
goto -> bb1;
}
}
```
In other words, enforce what was documented in #30626 (and also stop blaming it on LLVM, we have at least one Python script of our own).
Also, there is no Python later than 2.7 and there never will be.
Because we no longer use `GetFileAttributesExW` FileAttr is never created
directly from `WIN32_FILE_ATTRIBUTE_DATA` anymore.
So we should no longer store FileAttr's attributes in that c struct.
