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.
Migrate rustc_driver to SessionDiagnostic
First timer noob here 👋🏽 I'm having a problem understanding how I can retrieve the span, and how to properly construct the error structs to avoid the current compilation errors.
Any help pointing me in the right direction would be much appreciated 🙌🏽
Migrate `rustc_attr` crate diagnostics
Hi!
This is my first PR to the rustc project, excited to be part of the development! This PR is part of the diagnostics effort, to make diagnostics translatable.
`@rustbot` label +A-translation
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>
Diagnostics migr const eval
This PR should eventually contain all diagnostic migrations for the `rustc_const_eval` crate.
r? `@davidtwco`
`@rustbot` label +A-translation
Migrate `rustc_ty_utils` to `SessionDiagnostic`
I have migrated the `rustc_ty_utils` crate to use `SessionDiagnostic`, motivated by the [recent blog post about the diagnostic translation effort](https://blog.rust-lang.org/inside-rust/2022/08/16/diagnostic-effort.html).
This is my first PR to the Rust repository, so if I have missed anything, or anything needs to be changed, please let me know! 😄
`@rustbot` label +A-translation
Migrate ast lowering to session diagnostic
I migrated the whole rustc_ast_lowering crate to session diagnostic *except* the for the use of `span_fatal` at /compiler/rustc_ast_lowering/src/expr.rs#L1268 because `#[fatal(...)]` is not yet supported (see https://github.com/rust-lang/rust/pull/100694).
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`
session: stabilize split debuginfo on linux
Stabilize the `-Csplit-debuginfo` flag...
- ...on Linux for all values of the flag. Split DWARF has been implemented for a few months, hasn't had any bug reports and has had some promising benchmarking for incremental debug build performance.
- ..on other platforms for the default value. It doesn't make any sense that `-Csplit-debuginfo=packed` is unstable on Windows MSVC when that's the default behaviour, but keep the other values unstable.
rustdoc: remove unused CSS for `.variants_table`
Continuation of #100938 and #101010. This rule was added to support the old, table-based style for displaying enum variants, which are now displayed using headers and paragraphs.
Fix doc cfg on reexports
Fixes#83428.
The problem was that the newly inlined item cfg propagation was not working since its real parent is different than its current one.
For the implementation, I decided to put it directly into `CfgPropagation` instead of inside `inline.rs` because I thought it would be simpler to maintain and to not forget if new kind of items are added if it's all done in one place.
r? `@notriddle`
Reduce right-side DOM size
This is another follow-up of https://github.com/rust-lang/rust/pull/100429 but not in code blocks this time.
So the idea is: if there is only one element in the `.rightside` element, there is no need to wrap it, we can just create one node.
On each page, I run this JS: `document.getElementsByTagName('*').length`. Important to note: the bigger the number of elements inside the page, the greater the gain. It also doesn't work very nicely on std docs because there are a lot of version annotations. So with this PR, It allows to get the following results:
| file name | before this PR | with this PR | diff |
|-|-|-|-|
| std/default/trait.Default.html | 2189 | 1331 | 39.2% |
| std/vec/struct.Vec.html | 14073 | 13842 | 1.7% |
| std/fmt/trait.Debug.html | 5313 | 4907 | 7.7% |
| std/ops/trait.Index.html | 642 | 630 | 1.9% |
| gtk4/WidgetExt | 3269 | 3061 | 6.4% |
You can test it [here](https://rustdoc.crud.net/imperio/reduce-rightsize-dom-size/gtk4/prelude/trait.WidgetExt.html).
r? `@notriddle`
BTree: evaluate static type-related check at compile time
`assert`s like the ones replaced here would only go off when you run the right test cases, if the code were ever incorrectly changed such that rhey would trigger. But [inspired on a nice forum question](https://users.rust-lang.org/t/compile-time-const-generic-parameter-check/69202), they can be checked at compile time.
Avoid reporting overflow in `is_impossible_method`
Fixes#100620
We're evaluating a new predicate in a different param-env than it was checked during typeck, so be more careful about handling overflow errors. Instead of using `FulfillmentCtxt`, using `InferCtxt::evaluate_obligation` by itself will give us back the overflow error, so we can throw it away properly.
This may give us more false-positives, but it doesn't regress the `<HashMap as Iterator>::rev` example that originally motivated adding `is_impossible_method` in the first place.
rustdoc: remove unused CSS for `.multi-column`
As a sanity check, [this tool] can be used to run a CSS query across an HTML tree to detect if a selector ever matches (I use compiler-docs and std docs). This isn't good enough, because I also need to account for JavaScript, but this class is never mentioned in any of the JS files, either.
According to [blame], this class was added when rustdoc was first written, and, as far as I can tell, was never actually used.
[this tool]: https://gitlab.com/notriddle/html-scanner
[blame]: 4d45b0745a/src/librustdoc/html/static/css/rustdoc.css (L753-L761)
