[rustdoc] Remove Attrs type alias
When working on https://github.com/rust-lang/rust/pull/101006, I was quite confused because of this type alias as I'm used to having rustdoc types into `clean/types.rs`. Anyway, considering how few uses of it we have, I simply removed it.
r? `````@notriddle`````
Use the declaration's SourceInfo for FnEntry retags, not the outermost
This addresses a long-standing `// FIXME` in the pass that adds retags.
The changes to Miri's UI tests will look like this:
```
--> $DIR/aliasing_mut1.rs:LL:CC
|
LL | pub fn safe(_x: &mut i32, _y: &mut i32) {}
< | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not granting access to tag <TAG> because incompatible item [Unique for <TAG>] is protected by call ID
> | ^^ not granting access to tag <TAG> because incompatible item [Unique for <TAG>] is protected by call ID
|
```
r? ````@RalfJung````
translations: rename warn_ to warning
## Description
This MR renames the the macro `warn_` to `warning`.
To give a little bit of context, as [explained](https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/.23100717.20diag.20translation/near/295074146) by ```````@davidtwco``````` in the Zulip channel, `warn_` was named like that because the keyword `warn` is a built-in attribute and at the time this macro was created the word `warning` was also
taken.
However, it is no longer the case and we can rename `warn_` to `warning`.
extra sanity check against consts pointing to mutable memory
This should be both unreachable and redundant (since we already ensure that validation only reads from read-only memory, when validating consts), but I feel like we cannot be paranoid enough here, and also if this ever fails it'll be a nicer error than the "cannot read from mutable memory" error.
Replace `Body::basic_blocks()` with field access
Since the refactoring in #98930, it is possible to borrow the basic blocks
independently from other parts of MIR by accessing the `basic_blocks` field
directly.
Replace unnecessary `Body::basic_blocks()` method with a direct field access,
which has an additional benefit of borrowing the basic blocks only.
rustc_middle: Remove `Visibility::Invisible`
It had a different meaning in the past, but now it's only used as an implementation detail of import resolution.
no alignment check during interning
This should fix https://github.com/rust-lang/rust/issues/101034
r? `@oli-obk`
Unfortunately we don't have a self-contained testcase for this problem. I am not sure how it can be triggered...
Add GDB/LLDB pretty-printers for NonZero types
Add GDB/LLDB pretty-printers for `NonZero` types.
These pretty-printers were originally implemented for IntelliJ Rust by ```@Kobzol``` in https://github.com/intellij-rust/intellij-rust/pull/5270.
Part of #29392.
Sunset RLS
This removes RLS per the plan outlined in https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html. This replaces the `rls` executable with a small program which will display an alert telling the user that RLS is no longer available.
An overview of the changes here:
* Removes the rls submodule and replaces it with a small stub program.
* `rls` is removed from `./x.py install`. I do not think users running `install` will need the stub.
* `rls` is removed from `./x.py test`, it doesn't have any tests.
Other things of note:
* I kept `DIST_REQUIRE_ALL_TOOLS` even though it is no longer needed, with the thought that it could be useful in the feature. However, I could remove it if desired.
* I kept `extra_deps` in `tool_extended` (which allows tools to depend on other things), even though it is no longer needed. This can also be removed if desired.
* ~~This keeps RLS in the macOS `pkg` installer and the Windows `msi` installer. I kinda lean towards removing it from those, but I'm not sure?~~ RLS has been removed from pkg and msi.
* This does not remove the analysis component. It is not clear if we should keep this or not. RLS was the primary user, but I think there are a few users that have made tools around it.
* There will be several followup steps after this PR:
* Updating the toolstate repo to remove RLS.
* Updating documentation, such as rustc-dev-guide, to remove references to RLS.
The alert looks like this in VSCode:
<img width="989" alt="image" src="https://user-images.githubusercontent.com/43198/185817530-930c5842-24b5-4162-a213-016a25810955.png">
In Sublime it looks similar.
I would appreciate if others could help test with other editors such as vim or Emacs.
Move EH personality functions to std
These were previously in the panic_unwind crate with dummy stubs in the
panic_abort crate. However it turns out that this is insufficient: we
still need a proper personality function even with -C panic=abort to
handle the following cases:
1) `extern "C-unwind"` still needs to catch foreign exceptions with -C
panic=abort to turn them into aborts. This requires landing pads and a
personality function.
2) ARM EHABI uses the personality function when creating backtraces.
The dummy personality function in panic_abort was causing backtrace
generation to get stuck in a loop since the personality function is
responsible for advancing the unwind state to the next frame.
Fixes#41004
Add pointer masking convenience functions
This PR adds the following public API:
```rust
impl<T: ?Sized> *const T {
fn mask(self, mask: usize) -> *const T;
}
impl<T: ?Sized> *mut T {
fn mask(self, mask: usize) -> *const T;
}
// mod intrinsics
fn mask<T>(ptr: *const T, mask: usize) -> *const T
```
This is equivalent to `ptr.map_addr(|a| a & mask)` but also uses a cool llvm intrinsic.
Proposed in https://github.com/rust-lang/rust/pull/95643#issuecomment-1121562352
cc `@Gankra` `@scottmcm` `@RalfJung`
r? rust-lang/libs-api
It's a common phenomenon that feature stabilizations don't make it into
a particular release, but the version is still inaccurate. Often this
leads to subsequent changes to adjust/correct the version.
Instead, require people to put a placeholder that gets replaced during
beta branching time with the current rust version. That way, there is
no chance that an error can be introduced.
Usage of the placeholder is required on the nightly channel, and forbidden
on the stable and beta channels.
Merge duplicated CSS rules
I used the [stylelint](https://stylelint.io/user-guide/configure) tool to check for duplicated CSS rules in order to merge them.
r? `@notriddle`
rustdoc: remove incorrect CSS selector `.impl-items table td`
Fixes#100994
This selector was added in c7312fbae4. The bug can be seen at <https://doc.rust-lang.org/1.27.0/alloc/slice/trait.SliceIndex.html#foreign-impls>.
This rule was added to help with a `<table>` that was used for displaying the function signature [src] lockup. That lockup was changed in 34bd2b845b to use flexbox instead, leaving this selector unused (at least, for its original purpose).
rustdoc: remove unused CSS for `hidden-by-*-hider`
This CSS seems to have become obsolete with the move to `<details>` tags,
and its corresponding JavaScript was removed in aee054d05d
rustdoc: omit start/end tags for empty item description blocks
Related to #100952
This is definitely not a complete solution, but it does shrink keysyms/index.html on smithay from 620K to 516K.
Fix wrong compiletest filters on Windows
As discussed in [#79334](https://github.com/rust-lang/rust/issues/79334), when calling e.g.
```
python x.py test src/test/ui/expr/compound-assignment/eval-order.rs
```
on Windows, compiletest passes the filter `expr/compound-assignment/eval-order.rs` to libtest, which instead should be `expr\compound-assignment\eval-order.rs`, as that is the file found when collecting tests. This is what I fixed.
I'm not sure how to organize a test for this. Any suggestions?
Make forward compatibility lint deprecated_cfg_attr_crate_type_name deny by default
Turns the forward compatibility lint added by #83744 to deprecate `cfg_attr` usage with `#![crate_type]` and `#![crate_name]` attributes into deny by default. Copying the example from #83744:
```Rust
#![crate_type = "lib"] // remains working
#![cfg_attr(foo, crate_type = "bin")] // will stop working
```
Over 8 months have passed since #83744 was merged so I'd say this gives ample time for people to have been warned, so we can make the warning stronger. No usage was found via grep.app except for one, which was in an unmaintained code base that didn't seem to be used in the open source eco system. The crater run conducted in #83744 also didn't show up anything.
cc #91632 - tracking issue for the lint
Implementation of import_name_type
Fixes#96534 by implementing https://github.com/rust-lang/compiler-team/issues/525
Symbols that are exported or imported from a binary on 32bit x86 Windows can be named in four separate ways, corresponding to the [import name types](https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#import-name-type) from the PE-COFF spec. The exporting and importing binaries must use the same name encoding, otherwise mismatches can lead to link failures due to "missing symbols" or to 0xc0000139 (`STATUS_ENTRYPOINT_NOT_FOUND`) errors when the executable/library is loaded. For details, see the comments on the raw-dylib feature's https://github.com/rust-lang/rust/issues/58713. To generate the correct import libraries for these DLLs, therefore, rustc must know the import name type for each `extern` function, and there is currently no way for users to provide this information.
This change adds a new `MetaNameValueStr` key to the `#[link]` attribute called `import_name_type`, and which accepts one of three values: `decorated`, `noprefix`, and `undecorated`.
A single DLL is likely to export all its functions using the same import type name, hence `import_name_type` is a parameter of `#[link]` rather than being its own attribute that is applied per-function. It is possible to have a single DLL that exports different functions using different import name types, but users could express such cases by providing multiple export blocks for the same DLL, each with a different import name type.
Note: there is a fourth import name type defined in the PE-COFF spec, `IMPORT_ORDINAL`. This case is already handled by the `#[link_ordinal]` attribute. While it could be merged into `import_type_name`, that would not make sense as `#[link_ordinal]` provides per-function information (namely the ordinal itself).
Design decisions (these match the MCP linked above):
* For GNU, `decorated` matches the PE Spec and MSVC rather than the default behavior of `dlltool` (i.e., there will be a leading `_` for `stdcall`).
* If `import_name_type` is not present, we will keep our current behavior of matching the environment (MSVC vs GNU) default for decorating.
* Using `import_name_type` on architectures other than 32bit x86 will result in an error.
* Using `import_name_type` with link kinds other than `"raw-dylib"` will result in an error.
sugg: suggest the usage of boolean value when there is a typo in the keyword
Fixes https://github.com/rust-lang/rust/issues/100686
This adds a new suggestion when there is a well-known typo
With the following program
```rust
fn main() {
let x = True;
}
```
Now we have the following suggestion
```
error[E0425]: cannot find value `True` in this scope
--> test.rs:2:13
|
2 | let x = True;
| ^^^^ not found in this scope
|
help: you may want to use a bool value instead
|
2 | let x = true;
| ~~~~
error: aborting due to previous error
```
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
interpret: remove support for uninitialized scalars
With Miri no longer supporting `-Zmiri-allow-uninit-numbers`, we no longer need to support storing uninit data in a `Scalar`. We anyway already only use this representation for types with *initialized* `Scalar` layout (and we have to, due to partial initialization), so let's get rid of the `ScalarMaybeUninit` type entirely.
I tried to stage this into meaningful commits, but the one that changes `read_immediate` to always trigger UB on uninit is the largest chunk of the PR and I don't see how it could be subdivided.
Fixes https://github.com/rust-lang/miri/issues/2187
r? `@oli-obk`
