This commit improves the logic for place descriptions in conflicting
borrow errors so that borrows of union fields have better messages even
when the unions are embedded in other unions or structs.
This commit adds justifications to error messages for conflicting
borrows of union fields.
Where previously an error message would say
``cannot borrow `u.b` as mutable..``, it now says
``cannot borrow `u` (via `u.b`) as mutable..``.
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.
Instead disable creation of assumptions during inlining using an
LLVM opt flag.
The -Z arg-align-attributes option which previously controlled this
behavior is removed.
