bootstrap: Link LLVM as a dylib with ThinLTO (take 2)
When building a distributed compiler on Linux where we use ThinLTO to
create the LLVM shared object this commit switches the compiler to
dynamically linking that LLVM artifact instead of statically linking to
LLVM. The primary goal here is to reduce CI compile times, avoiding two+
ThinLTO builds of all of LLVM. By linking dynamically to LLVM we'll
reuse the one ThinLTO step done by LLVM's build itself.
Lots of discussion about this change can be found [here] and down. A
perf run will show whether this is worth it or not!
[here]: https://github.com/rust-lang/rust/pull/53245#issuecomment-417015334
---
This PR previously landed in https://github.com/rust-lang/rust/pull/56944, caused https://github.com/rust-lang/rust/issues/57111, and was reverted in https://github.com/rust-lang/rust/pull/57116. I've added one more commit here which should fix the breakage that we saw.
Calculate privacy access only via query
Initially converted to query in a9f6babcda and then changed to respect dependencies 8281e883dd.
I did this as an effort to prune `CrateAnalysis` from librustc_save_analysis, with the only thing remaining being the glob map (`name` is unused, existing `crate_name` is exposed in the compiler passes, instead).
Since calculating the glob map is opt-in, it'd be great if we could calculate that on-demand. However, it seems that it'd require converting resolution to queries, which I'm not sure how to do yet.
In an effort to get rid of `CrateAnalysis` altogether, could we try unconditionally calculating the glob_map in the resolver, thus completely removing `CrateAnalysis` struct, and doing a perf run?
r? @nikomatsakis
cc @petrochenkov do you have any idea how/if at all could we querify the resolver? I've stumbled upon a comment that's ~3? years old at the moment, so I'm guessing things might have changed and it actually may be feasible now. fe0c10019d/src/librustc_driver/driver.rs (L589-L593)
librustc_mir: Make qualify_min_const_fn module public
Trying to write a `const_fn` lint for Clippy. @oli-obk suggested
[here][link] to use the `is_min_const_fn` function from the
`qualify_min_const_fn` module. However, the module is currently private
and this commit makes it public.
I lack any historical knowledge of the development of the `const_fn`
feature, so I'm not sure if it was private on purpose or not. fwiw, all
modules are already public except `qualify_min_const_fn`.
r? @oli-obk
[link]: https://github.com/rust-lang/rust-clippy/issues/2440#issuecomment-446109978
rustdoc: force binary filename for compiled doctests
Fixes https://github.com/rust-lang/rust/issues/57317, needed for https://github.com/rust-lang/rust-by-example/issues/1137
Right now, when building a doctest, rustdoc provides the compiler an output directory (a temp dir) but lets the compiler name the executable. If the doctest needs to be executed, it then tries to run a binary named `rust_out` from that directory. For the most part, this works fine. However, if the doctest sets its own crate name, the compiler uses that name for the output binary instead. This causes rustdoc to try to execute a nonexistent binary, causing the test to fail.
This PR changes the paths rustdoc gives to the compiler when building doctests to force the output *filename* instead of just the *directory*.
Improve Box<T> -> Pin<Box<T>> conversion
I found the `From` trait conversion for this very hard to find, having a named function for it is much more discoverable. Also fixes#56256 as I need that in the place I'm using this.
Has a placeholder tracking issue, will file an issue once I get feedback.
`const fn` is no longer coming soon (const keyword docs)
The `const` keyword [documentation](https://doc.rust-lang.org/std/keyword.const.html) mentions that `const fn`s are coming soon, but they have already been added.
VaList::copy should not require a mutable ref
`VaList::copy` does not need to take a mutable reference. The `va_copy`
intrinsic takes a immutable reference.
Fix 'be be' constructs
I noticed a duplicated "be" somewhere in the code. A search for it
manifested a couple more locations with the same problem. This change
removes one of the "be"s.
Rename and fix nolink-with-link-args test
There are three problems with the nolink-with-link-args test:
* The test fails when using MSVC. It's caused by the `linker-flavor=ld` flag which was added in #46291.
* In its comment, this test tests that "link_args are indeed passed when nolink is specified", but the `nolink` attribute has been removed [a long time ago](https://github.com/rust-lang/rust/pull/12826).
* Pattern has a small typo.
At first I was going to completely remove this test, but there is [a closed pull request for that](https://github.com/rust-lang/rust/pull/21090).
So:
* rename the file as suggested in the closed PR
* adjust the comment
* fix typo in the pattern
* add `ignore-msvc`.
r? @alexcrichton
Fix#56806 by using `delay_span_bug` in object safety layout sanity checks
It's possible that `is_object_safe` is called on a trait method that with an invalid receiver type. This caused an ICE in #56806, because `receiver_is_dispatchable` returns `true` for `self: Box<dyn Trait>`, which causes one of the layout sanity checks in object_safety.rs to fail. Replacing `bug!` with `delay_span_bug` solves this.
The fact that `receiver_is_dispatchable` returns `true` here could be considered a bug. It passes the check that the method implements, though: `Box<dyn Trait>` implements `DispatchFromDyn<Box<dyn Trait>>` because `dyn Trait` implements `Unsize<dyn Trait>`. It would be good to hear what @eddyb and @nikomatsakis think.
Note that I only added a test for the case encountered in #56806. I could not come up with a case that triggered an ICE from the other check, `bug!("receiver when Self = dyn Trait should be ScalarPair, found Scalar")`. There is no way, to my knowledge, that you can make `receiver_is_dispatchable` return true but still have a `Scalar` ABI when `Self = dyn Trait`.
One other case I encountered while debugging #56806 was that if you have a type parameter `T` that implements `Deref<Target=Self>` and `DispatchFromDyn<T>`, and use it as a method receiver, it will cause an ICE during `is_object_safe` because `T` has no layout ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=d9b7497b3be0ca8382fa7d9497263214)):
```rust
trait Trait<T: Deref<Target=Self> + DispatchFromDyn<T>> {
fn foo(self: T) -> dyn Trait<T>;
}
```
I don't intend to remove the ICE there because it is a pathological case, especially since there is no way to implement `DispatchFromDyn<T>` for `T` — the checks in typeck/coherence/builtin.rs do not allow that.
fixes#56806
r? @varkor
panic when calling MaybeUninhabited::into_inner on uninhabited type
I do this by adding an internal-only intrinsic `panic_if_uninhabited`. I have no idea what I am doing here, just mindlessly copying code around, so please review carefully!
NLL: Add closure cannot be moved note.
Fixes#57098.
This PR extends existing logic for checking whether a closure that
is `FnOnce` and therefore moves variables that it captures from the
environment has already been invoked when being invoked again.
Now, this logic will also check whether the closure is being moved after
previously being moved or invoked and add an appropriate note.
r? @pnkfelix
Add support for trait-objects without a principal
The hard-error version of #56481 - should be merged after we do something about the `traitobject` crate.
Fixes#33140.
Fixes#57057.
r? @nikomatsakis
Implement the Re-rebalance coherence RFC
This is the first time I touch anything in the compiler so just tell me if I got something wrong.
Big thanks to @sgrif for the pointers where to look for those things.
cc #55437
It's possible that `is_object_safe` is called on a trait that is ill-formed, and we shouldn't ICE unless there are no errors being raised. Using `delay_span_bug` solves this.
fixes#56806
make `panictry!` private to libsyntax
This commit completely removes usage of the `panictry!` macro from
outside libsyntax. The macro causes parse errors to be fatal, so using
it in libsyntax_ext caused parse failures *within* a syntax extension to
be fatal, which is probably not intended.
Furthermore, this commit adds spans to diagnostics emitted by empty
extensions if they were missing, à la #56491.
Trying to write a `const_fn` lint for Clippy. @oli-obk suggested
[here][link] to use the `is_min_const_fn` function from the
`qualify_min_const_fn` module. However, the module is currently private
and this commit makes it public.
I lack any historical knowledge of the development of the `const_fn`
feature, so I'm not sure if it was private on purpose or not. fwiw, all
modules are already public except `qualify_min_const_fn`.
[link]: https://github.com/rust-lang/rust-clippy/issues/2440#issuecomment-446109978
Forbid recursive impl trait
There is no type T, such that `T = [T; 2]`, but impl Trait could sometimes
be to circumvented this.
This patch makes it a hard error for an opaque type to resolve to such a
"type". Before this can be merged it needs
- [x] A better error message - it's good enough for now.
- [x] A crater run (?) to see if this any real-world code
closes#47659
Allow to dispatch fn traits depending on number of parameters
Hello,
By following @eddyb's advise on issue #45510, I managed to have the snippets of code in #45510 and #18952 passing without breaking older diagnostics.
EDIT: the codegen tests breakage I experienced is due to the poor quality of my laptop.
If any kind reviewer has any advice, you are very welcome.
