| Age | Commit message (Collapse) | Author | Lines |
|---|
|
reduce tidy overheads in run-make checks
This change makes tidy to handle run-make checks with a single iteration, avoiding the need for multiple iterations and copying.
|
|
run-make-support: tidy up support library
- Make `handle_failed_output` take `&Command` instead of having the caller keep doing `format!("{:#?}", s)`.
- Introduce a helper macro for implementing common command wrappers, such as `arg`, `args`, `run`, `run_fail`.
- Use the helper macro on existing command wrappers and remove manual copy-pasta'd implementations.
|
|
Fixes a regression caused by 0a50dba50bedd24377bd1066da3b4b7066df4d28
|
|
bootstrap: move all of rustc's flags to `rustc_cargo`
This ensures that `RUSTFLAGS` will be consistent between all modes of
building the compiler, so they won't trigger a rebuild by cargo. This
kind of fix was started in #119414 just for LTO flags, but it's
applicable to all kinds of flags that might be configured.
|
|
|
|
|
|
Removes the manual copy-pasta'd implementation of common methods.
|
|
Add a helper macro for adding common methods to command wrappers. Common
methods include helpers that delegate to `Command` and running methods.
- `arg` and `args` (delegates to `Command`)
- `env`, `env_remove` and `env_clear` (delegates to `Command`)
- `output`, `run` and `run_fail`
This helps to avoid needing to copy-pasta / reimplement these common
methods on a new command wrapper, which hopefully reduces the friction
for run-make test writers wanting to introduce new command wrappers.
|
|
|
|
Miri subtree update
r? ``@ghost``
|
|
do not allow using local llvm while using rustc from ci
From: https://github.com/rust-lang/rust/issues/123586#issuecomment-2043296578
> Even if `llvm.download-ci-llvm` is set to true, `stage > 0` rustc will always use the prebuilt LLVM library which comes with ci-rustc. So I tried to use locally-built LLVM libraries in the ci-rustc by replacing the existing LLVM libraries with the locally built ones, and it appears that this is indeed a limitation of using `rust.download-rustc=true` as it fails with the following error:
>
> ```
> $ ./build/host/ci-rustc/bin/rustc --version
> ./build/host/ci-rustc/bin/rustc: symbol lookup error: /home/nimda/devspace/.other/rustc-builds/build/x86_64-unknown-linux-gnu/ci-rustc/bin/../lib/librustc_driver-a03ea465d8e03db1.so: undefined symbol: LLVMInitializeARMTargetInfo, version LLVM_18.1
> ```
>
> So, if `rust.download-rustc` is set to true and `llvm.download-ci-llvm` is false, I believe bootstrap should terminate the process (as it always uses prebuilt LLVM libraries from ci-rustc, there is no point to build LLVM locally) while parsing the configuration.
Resolves #123586
r? Mark-Simulacrum
|
|
Enable building tier2 target riscv32im-unknown-none-elf
riscv32im-unknown-none-elf was promoted to tier2 in
https://github.com/rust-lang/rust/pull/117874
but it has not yet been added to the list of build targets.
By adding riscv32im-unknown-none-elf to the list of build targets, this PR enables end-users to install this target via rustup.
|
|
Linker flavors next steps: linker features
This is my understanding of the first step towards `@petrochenkov's` vision for the future of linker flavors, described in https://github.com/rust-lang/rust/pull/119906#issuecomment-1895693162 and the discussion that followed.
To summarize: having `Cc` and `Lld` embedded in linker flavors creates tension about naming, and a combinatorial explosion of flavors for each new linker feature we'd want to use. Linker features are an extension mechanism that is complementary to principal flavors, with benefits described in #119906.
The most immediate use of this flag would be to turn self-contained linking on and off via features instead of flavors. For example, `-Clinker-features=+/-lld` would toggle using lld instead of selecting a precise flavor, and would be "generic" and work cross-platform (whereas linker flavors are currently more tied to targets). Under this scheme, MCP510 is expected to be `-Clink-self-contained=+linker -Zlinker-features=+lld -Zunstable-options` (though for the time being, the original flags using lld-cc flavors still work).
I purposefully didn't add or document CLI support for `+/-cc`, as it would be a noop right now. I only expect that we'd initially want to stabilize `+/-lld` to begin with.
r? `@petrochenkov`
You had requested that minimal churn would be done to the 230 target specs and this does none yet: the linker features are inferred from the flavor since they're currently isomorphic. We of course expect this to change sooner rather than later.
In the future, we can allow targets to define linker features independently from their flavor, and remove the cc and lld components from the flavors to use the features instead, this actually doesn't need to block stabilization, as we discussed.
(Best reviewed per commit)
|
|
This change makes tidy to handle run-make checks with a single iteration,
avoiding the need for multiple iterations and copying.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
De-duplicate SSE2 sll/srl/sra code
|
|
Update cargo
8 commits in 74fd5bc730b828dbc956335b229ac34ba47f7ef7..48eca1b164695022295ce466b64b44e4e0228b08
2024-04-10 18:40:49 +0000 to 2024-04-12 21:16:36 +0000
- test: Remove add/remove death tests (rust-lang/cargo#13750)
- feat(resolve): Fallback to 'rustc -V' for MSRV resolving (rust-lang/cargo#13743)
- feat(cli): Add --ignore-rust-version to update/generate-lockfile (rust-lang/cargo#13742)
- `cargo package -p no-exist` emitt error when the -p `package` not found (rust-lang/cargo#13735)
- fix(help): Generalize --ignore-rust-version (rust-lang/cargo#13741)
- test: don't compress test registry crates (rust-lang/cargo#13744)
- feat(reslve): Respect '--ignore-rust-version' (rust-lang/cargo#13738)
- refactor: Remove `rust_2024_compatibility` lint group (rust-lang/cargo#13740)
r? ghost
|
|
This updates the Fuchsia commit used in `auto - x86_64-gnu-integration`
CI bot to use the Rust commit 703dc9ce64d9b31a239a7280d9b5f9ddd85ffed6.
This should help improve the coverage of this builder.
It also updates the SDK version to F20.20240412.3.1, and the Fuchsia Clang
version to c777c011a709dffd4fa5e79cad7947b7c3405d02.
|
|
|
|
Add `/System/iOSSupport` to the library search path on Mac Catalyst
On macOS, `/System/iOSSupport` contains iOS frameworks like UIKit, which is the whole idea of Mac Catalyst.
To link to these, we need to explicitly tell the linker about the support library stubs provided in the macOS SDK under the same path.
Concretely, when building a binary for Mac Catalyst, Xcode passes the following flags to the linker:
```
-iframework /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/System/iOSSupport/System/Library/Frameworks
-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk/System/iOSSupport/usr/lib
```
This is not something that can be disabled (it's enabled as soon as you enable `SUPPORTS_MACCATALYST`), so I think it's pretty safe to say that we don't need an option to turn these off.
I've chosen to slightly deviate from what Xcode does and use `-F` instead of `-iframework`, since we don't need to change the header search path, and this way the flags nicely match on all the linkers. From what I could tell by reading Clang sources, there shouldn't be a difference when just running the linker.
CC `@BlackHoleFox,` `@shepmaster` (I accidentally let rustbot choose the reviewer).
|
|
|
|
rustdoc: point at span in `include_str!`-ed md file
Fixes #118549
|
|
Remove unused cargo-platform dependency from tidy
Noticed in https://github.com/rust-lang/rust/pull/123788#issuecomment-2049806519
|
|
|
|
Set the host library path in run-make v2
When the build is configured with `[rust] rpath = false`, we need to set
`LD_LIBRARY_PATH` (or equivalent) to what would have been the `RPATH`,
so the compiler can find its own libraries. The old `tools.mk` code has
this environment prefixed in the `$(BARE_RUSTC)` variable, so we just
need to wire up something similar for run-make v2.
This is now set while building each `rmake.rs` itself, as well as in the
`rust-make-support` helpers for `rustc` and `rustdoc` commands. This is
also available in a `set_host_rpath` function for manual commands, like
in the `compiler-builtins` test.
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #122882 (Avoid a panic in `set_output_capture` in the default panic handler)
- #123523 (Account for trait/impl difference when suggesting changing argument from ref to mut ref)
- #123744 (Silence `unused_imports` for redundant imports)
- #123784 (Replace `document.write` with `document.head.insertAdjacent`)
- #123798 (Avoid invalid socket address in length calculation)
- #123804 (Stop using `HirId` for fn-like parents since closures are not `OwnerNode`s)
- #123806 (Panic on overflow in `BorrowedCursor::advance`)
- #123820 (Add my former address to .mailmap)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Replace `document.write` with `document.head.insertAdjacent`
From [this comment](https://github.com/rust-lang/rust/pull/123706/files#r1559864981), using `document.write` is strongly discouraged (explained on [MDN](https://developer.mozilla.org/en-US/docs/Web/API/Document/write)).
I think in this case it was mostly ok but better be on the safe side.
r? `@notriddle`
|
|
Correctly handle inlining of doc hidden foreign items
Fixes #123435.
In case a foreign item has doc(hidden) attribute, we simply merged its attributes with the re-export's, making it being removed once in the `strip_hidden` pass.
The solution was to use the same as for local reexported items: merge attributes, but not some of them (like `doc(hidden)`).
I originally checked if we could simply update `Item::is_doc_hidden` method to use `self.inline_stmt_id.is_some_and(|def_id| tcx.is_doc_hidden(def_id))` but unfortunately, it added (local) items that shouldn't be inlined. At least it unifies local and foreign items inlining, which I think is the best course of action here.
r? `@notriddle`
|
|
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #123660 (Make the computation of `coroutine_captures_by_ref_ty` more sophisticated)
- #123738 (Call lower_const_param instead of duplicating the code)
- #123774 (Fix typo MaybeUnit -> MaybeUninit)
- #123790 (correct the handling of `bootstrap-cache-path` option)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
It incorrectly filters out non-wasm dependencies too.
|
|
This change makes `build.bootstrap-cache-path` option to be configurable with
`./configure` script, so it can be used like `./configure --bootstrap-cache-path=demo`.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Rollup of 2 pull requests
Successful merges:
- #123704 (Tweak value suggestions in `borrowck` and `hir_analysis`)
- #123753 (compiletest: error when finding a trailing directive)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
compiletest: error when finding a trailing directive
This PR introduce a supplementary check that when checking for a compiletest directive, will also check that the next "word" after that directive is not also by itself a directive.
This is done to avoid situations like this `//@ only-linux only-x86_64` where one might think that both directives are being taken into account while in fact the second in a comment, and so was ignored, until now.
Related to #123730
cc ``@scottmcm``
r? ``@jieyouxu``
|
|
Add support for Arm64EC inline assembly (as unstable)
Compiler support for Arm64EC assembly mostly reuses the existing AArch64 support, except that it needs to block registers that are not permitted: <https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi#register-mapping-and-blocked-registers>
For assembly authors there are several caveats and differences that need to be considered, I've provided documentation for this as part of the "Standard Library Support" PR: <https://github.com/rust-lang/rust/pull/123144/files#diff-6b08532480943c8b82f5dbda7ee1521afa74c9f626466aeb308dfa6956397edd>
r? rust-lang/compiler
|
|
Rework ptr-to-ref conversion suggestion for method calls
If we have a value `z` of type `*const u8` and try to call `z.to_string()`, the upstream compiler will show you a note suggesting to call `<*const u8>::as_ref` first.
This PR extends that:
- The note will only be shown when the method would exist on the corresponding reference type
- It can now suggest any of `<*const u8>::as_ref`, `<*mut u8>::as_ref` and `<*mut u8>::as_mut`, depending on what the method needs.
I didn't introduce a `help` message because that's not a good idea with `unsafe` functions (and you'd also need to unwrap the `Option<&_>` somehow).
People should check the safety requirements.
For the simplest case
```rust
fn main() {
let x = 8u8;
let z: *const u8 = &x;
// issue #21596
println!("{}", z.to_string()); //~ ERROR E0599
}
```
the output changes like this:
```diff
error[E0599]: `*const u8` doesn't implement `std::fmt::Display`
--> $DIR/suggest-convert-ptr-to-ref.rs:5:22
|
LL | println!("{}", z.to_string());
| ^^^^^^^^^ `*const u8` cannot be formatted with the default formatter
|
- = note: try using `<*const T>::as_ref()` to get a reference to the type behind the pointer: https://doc.rust-lang.org/std/primitive.pointer.html#method.as_ref
- = note: using `<*const T>::as_ref()` on a pointer which is unaligned or points to invalid or uninitialized memory is undefined behavior
+note: the method `to_string` exists on the type `&u8`
+ --> $SRC_DIR/alloc/src/string.rs:LL:COL
+ = note: try using the unsafe method `<*const T>::as_ref` to get an optional reference to the value behind the pointer: https://doc.rust-lang.org/std/primitive.pointer.html#method.as_ref
= note: the following trait bounds were not satisfied:
`*const u8: std::fmt::Display`
which is required by `*const u8: ToString`
```
I removed the separate note about the safety requirements because it was incomplete and the linked doc page already has the information you need.
Fixes #83695, but that's more of a side effect. The upstream compiler already suggests the right method name here.
|
|
When the build is configured with `[rust] rpath = false`, we need to set
`LD_LIBRARY_PATH` (or equivalent) to what would have been the `RPATH`,
so the compiler can find its own libraries. The old `tools.mk` code has
this environment prefixed in the `$(BARE_RUSTC)` variable, so we just
need to wire up something similar for run-make v2.
This is now set while building each `rmake.rs` itself, as well as in the
`rust-make-support` helpers for `rustc` and `rustdoc` commands. This is
also available in a `set_host_rpath` function for manual commands, like
in the `compiler-builtins` test.
|
|
Do not accept the following
```rust
macro_rules! lexes {($($_:tt)*) => {}}
lexes!(🐛"foo");
```
Before, invalid emoji identifiers were gated during parsing instead of lexing in all cases, but this didn't account for macro expansion of literal prefixes.
Fix #123696.
|
|
|
|
|
|
|
|
|
|
|
|
rustdoc: reduce per-page HTML overhead
r? `@GuillaumeGomez`
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
It's been 7 months since we deprecated this. It should be fine to remove it now.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
According to <https://caniuse.com/?search=svg%20favicon>,
SVG favicons are supported in everything but Safari.
When I actually try it in Safari, it's downloading all
three favicons, and nothing looks different when I disable
the 16x16 one.
<https://dev.to/masakudamatsu/favicon-nightmare-how-to-maintain-sanity-3al7>,
which is linked from caniuse above, recommends an ico.
However, the reason they recommend it is the apps that
only support /favicon.ico exactly, and rustdoc can't assume
it will be installed to the site root, so it's unfortunately
up to the webmaster to make sure it's set up.
|
|
This cuts the HTML overhead for a page by about 1KiB,
significantly reducing the overall size of the docs bundle.
|
