| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Fix `#[link kind="raw-dylib"]` to respect `#[link_name]`
Issue Details:
When using `#[link kind="raw-dylib"]` (#58713), the Rust compiler ignored any `#[link_name]` attributes when generating the import library and so the resulting binary would fail to link due to missing symbols.
Fix Details:
Use the name from `#[link_name]` if present when generating the `raw-dylib` import library, otherwise default back to the actual symbol name.
|
|
|
|
|
|
|
|
Stabilize raw-dylib for non-x86
This stabilizes the `raw-dylib` and `link_ordinal` features (#58713) for non-x86 architectures (i.e., `x86_64`, `aarch64` and `thumbv7a`):
* Marked the `raw_dylib` feature as `active`.
* Marked the `link_ordinal` attribute as `ungated`.
* Added new errors if either feature is used on x86 targets without the `raw_dylib` feature being enabled.
* Updated tests to only set the `raw_dylib` feature when building for x86.
|
|
|
|
Fix `-Zgcc-ld=lld`
`-Zgcc-ld=lld` is currently broken. CI is currently ignoring its tests.
cc `@Mark-Simulacrum` on the `compiletest` change: I'm not sure which of `bootstrap`'s test step or `compiletest` is currently incorrect wrt windows' `--compile-lib-path`. Since `sysroot/bin` is passed on windows, that means that `compiletest` can't find `rust-lld` on windows and tests are currently ignored: it's looking for something that is in `sysroot/lib` instead.
They are currently ignored on unixes for a different reason: the lld wrapper has a different name than what is checked.
(I've changed `compiletest` in this PR, just because I could make a very targeted change there, whereas completely changing the intentional lib path that is passed seemed it'd have wider reaching implications on all tests.)
And in both unix/win cases, I've changed the detection to look for `rust-lld` rather than the wrappers in `bin/gcc-ld/`. It seems like the more stable of all these executable names.
r? `@petrochenkov`
I've tested the `lld-wrapper` change on linux and osx, but couldn't test on windows gnu targets (I only have MSVC targets, and these can't use `rust-lld` via `-Zgcc-ld=lld`, nor do they use the lld wrapper IIUC).
I'd expect it to work whether or not the wrapper is called with or without an executable suffix. But at least now CI should test it in these targets.
Fixes #101370.
|
|
now that CI correctly detects rust-lld in run-make tests, we ignore this
test since it relies on `-Zgcc-ld=lld` which is not made to work on the
windows-msvc targets: it requires a gcc flavor.
|
|
Track PGO profiles in depinfo
This PR makes sure that PGO profiles (`-Cprofile-use` and `-Cprofile-sample-use`) are tracked in depinfo, so that when they change, the compilation session will be invalidated.
This approach was discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Tracking.20PGO.20profile.20files.20in.20cargo).
I tried it locally and it seems that the code is recompiled just with this change, and https://github.com/rust-lang/rust/pull/100413 is not even needed. But it's possible that not everything required is recompiled, so we will probably want to land both changes.
Another approach to implement this could be to store the PGO profiles in `sess.parse_sess.file_depinfo` when the session is being created, but then the paths would have to be converted to a string and then to a symbol, which seemed unnecessarily complicated.
CC `@michaelwoerister`
r? `@Eh2406`
|
|
This PR will fix some typos detected by [typos].
I only picked the ones I was sure were spelling errors to fix, mostly in
the comments.
[typos]: https://github.com/crate-ci/typos
|
|
|
|
|
|
|
|
Don't derive `PartialEq::ne`.
Currently we skip deriving `PartialEq::ne` for C-like (fieldless) enums
and empty structs, thus reyling on the default `ne`. This behaviour is
unnecessarily conservative, because the `PartialEq` docs say this:
> Implementations must ensure that eq and ne are consistent with each other:
>
> `a != b` if and only if `!(a == b)` (ensured by the default
> implementation).
This means that the default implementation (`!(a == b)`) is always good
enough. So this commit changes things such that `ne` is never derived.
The motivation for this change is that not deriving `ne` reduces compile
times and binary sizes.
Observable behaviour may change if a user has defined a type `A` with an
inconsistent `PartialEq` and then defines a type `B` that contains an
`A` and also derives `PartialEq`. Such code is already buggy and
preserving bug-for-bug compatibility isn't necessary.
Two side-effects of the change:
- There is only one error message produced for types where `PartialEq`
cannot be derived, instead of two.
- For coverage reports, some warnings about generated `ne` methods not
being executed have disappeared.
Both side-effects seem fine, and possibly preferable.
|
|
Replace - with _ in fluent slugs to improve developer workflows
This is a proposal to smoothen the compiler contribution experience in the face of the move to fluent.
## Context
The fluent project has introduced a layer of abstraction to compiler errors. Previously, people would write down error messages directly in the same file the code was located to emit them. Now, there is a slug that connects the code in the compiler to the error message in the ftl file.
You can look at 7ef610c003f8072ec4ca4ecf195922a9a44e48dd to see an example of the changes:
Old:
```Rust
let msg = format!(
"bounds on `{}` are most likely incorrect, consider instead \
using `{}` to detect whether a type can be trivially dropped",
predicate,
cx.tcx.def_path_str(needs_drop)
);
lint.build(&msg).emit();
```
New (Rust side):
```Rust
lint.build(fluent::lint::drop_trait_constraints)
.set_arg("predicate", predicate)
.set_arg("needs_drop", cx.tcx.def_path_str(needs_drop))
.emit();
```
New (Fluent side):
```fluent
lint-drop-trait-constraints =
bounds on `{$predicate}` are most likely incorrect, consider instead using `{$needs_drop}` to detect whether a type can be trivially dropped
```
You will note that in the ftl file, the slug is slightly different from the slug in the Rust file: The ftl slug uses `-` (e.g. `lint-drop-trait-constraints`) while the rust slug uses `::` and `_` (e.g. `lint::drop_trait_constraints`). This choice was probably done due to:
* Rust not accepting `-` in identifiers (as it is an operator)
* fluent not supporting the `:` character in slug names (parse error upon attempts)
* all official fluent documentation using `-` instead of `_`
## The problem
The two different types of slugs, one with `-`, and one with `_`, cause difficulties for contributors. Imagine you don't have perfect knowledge of where stuff is in the compiler (i would say this is most people), and you encounter an error for which you think there is something you could improve that is not just a rewording.
So you want to find out where in the compiler's code that error is being emitted. The best way is via grepping.
1. you grep for the message in the compiler's source code. You discover the ftl file and find out the slug for that error.
2. That slug however contains `-` instead of `_`, so you have to manually translate the `-`'s into `_`s, and furthermore either remove the leading module name, or replace the first `-` with a `::`.
3. you do a second grep to get to the emitting location in the compiler's code.
This translation difficulty in step 2 appears also in the other direction when you want to figure out what some code in the compiler is doing and use error messages to help your understanding. Comments and variable names are way less exposed to users so [are more likely going to lie](https://github.com/rust-lang/rust/commit/cc3c5d2700481bae497d6cde825c1d48e79c776a) than error messages.
I think that at least the `-`→`_` translation which makes up most of step 2 can be removed at low cost.
## The solution
If you look closely, the practice of fluent to use `-` is only a stylistic choice and it is not enforced by fluent implementations, neither the playground nor the one the rust compiler uses, that slugs may not contain `_`. Thus, we can in fact migrate the ftl side to `_`. So now we'll have slugs like `lint_drop_trait_constraints` on the ftl side. You only have to do one replacement now to get to the Rust slug: remove the first `_` and place a `::` in its stead. I would argue that this change is in fact useful as it allows you to control whether you want to look at the rust side of things or the ftl side of things via changing the query string only: with an increased number of translations checked into the repository, grepping for raw slugs will return the slug in many ftl files, so an explicit step to look for the source code is always useful. In the other direction (rust to fluent), you don't need a translation at all any more, as you can just take the final piece of the slug (e.g. `drop_trait_constraints`) and grep for that. The PR also adds enforcement to forbid usage of `_` in slug names. Internal slug names (those leading with a `-`) are exempt from that enforcement.
As another workflow that benefits from this change, people who add new errors don't have to do that `-` conversion either.
| Before/After | Fluent slug | Rust slug (no change) |
|--|--|--|
| Before | `lint-drop-trait-constraints` | `lint::drop_trait_constraints`|
| After | `lint_drop_trait_constraints` | `lint::drop_trait_constraints`|
Note that I've suggested this previously in the translation thread on zulip. I think it's important to think about non-translator contribution impact of fluent. I have certainly plans for more improvements, but this is a good first step.
``@rustbot`` label A-diagnostics
|
|
Refuse to codegen an upstream static.
Fixes https://github.com/rust-lang/rust/issues/85401
|
|
|
|
errors: don't fail on broken primary translations
If a primary bundle doesn't contain a message then the fallback bundle is used. However, if the primary bundle's message is broken (e.g. it refers to a interpolated variable that the compiler isn't providing) then this would just result in a compiler panic. While there aren't any primary bundles right now, this is the type of issue that could come up once translation is further along.
r? ```@compiler-errors``` (since this comes out of a in-person discussion we had at RustConf)
|
|
|
|
If a primary bundle doesn't contain a message then the fallback bundle
is used. However, if the primary bundle's message is broken (e.g. it
refers to a interpolated variable that the compiler isn't providing)
then this would just result in a compiler panic. While there aren't any
primary bundles right now, this is the type of issue that could come up
once translation is further along.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
@__llvm_profile_runtime is how an external hidden global.
|
|
Add test for raw-dylib with an external variable
All existing tests of link kind `raw-dylib` only validate the ability to link against functions, but it is also possible to link against variables.
This adds tests for linking against a variable using `raw-dylib` both by-name and by-ordinal.
|
|
|
|
Fixes #100066
|
|
Add tests for raw-dylib with vectorcall, and fix vectorcall code generation
* Adds tests for using `raw-dylib` (#58713) with `vectorcall`.
* Fixed code generation for `vectorcall` (parameters have to be marked with `InReg`, just like `fastcall`).
* Enabled running the `raw-dylib` `fastcall` tests when using MSVC (since I had to add support in the test for running MSVC-only tests since GCC doesn't support `vectorcall`).
|
|
Currently we skip deriving `PartialEq::ne` for C-like (fieldless) enums
and empty structs, thus reyling on the default `ne`. This behaviour is
unnecessarily conservative, because the `PartialEq` docs say this:
> Implementations must ensure that eq and ne are consistent with each other:
>
> `a != b` if and only if `!(a == b)` (ensured by the default
> implementation).
This means that the default implementation (`!(a == b)`) is always good
enough. So this commit changes things such that `ne` is never derived.
The motivation for this change is that not deriving `ne` reduces compile
times and binary sizes.
Observable behaviour may change if a user has defined a type `A` with an
inconsistent `PartialEq` and then defines a type `B` that contains an
`A` and also derives `PartialEq`. Such code is already buggy and
preserving bug-for-bug compatibility isn't necessary.
Two side-effects of the change:
- There is only one error message produced for types where `PartialEq`
cannot be derived, instead of two.
- For coverage reports, some warnings about generated `ne` methods not
being executed have disappeared.
Both side-effects seem fine, and possibly preferable.
|
|
flag '-l link-arg=___ was added
#99427
|
|
|
|
|
|
|
|
arbitrary link argument like -C link-arg, but respecting relative order to other `-l` options, unstable
|
|
Enable raw-dylib for bin crates
Fixes #93842
When `raw-dylib` is used in a `bin` crate, we need to collect all of the `raw-dylib` functions, generate the import library and add that to the linker command line.
I also changed the tests so that 1) the C++ dlls are created after the Rust dlls, thus there is no chance of accidentally using them in the Rust linking process and 2) disabled generating import libraries when building with MSVC.
|
|
|
|
|
|
This is no longer used only for debugging options (e.g. `-Zoutput-width`, `-Zallow-features`).
Rename it to be more clear.
|
|
|
|
Rename the `--output-width` flag to `--diagnostic-width` as this appears
to be the preferred name within the compiler team.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
Rename the `--terminal-width` flag to `--output-width` as the behaviour
doesn't just apply to terminals (and so is slightly less accurate).
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
Formerly `-Zterminal-width`, `--terminal-width` allows the user or build
tool to inform rustc of the width of the terminal so that diagnostics
can be truncated.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
adapt native-link-modifier-bundle test to use llvm-nm
No functional changes intended.
This updates the test case to use `llvm-nm` as an alternative to https://github.com/rust-lang/rust/pull/98424.
This fixes a test failure over at the experimental build of rustc with HEAD LLVM:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/11144#01814d0f-a46a-4c19-91cf-41e720edb6f9/684-691.
The issue is that this test uses the system nm, which may not be recent
enough to understand the bitcode produced by rustc when compiled against HEAD LLVM.
Similar to what we did for another test in https://github.com/rust-lang/rust/pull/94023.
|
|
|
|
Previously, this printed the debugging options, not the lint options,
and only handled `-Whelp`, not `-A/-D/-F`.
This also fixes a few other misc issues:
- Fix `// check-stdout` for UI tests; previously it only worked for run-fail and compile-fail tests
- Add lint headers for tool lints, not just builtin lints
- Remove duplicate run-make test
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Move Derefer before Retag
_Follow up work to #96116 #95857 #95649_
This moves `Derefer` before `Retag` and creates a new `LocalInfo` called `Temp` to avoid retagging created temp values.
Zulip discussion [link](https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/deref.20as.20first.20and.20only.20projection)
r? `@oli-obk`
|
