Enable mutable noalias for LLVM >= 12
Enable mutable noalias by default on LLVM 12, as previously known miscompiles have been resolved. Now it's time to find the next one ;)
* The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior.
* The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision.
* `noalias` is not emitted for types that are `!Unpin`, as a heuristic for self-referential structures (see #54878 and #63818).
This saves us both the Freeze/Unpin queries, and avoids placing
noalias attributes, which have a compile-time impact on LLVM
even in optnone builds (due to always_inline functions).
This allows the optimizer to turn certain iterator pipelines such as
```rust
let vec = vec![0usize; 100];
vec.into_iter().map(|e| e as isize).collect::<Vec<_>>()
```
into a noop.
The optimization only applies when iterator sources are `T: Copy`
since `impl TrustedRandomAccess for IntoIter<T>`.
No such requirement applies to the output type (`Iterator::Item`).
Such structures may contain self-references, in which case the
same location may be accessible through a pointer that is not
based-on the noalias pointer.
This is still grey area as far as language semantics are concerned,
but checking for !Unpin as an indicator for self-referential
sturctures seems like a good approach for the meantime.
The frontend shouldn't be deciding whether or not to use mutable
noalias attributes, as this is a pure LLVM concern. Only provide
the necessary information and do the actual decision in
codegen_llvm.
When bumping the bootstrap version, the name of the generated LLVM
shared object file is changed, even though it's the same contents as
before. If bootstrap tries to use an older version, it will get linking
errors:
```
Building rustdoc for stage1 (x86_64-unknown-linux-gnu)
Compiling rustdoc-tool v0.0.0 (/home/joshua/rustc/src/tools/rustdoc)
error: linking with `cc` failed: exit code: 1
|
= note: "cc" "-Wl,--as-needed" ... lots of args ...
= note: /usr/bin/ld: cannot find -lLLVM-12-rust-1.53.0-nightly
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: could not compile `rustdoc-tool`
```
Perform 'deep recollection' in test helper macros
Currently, the print helper macro performs 'recollection' by doing
`token_stream.into_iter().collect()`. However, this will not affect
nonterminals that occur nested inside delimited groups, since the
wrapping delimited group will be left untouched.
This commit adds 'deep recollection', which recursively recollects every
delimited group in the token stream. As with normal recollection, we
only print out something if deep recollection results in a different
stringified token stream.
This is useful for catching bugs where we update the AST of a
nonterminal (which affects pretty-printing), but do not update the
attatched `TokenStream`
Currently, the print helper macro performs 'recollection' by doing
`token_stream.into_iter().collect()`. However, this will not affect
nonterminals that occur nested inside delimited groups, since the
wrapping delimited group will be left untouched.
This commit adds 'deep recollection', which recursively recollects every
delimited group in the token stream. As with normal recollection, we
only print out something if deep recollection results in a different
stringified token stream.
This is useful for catching bugs where we update the AST of a
nonterminal (which affects pretty-printing), but do not update the
attatched `TokenStream`
Extend `proc_macro_back_compat` lint to `js-sys`
With this PR, we now lint for all cases where we perform some kind of
proc-macro back-compat hack.
The `js-sys` had an internal fix made to properly handle
`None`-delimited groups, so we need to manually check the version in the
filename. As a result, we no longer apply the back-compat hack to cases
where the version number is missing file the file path. This should not
affect any users of the `crates.io` crate.
const_evaluatable_checked: Stop eagerly erroring in `is_const_evaluatable`
Fixes#82279
We don't want to be emitting errors inside of is_const_evaluatable because we may call this during selection where it should be able to fail silently
There were two errors being emitted in `is_const_evaluatable`. The one causing the compile error in #82279 was inside the match arm for `FailureKind::MentionsParam` but I moved the other error being emitted too since it made things cleaner imo
The `NotConstEvaluatable` enum \*should\* have a fourth variant for when we fail to evaluate a concrete const, e.g. `0 - 1` but that cant happen until #81339
cc `@oli-obk` `@lcnr`
r? `@nikomatsakis`
* Use Markdown list syntax and unindent a bit to prevent Markdown
interpreting the nested lists as code blocks
* A few more small typographical cleanups
Revert performance-sensitive change in #82436
This change was done in #82436, as an "optimization". Unfortunately I
missed that this code is not always executed, because of the "continue"
in the conditional above it.
This commit should solve the perf regressions introduced by #82436 as I
think there isn't anything else that could affect runtime performance in
that PR. The `Pick` type grows only one word, which I doubt can cause up
to 8.8% increase in RSS in some of the benchmarks.
---
Could someone with the rights start a perf job please?
