| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This commit 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.
|
|
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..``.
|
|
Instead, use `#[rustc_layout_scalar_valid_range_start(1)]` directly
on relevant libcore types.
|
|
|
|
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.
|
|
address some FIXME whose associated issues were marked as closed
part of #44366
|
|
This reverts commit f1051b574c26e20608ff26415a3dddd13f140925, reversing
changes made to 833e0b3b8a9f1487a61152ca76f7f74a6b32cc0c.
|
|
|
|
|
|
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
|
|
Ignore two tests on s390x
Ignore two tests on s390x which don't make sense on s390x as they are x86-specific.
|
|
Stabilize min_const_unsafe_fn in 1.33
Fixes #55607
r? @oli-obk
|
|
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
|
|
Point to cause of `fn` expected return type
Fix #48136.
|
|
Correct strings for raw pointer deref and array access suggestions
Fixes https://github.com/rust-lang/rust/issues/56714.
Fixes https://github.com/rust-lang/rust/issues/56963.
r? @zackmdavis
|
|
Mark tuple structs as live if their constructors are used
fixes https://github.com/rust-lang/rust/issues/56281
|
|
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
|
|
Fix mutable references in `static mut`
fixes #56903
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The present author regrets not thinking of a more eloquent way to do
this.
|
|
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.
|
|
Rollup of 25 pull requests
Successful merges:
- #56802 (Add DoubleEndedIterator::nth_back)
- #56909 (static eval: Do not ICE on layout size overflow)
- #56914 (Ignore ui/target-feature-gate on sparc, sparc64, powerpc, powerpc64 and powerpc64le)
- #56919 (Remove a wrong multiplier on relocation offset computation)
- #56933 (Add --progress to git submodule commands in x.py)
- #56936 (rename div_euc -> div_euclid, and mod_euc -> rem_euclid)
- #56941 (deny intra-doc link resolution failures in libstd)
- #56945 (Fix rustdoc-js tests)
- #56967 (Replace current crate's searchIndex when regenerating)
- #56970 (Mem uninit doc ptr drop)
- #56973 (make basic CTFE tracing available on release builds)
- #56979 (Adding unwinding support for x86_64_fortanix_unknown_sgx target.)
- #56981 (miri: allocation is infallible)
- #56984 (A few tweaks to dropck_outlives)
- #56989 (Fix compiletest `trim` deprecation warnings)
- #56992 (suggest similar lint names for unknown lints)
- #57002 (Stabilize Vec(Deque)::resize_with)
- #57011 (rustdoc: add new CLI flag to load static files from a different location)
- #57027 (Optimize away a move)
- #57034 (Inline tweaks)
- #57039 (Update migrate warning wording.)
- #57040 (Fix feature gate to point to 1.32.0 for `path_from_str`)
- #57049 (Stabilize #[repr(packed(N))])
- #57050 (Fixed typo in HashMap documentation)
- #57052 (Fix stabilization version numbers (exhaustive_integer_patterns + macro_literal_matcher))
|
|
Disable field reordering for repr(int).
This fixes the problem that the test in #56619 uncovers.
Closes #56619.
|
|
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.
|
|
Stabilize #[repr(packed(N))]
Fixes https://github.com/rust-lang/rust/issues/33158
|
|
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
|
|
suggest similar lint names for unknown lints
Fixes #54737.
|
|
Remove a wrong multiplier on relocation offset computation
r? @RalfJung
fixes #56800
|
|
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
|
|
|
|
|
|
rustdoc: display rustc_private APIs as "Internal"
This PR updates the display of `rustc_private` APIs to be "Internal" instead of "Experimental", and changes the colors appropriately. It also updates the copy of the `rustc_private` feature to sound more informative and less like a compiler suggestion.
The PR additionally contains a significant refactor of the `short_stability` function to remove duplication and fix a few rendering bugs due to extra or missing spaces.
Before:
After:
|
|
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.
|
