| Age | Commit message (Collapse) | Author | Lines |
|---|
|
We were missing an Instance::resolve_for_fn_ptr in resolve_for_vtable.
Closes #74764.
|
|
|
|
This reverts commit 174b58287c66a6ad3eaa1897279d769611919960.
|
|
Thus we avoid propagation of a local the moment we encounter references to it.
|
|
|
|
|
|
This commit intends to fix an accidental regression from #70846. The
goal of #70846 was to build compiler-builtins with a maximal number of
CGUs to ensure that each module in the source corresponds to an object
file. This high degree of control for compiler-builtins is desirable to
ensure that there's at most one exported symbol per CGU, ideally
enabling compiler-builtins to not conflict with the system libgcc as
often.
In #70846, however, only part of the compiler understands that
compiler-builtins is built with many CGUs. The rest of the compiler
thinks it's building with `sess.codegen_units()`. Notably the
calculation of `sess.lto()` consults `sess.codegen_units()`, which when
there's only one CGU it disables ThinLTO. This means that
compiler-builtins is built without ThinLTO, which is quite harmful to
performance! This is the root of the cause from #73135 where intrinsics
were found to not be inlining trivial functions.
The fix applied in this commit is to remove the special-casing of
compiler-builtins in the compiler. Instead the build system is now
responsible for special-casing compiler-builtins. It doesn't know
exactly how many CGUs will be needed but it passes a large number that
is assumed to be much greater than the number of source-level modules
needed. After reading the various locations in the compiler source, this
seemed like the best solution rather than adding more and more special
casing in the compiler for compiler-builtins.
Closes #73135
|
|
Fix #59326.
|
|
|
|
|
|
Fix a crash when searching for an alias contained in the currently selected filter crate.
Also remove alias search results for crates that should be filtered out.
The test suite needed to be fixed to actually take into account the crate filtering and check that there are no results when none are expected.
|
|
|
|
In particular matching on complex types such as strings will cause
deep recursion to happen.
Fixes #72933
|
|
|
|
|
|
|
|
Fixes #73050
|
|
This pass is buggy so I'm disabling it to fix a stable-to-beta
regression.
Related to #73223
|
|
|
|
|
|
This reverts commit 611988551fba1bcbb33ae2e1e0171cb8d2e70d5a.
|
|
This reverts commit a030c923412b0a0f7b02a585debe7bf60357370d.
|
|
|
|
Co-authored-by: Aaron1011 <aa1ronham@gmail.com>
|
|
ecstatic-morse:remove-requires-storage-analysis, r=tmandry"
This reverts commit 458a3e76294fd859fb037f425404180c91e14767, reversing
changes made to d9417b385145af1cabd0be8a95c65075d2fc30ff.
|
|
test miri-unleash TLS accesses
Finally gets rid of `IS_SUPPORTED_IN_MIRI`. :-)
I also added a test for the new `asm!` while I am at it.
r? @ecstatic-morse Cc @rust-lang/wg-const-eval
|
|
Clarify errors and warnings about the transition to the new asm!
Hopefully addresses the concerns from https://github.com/rust-lang/rust/pull/71007#issuecomment-636412905.
|
|
Add a test for `$:ident` in proc macro input
cc https://github.com/rust-lang/rust/issues/72545#issuecomment-636388019
|
|
Return early to avoid ICE
Fixes #72766
|
|
Co-authored-by: Aaron Hill <aa1ronham@gmail.com>
|
|
|
|
Make TLS accesses explicit in MIR
r? @rust-lang/wg-mir-opt
cc @RalfJung @vakaras for miri thread locals
cc @bjorn3 for cranelift
fixes #70685
|
|
Add descriptions for all queries
This also removes the default description for queries with DefId keys and makes the macro validate that a description is provided.
cc #72730
r? @eddyb
|
|
Avoid setting wrong obligation cause span of associated type mismatch
Removes code that sets wrong obligation cause span of associated type mismatch. See the linked issue for details.
Closes #72806.
|
|
|
|
|
|
Account for trailing comma when suggesting `where` clauses
Fix #72693.
|
|
|
|
|
|
|
|
miri validation: clarify valid values of 'char'
The old text said "expected a valid unicode codepoint", which is not actually correct -- it has to be a scalar value (which is a code point that is not part of a surrogate pair).
|
|
rustc_lexer: Optimize shebang detection slightly
Sorry, I just couldn't resist.
It shouldn't make any difference in practice.
Also, documented a previously unnoticed case with doc comments treated as regular comments during shebang detection.
|
|
awoimbee:give-fn-parenthetical-notation-parentheses, r=estebank
Fix missing parentheses Fn notation error
Fixes #72611
Well, fixes the error output, I think E0658 is the right error to throw in this case so I didn't change that
|
|
Add -Z profile-emit=<path> for Gcov gcda output.
Adds a -Z flag to control the file path that the Gcov gcda output is
written to during runtime. This flag expects a path and filename, e.g.
-Z profile-emit=gcov/out/lib.gcda.
This works similar to GCC/Clang's -fprofile-dir flag which allows
control over the output path for gcda coverage files.
|
|
Allow types (with lifetimes/generics) in impl_lint_pass
cc https://github.com/rust-lang/rust-clippy/pull/5279#discussion_r430790267
This allows to implement `LintPass` for types with lifetimes and/or generics. The only thing, I'm not sure of is the `LintPass::name` function, which now includes the lifetime(s) (which will be `'_` most of the time) in the name returned for the lint pass, if it exists. But I don't think that this should be a problem, since the `LintPass::name` is never used for output for the user (?).
|
|
expand `env!` with def-site context
Similar to #66349.
Fixes rust-lang/rust-clippy#5619.
|
|
Improve inline asm error diagnostics
Previously we were just using the raw LLVM error output (with line, caret, etc) as the diagnostic message, which ends up looking rather out of place with our existing diagnostics.
The new diagnostics properly format the diagnostics and also take advantage of LLVM's per-line `srcloc` attribute to map an error in inline assembly directly to the relevant line of source code.
Incidentally also fixes #71639 by disabling `srcloc` metadata during LTO builds since we don't know what crate it might have come from. We can only resolve `srcloc`s from the currently crate since it indexes into the source map for the current crate.
Fixes #72664
Fixes #71639
r? @petrochenkov
### Old style
```rust
#![feature(llvm_asm)]
fn main() {
unsafe {
let _x: i32;
llvm_asm!(
"mov $0, $1
invalid_instruction $0, $1
mov $0, $1"
: "=&r" (_x)
: "r" (0)
:: "intel"
);
}
}
```
```
error: <inline asm>:3:14: error: invalid instruction mnemonic 'invalid_instruction'
invalid_instruction ecx, eax
^~~~~~~~~~~~~~~~~~~
--> src/main.rs:6:9
|
6 | / llvm_asm!(
7 | | "mov $0, $1
8 | | invalid_instruction $0, $1
9 | | mov $0, $1"
... |
12 | | :: "intel"
13 | | );
| |__________^
```
### New style
```rust
#![feature(asm)]
fn main() {
unsafe {
asm!(
"mov {0}, {1}
invalid_instruction {0}, {1}
mov {0}, {1}",
out(reg) _,
in(reg) 0i64,
);
}
}
```
```
error: invalid instruction mnemonic 'invalid_instruction'
--> test.rs:7:14
|
7 | invalid_instruction {0}, {1}
| ^
|
note: instantiated into assembly here
--> <inline asm>:3:14
|
3 | invalid_instruction rax, rcx
| ^^^^^^^^^^^^^^^^^^^
```
|
|
|
|
|
|
|
