The LLVM build system is somewhat picky about which Python is used to build it
as it's known to be incompatible with the default `python2` package that ships
with MinGW. This was previously detected for MSVC builds but the logic was left
out for MinGW by accident (now that we've switched to cmake builds for LLVM
everywhere).
This corrects the `./configure` check and also updates the `README.md`
accordingly. Additionally, a number of instructions were updated to work with
the most recent copy of MSYS2.
Closes#34489
std: Fix up stabilization discrepancies
* Remove the deprecated `CharRange` type which was forgotten to be removed
awhile back.
* Stabilize the `os::$platform::raw::pthread_t` type which was intended to be
stabilized as part of #32804
Convert makefiles to build LLVM/compiler-rt with CMake
This is certainly buggy, but I have successfully built on x86_64-unknown-linux-gnu and x86_64-pc-windows-gnu. I haven't built successfully on mac yet, and I've seen mysterious test failures on Linux, but I'm interested in throwing this at the bots to see what they think.
upgrade thread_local! invocation syntax
Allows declaring multiple statics in one macro invocation, and supports attaching attributes to the generated items. In particular, `#![forbid(missing_docs, unused)]` is now tenable on a crate/module containing thread locals.
For an example see [here](https://is.gd/aVFZZF). This change is fully backwards compatible as far as I can tell.
cc @frankmcsherry
* Remove the deprecated `CharRange` type which was forgotten to be removed
awhile back.
* Stabilize the `os::$platform::raw::pthread_t` type which was intended to be
stabilized as part of #32804
Modified E0220 to show error messages for more general cases
This PR extends `E0220`'s description to explain more cases.
Refer to [#34342](https://github.com/rust-lang/rust/pull/34342) for more.
r? @GuillaumeGomez
Fix macro hygiene regression
The regression was caused by #32923, which is currently in beta.
The following is an example of regressed code:
```rust
fn main() {
let x = 0;
macro_rules! foo { () => {
println!("{}", x); // prints `0` on stable and after this PR, prints `1` on beta and nightly
} }
let x = 1;
foo!();
}
```
For code to regress, the following is necessary (but not sufficient):
- There must be a local variable before a macro in a block, and the macro must use the variable.
- There must be a second local variable with the same name after the macro.
- The macro must be invoked in a statement position after the second local variable.
For example, if the `let x = 0;` from the breaking example were commented out, it would (correctly) not compile on beta/nightly. If the semicolon were removed from `foo!();`, it would (correctly) print `0` on beta and nightly.
r? @nrc
rustdoc: Fix a couple of issues with src links to external crates
- src links/redirects to extern fn from another crate had an extra '/'.
- src links to `pub use` of a crate module had an extra '/'.
- src links to renamed reexports from another crate used the new name
for the link but should use the original name.
Fixes: #34274
configure: Remove clang version checks
We no C++ and an incredibly small amount of C code as part of the build, so
there's not really much need for us to strictly check the version of compilers
as we're not really stressing anything. LLVM is a pretty huge chunk of C++ but
it should be the responsibility of LLVM to ensure that it can build with a
particular clang/gcc version, not ours (as this logic changes over time).
These version checks seem to basically just by us a regular stream of PRs every
six weeks or so when a new version is releases, so they're not really buying us
much. As a result, remove them and we can add then back piecemeal perhaps as a
blacklist if we really need to.
Fix overflow error in thread::sleep
Fixes#34330
I added a test to have a more clear error inside the function. Since `time_t` is `i64` and we expect `u64`, maybe we should changed the awaited type?
Add custom message parameter to `assert_eq!`
`assert!` macro accepts a custom message parameter and it's sometimes useful. But `assert_eq!` doesn't have it and users need to use `assert!` instead of `assert_eq!` when they want to output a custom message even if the assertion just compares two values. This pull request will resolve those cases.
Improves organization of driver includes.
Minor reordering of use's in librustc_driver/driver.rs
- puts her::lower::lower_create with it's siblings
- groups link and write of rustc_trans::back
book: Fixed links in book/compiler-plugins.md
Updated the links referring to roman_numerals.rs and lint_plugin_test.rs. Went from src/test/auxiliary/ to src/test/run-pass-fulldeps/auxiliary/.
Remove unzip() SizeHint hack
This was using an invalid iterator so is likely to end with buggy
behaviour.
It also doesn't even benefit many type in std including Vec so removing it
shouldn't cause any problems.
Fixes: #33468
trans: generalize immediate temporaries to all MIR locals.
Added `Mir::local_index` which gives you an unified index for `Arg`, `Var`, `Temp` and `ReturnPointer`.
Also available is `Mir::count_locals` which returns the total number of the above locals.
This simplifies a lot of the code which can treat all of the local lvalues in the same manner.
If we had `-> impl Iterator`, I could have added a bunch of useful `Ty` or `Lvalue` iterators for all locals.
We could of course manually write such iterators as they are needed.
The only place which currently takes advantage of unified locals is trans' alloca elision.
Currently it's not as good as it could be, due to our usage of `llvm.dbg.declare` in debug mode.
But passing some arguments and variables as immediates has some effect on release-mode `libsyntax`:
Old trans:
```
time: 11.500; rss: 710MB translation
time: 0.002; rss: 710MB assert dep graph
time: 0.000; rss: 710MB serialize dep graph
time: 4.410; rss: 628MB llvm function passes [0]
time: 84.485; rss: 633MB llvm module passes [0]
time: 23.898; rss: 634MB codegen passes [0]
time: 0.002; rss: 634MB codegen passes [0]
time: 113.408; rss: 634MB LLVM passes
```
`-Z orbit`, previously:
```
time: 12.588; rss: 723MB translation
time: 0.002; rss: 723MB assert dep graph
time: 0.000; rss: 723MB serialize dep graph
time: 4.597; rss: 642MB llvm function passes [0]
time: 77.347; rss: 646MB llvm module passes [0]
time: 24.703; rss: 648MB codegen passes [0]
time: 0.002; rss: 615MB codegen passes [0]
time: 107.233; rss: 615MB LLVM passes
```
`-Z orbit`, after this PR:
```
time: 13.820; rss: 672MB translation
time: 0.002; rss: 672MB assert dep graph
time: 0.000; rss: 672MB serialize dep graph
time: 3.969; rss: 591MB llvm function passes [0]
time: 72.294; rss: 595MB llvm module passes [0]
time: 24.610; rss: 597MB codegen passes [0]
time: 0.002; rss: 597MB codegen passes [0]
time: 101.439; rss: 597MB LLVM passes
```
Implementation of #34168
r? @brson
cc @alexcrichton
cc @steveklabnik
cc @jonathandturner
I only updated `librustc_privacy/diagnostics.rs`, and I already found a case where the code doesn't throw the expected error code (E0448).
Fixes#34168.
- src links/redirects to extern fn from another crate had an extra '/'.
- src links to `pub use` of a crate module had an extra '/'.
- src links to renamed reexports from another crate used the new name
for the link but should use the original name.
We no C++ and an incredibly small amount of C code as part of the build, so
there's not really much need for us to strictly check the version of compilers
as we're not really stressing anything. LLVM is a pretty huge chunk of C++ but
it should be the responsibility of LLVM to ensure that it can build with a
particular clang/gcc version, not ours (as this logic changes over time).
These version checks seem to basically just by us a regular stream of PRs every
six weeks or so when a new version is releases, so they're not really buying us
much. As a result, remove them and we can add then back piecemeal perhaps as a
blacklist if we really need to.
