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 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.
Bound sgx target_env with fortanix as target_vendor
This PR adds `target_vendor` check, as discussed in issue [57231](https://github.com/rust-lang/rust/issues/57231)
Signed-off-by: Yu Ding <dingelish@gmail.com>
Improve type mismatch error messages
Closes#56115.
Replace "integral variable" with "integer" and replace "floating-point variable" with "floating-point number" to make the message less confusing.
TODO the book and clippy needs to be changed accordingly later.
r? @varkor
Eliminate Receiver::recv_timeout panic
Fixes#54552.
This panic is because `recv_timeout` uses `Instant::now() + timeout` internally. This possible panic is not mentioned in the documentation for this method.
Very recently we merged (still unstable) support for checked addition (#56490) of `Instant + Duration`, so it's now finally possible to add these together without risking a panic.
Fix inconsistent Clone documentation.
Now, arrays of any size Clone if the element type is Clone. So remove the
the document that uses this as an example.
refs #57123
NLL: User type annotations refactor, associated constant patterns and ref bindings.
Fixes#55511 and Fixes#55401. Contributes to #54943.
This PR performs a large refactoring on user type annotations, checks user type annotations for associated constants in patterns and that user type annotations for `ref` bindings are respected.
r? @nikomatsakis
resolve: Simplify treatment of ambiguity errors
If we have a glob conflict like this
```rust
mod m1 { struct S; }
mod m2 { struct S; }
use m1::*;
use m2::*;
```
we treat it as a special "ambiguity item" that's not an error by itself, but produces an error when actually used.
```rust
use m1::*; // primary
use m2::*; // secondary
=>
ambiguity S(m1::S, m2::S);
```
Ambiguity items were *sometimes* treated as their primary items for error recovery, but pretty irregularly.
After this PR they are always treated as their primary items, except that
- If an ambiguity item is marked as used, then it still produces an error.
- Ambiguity items are still filtered away when exported to other crates (which is also a use in some sense).
privacy: Use common `DefId` visiting infrastructure for all privacy visitors
One repeating pattern in privacy checking is going through a type, visiting all `DefId`s inside it and doing something with them.
This is the case because visibilities and reachabilities are attached to `DefId`s.
Previously various privacy visitors visited types slightly differently using their own methods, with most recently written `TypePrivacyVisitor` being the "gold standard".
This mostly worked okay, but differences could manifest in overly conservative reachability analysis, some errors being reported twice, some private-in-public lints (not errors) being wrongly reported or not reported.
This PR does something that I wanted to do since https://github.com/rust-lang/rust/pull/32674#discussion_r58291608 - factoring out the common visiting logic!
Now all the common logic is contained in `struct DefIdVisitorSkeleton`, with specific privacy visitors deciding only what to do with visited `DefId`s (via `trait DefIdVisitor`).
A bunch of cleanups is also applied in the process.
This area is somewhat tricky due to lots of easily miss-able details, but thankfully it's was well covered by tests in https://github.com/rust-lang/rust/pull/46083 and previous PRs, so I'm relatively sure in the refactoring correctness.
Fixes https://github.com/rust-lang/rust/pull/56837#discussion_r241962239 in particular.
Also this will help with implementing https://github.com/rust-lang/rust/issues/48054.
