Call poly_project_and_unify_type on types that contain inference types
Commit f57247c48c (Ensure that Rusdoc discovers all necessary auto
trait bounds) added a check to ensure that we only attempt to unify a
projection predicatre with inference variables. However, the check it
added was too strict - instead of checking that a type *contains* an
inference variable (e.g. '&_', 'MyType<_>'), it required the type to
*be* an inference variable (i.e. only '_' would match).
This commit relaxes the check to use 'ty.has_infer_types', ensuring that
we perform unification wherever possible.
Fixes#56822
- Point at opening mismatched formatting brace
- Account for differences between raw and regular strings
- Account for differences between the code snippet and `InternedString`
- Add more tests
make non_camel_case_types an early lint
This allows us to catch these kinds of style violations much earlier, as evidenced by the large number of tests that had to be updated for this change.
Enable emission of alignment attrs for pointer params
Instead disable creation of assumptions during inlining using an LLVM opt flag. For non-inlined functions, this gives us alignment information, while not inserting any assumes that kill other optimizations.
The `-Z arg-align-attributes` option which previously controlled this behavior is removed.
Fixes#54982.
r? @nagisa
cc @eddyb who added the current behavior, and @scottmcm, who added the `-Z arg-align-attributes` flag.
bootstrap: Link LLVM as a dylib with ThinLTO
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
Fix alignment for array indexing
We need to reduce the alignment with the used offset. If the offset isn't known, use the element size, as this will yield the minimum possible alignment.
This handles both direct array indexing, and array repeat expressions.
Fixes#56927.
r? @nagisa
Pin stabilization
This implements the changes suggested in https://github.com/rust-lang/rust/issues/55766#issue-378417538 and stabilizes the `pin` feature. @alexcrichton also listed several "blockers" in that issue, but then in [this comment](https://github.com/rust-lang/rust/issues/55766#issuecomment-445074980) mentioned that they're more "TODO items":
> In that vein I think it's fine for a stabilization PR to be posted at any time now with FCP lapsed for a week or so now. The final points about self/pin/pinned can be briefly discussed there (if even necessary, they could be left as the proposal above).
Let's settle these last bits here and get this thing stabilized! :)
r? @alexcrichton
cc @withoutboats
enum type instead of variant suggestion unification
Fixes#56028.
Weirdly, we were deciding between a help note and a structured suggestion based on whether the import candidate span was a dummy—but we weren't using that span in any case! The dummy-ness of the span (which appears to be a matter of this-crate vs. other-crate definition) isn't the right criterion by which we should decide whether it's germane to mention that "there is an enum variant"; instead, let's use the someness of `def` (which is used as the `has_unexpected_resolution` argument to `error_code`).
Since `import_candidate_to_paths` has no other callers, we are free to stop returning the span and rename the function. By using `span_suggestions_`, we leverage the max-suggestions output limit already built in to the emitter, thus resolving #56028.
In the matter of message wording, "you can" is redundant (and perhaps too informal); prefer the imperative.
In a second commit, we do some unprincipled special-casing to correct and beautify suggestions for `Option` and `Result` (where the existing code was being confused by their being reexported in the prelude).
r? @davidtwco
Weirdly, we were deciding between a help note and a structured
suggestion based on whether the import candidate span was a dummy—but
we weren't using that span in any case! The dummy-ness of the span
(which appears to be a matter of this-crate vs. other-crate
definition) isn't the right criterion by which we should decide
whether it's germane to mention that "there is an enum variant";
instead, let's use the someness of `def` (which is used as the
`has_unexpected_resolution` argument to `error_code`).
Since `import_candidate_to_paths` has no other callers, we are free to
stop returning the span and rename the function. By using
`span_suggestions_`, we leverage the max-suggestions output limit
already built in to the emitter, thus resolving #56028.
In the matter of message wording, "you can" is redundant (and perhaps
too informal); prefer the imperative.
Update migrate warning wording.
This PR modifies the wording of the warning for backwards-incompatible changes in migrate mode. The warning messages are changed to be lowercase and not include line-breaks in order to be consistent with other compiler diagnostics.
rustdoc: add new CLI flag to load static files from a different location
This PR adds a new CLI flag to rustdoc, `--static-root-path`, which controls how rustdoc links pages to the CSS/JS/font static files bundled with the output. By default, these files are linked with a series of `../` which is calculated per-page to link it to the documentation root - i.e. a relative link to the directory given by `-o`. This is causing problems for docs.rs, because even though docs.rs has saved one copy of these files and is dispatching them dynamically, browsers have no way of knowing that these are the same files and can cache them. This can allow it to link these files as, for example, `/rustdoc.css` instead of `../../rustdoc.css`, creating a single location that the files are loaded from.
I made sure to only change links for the *static* files, those that don't change between crates. Files like the search index, aliases, the source files listing, etc, are still linked with relative links.
r? @GuillaumeGomez
cc @onur
Ignore ui/target-feature-gate on sparc, sparc64, powerpc, powerpc64 and powerpc64le
The test ui/target-feature-gate is not applicable on sparc, sparc64, powerpc, powerpc64 and powerpc64le and consequently fails there. So just ignore it on these targets.
static eval: Do not ICE on layout size overflow
Layout size overflow and typeck eval errors are reported. Trigger a bug
only when the eval error is strictly labeled as TooGeneric.
Fixes: #56762
This commit modifies the wording of the warning for
backwards-incompatible changes in migrate mode. The warning messages are
changed to be lowercase and not include line-breaks in order to be
consistent with other compiler diagnostics.
stop treating trait objects from #[fundamental] traits as fundamental
This is a [breaking-change] to code that exploits this functionality (which should be limited to code using `#![feature(fundamental)]`.
Fixes#56503.
r? @nikomatsakis
Stabilize `Rc`, `Arc` and `Pin` as method receivers
Replaces #55880
Closes #55786
r? @nikomatsakis
cc @withoutboats @cramertj
This lets you write methods using `self: Rc<Self>`, `self: Arc<Self>`, `self: Pin<&mut Self>`, `self: Pin<Box<Self>`, and other combinations involving `Pin` and another stdlib receiver type, without needing the `arbitrary_self_types`. Other user-created receiver types can be used, but they still require the feature flag to use.
This is implemented by introducing a new trait, `Receiver`, which the method receiver's type must implement if the `arbitrary_self_types` feature is not enabled. To keep composed receiver types such as `&Arc<Self>` unstable, the receiver type is also required to implement `Deref<Target=Self>` when the feature flag is not enabled.
This lets you use `self: Rc<Self>` and `self: Arc<Self>` in stable Rust, which was not allowed previously. It was agreed that they would be stabilized in #55786. `self: Pin<&Self>` and other pinned receiver types do not require the `arbitrary_self_types` feature, but they cannot be used on stable because `Pin` still requires the `pin` feature.
