Change visibility of Args new function
Currently the Args new function is constrained to pub(super) but this stops me from being able to construct Args structs in unit tests.
This pull request is to change this to pub.
Add documentation for unstable_feature_bound
There is more detail and explanation in https://hackmd.io/``````@tiif/Byd3mq7Ige``````
Original PR that implemented this: rust-lang/rust#140399
r? ``````@BoxyUwU`````` to nominate for types team discussion
Rehome 33 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`
rust-lang/rust#143902 divided into smaller, easier to review chunks.
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that ``@Kivooeo`` was using.
r? ``@jieyouxu``
Preserve the .debug_gdb_scripts section
Make sure that compiler and linker don't optimize the section's contents
away by adding the global holding the data to `llvm.used`. This
eliminates the need for a volatile load in the main shim; since the LLVM
codegen backend is the only implementer of the corresponding trait
function, remove it entirely.
Pretty printers in dylib dependencies are now emitted by the main crate
instead of the dylib; apart from matching how rlibs are handled, this
approach has the advantage that `omit_gdb_pretty_printer_section` keeps
working with dylib dependencies.
r? `@bjorn3`
changelog: [`collapsible_else_if`]: fix suggestion when inner `if` as
wrapped in parentheses
changelog: [`collapsible_if`]: fix suggestion when inner `if` as wrapped
in parentheses
fixes https://github.com/rust-lang/rust-clippy/issues/15303
I'm sure this is a bit dirty, but don't currently see a better way.
Instead of collecting pretty printers transitively when building
executables/staticlibs/cdylibs, let the debugger find each crate's
pretty printers via its .debug_gdb_scripts section. This covers the case
where libraries defining custom pretty printers are loaded dynamically.
This adds
- (ex) for regions whose origin is existential,
- (p) for regoins whose origin is a placeholder, and
- (p for <name>) if the originating placeholder is named.
This has helped _my_ debugging and it doesn't create too bad clutter, I feel.
The change is ridiculously small, but I turned it into a separate PR so we can bikeshed the format.
When I first tried contributing to clippy,
I encountered the problem that a lot of lint suggestions overlapped with
existing lints, so I would spend a bunch of time implementing something
only to figure out it wasn't actually needed.
The "comparison with existing lints" field should hopefully reduce this
somewhat, while not incresing the burden of
requesting a new lint too much due to not being mandatory.
changelog: none
This makes it possible to bless the snapshot files used by `diff()` in
newly-created run-make tests, without having to create the files manually
beforehand.
Currently we run the `rustc` from the `RUSTC` environment variable to
figure out whether or not to enable `f16` and `f128`, based on the
`target_has_reliable_{f16,f128}` config. However, this does not know
about the codegen backend used, and the backend isn't trivial to check
in a build script (usually it gets set via `RUSTFLAGS`).
It turns out we don't actually need to run `rustc` here: Cargo
unconditionally emits all config from the relevant compiler as
`CARGO_CFG_*` variables, regardless of whether or not they are known
options. Switch to checking these for setting config rather than
invoking `rustc`.
As an added advantage, this will work with target.json files without any
special handling.
Fixes: ed17b95715dd ("Use the compiler to determine whether or not to enable `f16` and `f128`")
Simplify dead code lint
This PR scratches a few itches I had when looking at that code.
The perf improvement comes from keeping the `scanned` set through several marking phases. This pretty much divides by 2 the number of HIR traversals.
Create a private module to hold the bootstrap code needed enable LSE
at startup on aarch64-*-linux-* targets when rust implements the
intrinsics.
This is a bit more heavyweight than compiler-rt's LSE initialization,
but has the benefit of initializing the aarch64 cpu feature detection
for other uses.
Using the rust initialization code does use some atomic operations,
that's OK. Mixing LSE and non-LSE operations should work while the
update flag propagates.
Add dynamic support for aarch64 LSE atomic ops on linux targets
when optimized-compiler-builtins is not enabled.
A hook, __enable_rust_lse, is provided for the runtime to enable
them if available. A future patch will use this to enable them
if available.
The resulting asm should exactly match that of LLVM's compiler-rt
builtins, though the symbol naming for the support function and
global does not.
The project build for compiler-rt is deprecated.
The runtimes build will use the just-built clang. As such, we
also need to pass --gcc-toolchain to the runtimes build, so that
it can find the GCC installation.
Jakub Beránek