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.
Needs a correct review because I'm not too confident with how this works.
All tests related to the C ABI are now passing.
References:
- dbe68fecd0/lib/CodeGen/TargetInfo.cpp (L479-L489)
- dbe68fecd0/lib/CodeGen/TargetInfo.cpp (L466-L477)
The `classifyArgumentType` function has two different paths depending on `RAA == CGCXXABI::RAA_DirectInMemory`, but I don't really know what's the corresponding option in Rust.
cc @brson @eddyb
This PR fixes two unrelated diagnostics bugs in resolve.
First, it reports privacy errors for an import only after the import resolution is determined, fixing #31402.
Second, it expands the per-module map from block ids to anonymous modules so that it also maps module declarations ids to modules, and it uses this map to in `with_scope` to fix#31644.
r? @nrc
This is because the tool compiler passes the name of the tool
as a command line `--cfg`. The improved session config parser
is stricter and no longer permits invalid meta items (such as
"error-index-generator").
Some tests just add the extra errors, others I fix by doing some simple error recovery. I've tried to avoid doing too much in the hope of doing something more principled later.
In general error messages are getting worse at this stage, but I think in the long run they will get better.
Now that we properly only link in jemalloc when building executables, we have
far less to worry about in terms of polluting the global namespace with the
`free` and `malloc` symbols on Linux. This commit will primarily allow LLVM to
use jemalloc so the compiler will only be using one allocator overall.
Locally this took compile time for libsyntax from 95 seconds to 89 (a 6%
improvement).
Back in 9bc8e6d14 the linking of rlibs changed to using the `link_whole_rlib`
function. This change, however was only intended to affect dylibs, not
executables. For executables we don't actually want to link entire rlibs because
we want the linker to strip out as much as possible.
This commit adds a conditional to this logic to only link entire rlibs if we're
creating a dylib, and otherwise an executable just links an rlib as usual. A
test is included which will fail to link if this behavior is reverted.
Right now the primary hashing algorithm of the compiler isn't actually inlined
across crates, meaning that it may be missing out on some crucial optimizations
in a few places (perhaps unrolling smaller loops, etc).
This commit made the hashing function disappear from a profiled version of the
compiler, but that's likely because it was just inlined elsewhere. When
compiling winapi, however, this decreased compile time from 18.3 to 17.8 seconds
(a 3% improvement).
