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.
Rework treatment of `$crate` in procedural macros
Important clarification: `$crate` below means "processed `$crate`" or "output `$crate`". In the input of a decl macro `$crate` is just two separate tokens, but in the *output of a decl macro* `$crate` is a single keyword identifier (https://github.com/rust-lang/rust/issues/55640#issuecomment-435692791).
First of all, this PR removes the `eliminate_crate_var` hack.
`$crate::foo` is no longer replaced with `::foo` or `::crate_name::foo` in the input of derive proc macros, it's passed to the macro instead with its precise span and hygiene data, and can be treated as any other path segment keyword (like `crate` or `self`) after that. (Note: `eliminate_crate_var` was never used for non-derive proc macros.)
This creates an annoying problem - derive macros still may stringify their input before processing and expect `$crate` survive that stringification and refer to the same crate (the Rust 1.15-1.29 way of doing things).
Moreover, the input of proc macro attributes and derives (but not fn-like proc macros) also effectively survives stringification before being passed to the macro (also for legacy implementation reasons).
So we kind of resurrect the `eliminate_crate_var` hack in reduced form, but apply it only to AST pretty-printing.
If an AST fragment is pretty-printed, the resulting *text* will have `$crate` replaced with `crate` or `::crate_name`. This should be enough to keep all the legacy cases working.
Closes https://github.com/rust-lang/rust/issues/55640
Closes https://github.com/rust-lang/rust/issues/56622
r? @ghost
also updated some error messages
removed the code manually checking for `receiver_ty: Deref<Target=self_ty>`, in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before, a "mismatched method receiver" error would be emitted when `receiver_ty` was valid except for a lifetime parameter, but only when `feature(arbitrary_self_types)` was enabled, and without the feature flag the error would be "uncoercible receiver". Now it emits "mismatched method receiver" in both cases.
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.
trigger unsized coercions keyed on Sized bounds
This PR causes unsized coercions to not be disabled by `$0: Unsize<dyn
Object>` coercion obligations when we have an `$0: Sized` obligation somewhere.
This should be mostly backwards-compatible, because in these cases not doing the unsize coercion should have caused the `$0: Sized` obligation to fail.
Note that `X: Unsize<dyn Object>` obligations can't fail *as obligations* if `X: Sized` holds, so this still maintains some version of monotonicity (I think that an unsized coercion can't be converted to no coercion by unifying type variables).
Fixes#49593 (unblocking never_type).
r? @eddyb
cc @nikomatsakis
Add targets thumbv7neon-linux-androideabi and thumbv7neon-unknown-linux-gnueabihf
These two targets enable both thumb-mode and NEON for ARMv7 CPUs.
This another attempt at #49902, which cannot be reopened. Between that PR and this one, some subrepos with C code whose build systems were failing went away.
Fix grammar in compiler error for array iterators
This fixes a small grammatical mistake in the message the compiler gives when attempting to iterate directly over an array `arr` without calling `arr.iter()` or borrowing `&arr`.
add a lint group for lints emitted by rustdoc
As rustdoc adds more lints that it specifically manages, it would be nice to be able to lump them all together. This gives us a new group just for that.
I deliberately didn't include `missing_docs` because this is kind of a stepping stone for moving our lints into tool lints (i.e. `#![warn(rustdoc::private_doc_tests)]`), since all of these are specifically emitted by rustdoc. If we want to move `missing_docs` out of the compiler, that's also an option, but it would create a surprising change of behavior.
I also took the chance to rewrite the lint descriptions of these lints to better match the style of the other lints. `>_>`
Search other library paths when loking for link objects
Support the case when link objects are not located in Rust sysroot
but in other locations which could be specify through library paths.
fix trait objects with a Self-containing projection values
Fixes#56288.
This follows ALT2 in the issue.
beta-nominating since this is a regression.
r? @nikomatsakis
Fix various aspects around `let` bindings inside const functions
* forbid `let` bindings in const contexts that use short circuiting operators
* harden analysis code against derefs of mutable references
Initially this PR was about stabilizing `let` bindings, but too many flaws were exposed that need some more testing on nightly
