| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
|
|
Support parentheses in patterns under feature gate
This is a prerequisite for any other extensions to pattern syntax - `|` with multiple patterns, type ascription, `..PAT` in slice patterns.
Closes https://github.com/rust-lang/rfcs/issues/554
|
|
Fixes #47311.
r? @nrc
|
|
Improve recovery for trailing comma after `..`
|
|
Implement multiple patterns with `|` in `if let` and `while let` (RFC 2175)
cc https://github.com/rust-lang/rust/issues/48215
|
|
Error on nested impl Trait and path projections from impl Trait
cc #34511
r? @nikomatsakis
|
|
|
|
update tracking issue for nll
Point to the new tracing issue for nll
For reference https://github.com/rust-lang/rust/issues/44928
|
|
Point to the new tracing issue for nll
|
|
You can now choose between the following:
- `#[unwind(allowed)]`
- `#[unwind(aborts)]`
Per rust-lang/rust#48251, the default is `#[unwind(allowed)]`, though
I think we should change this eventually.
|
|
|
|
Correct a few stability attributes
* `core_float_bits`, `duration_core`, `path_component_asref`, and `repr_align` were stabalized in 1.25.0 not 1.24.0.
* Impls for `NonNull` involving unstable things should remain unstable.
* `Duration` should remain stable since 1.3.0 so it appears correctly in the `std` docs.
* `cursor_mut_vec` is an impl on only stable things so should be marked stable.
|
|
|
|
Implement `?` macro repetition
See rust-lang/rfcs#2298 (with disposition merge)
|
|
|
|
|
|
Unfortunately left out it means that when the `#![feature(proc_macro)]` flag is
in effect it fails to find `rustc_args_required_const` for expansion. This
version, however, is verified to work with stdsimd's requirements!
|
|
|
|
r=petrochenkov
Stabilize feature(match_beginning_vert)
With this feature stabilized, match expressions can optionally have a `|` at the beginning of each arm.
Reference PR: rust-lang-nursery/reference#231
Closes #44101
|
|
|
|
|
|
field only exist in the json if the flag is passed
|
|
don't mention tasks in stability warnings of #[thread_local] #47755
This is a fix for issue #47755.
|
|
This is a fix for issue #47755.
|
|
errors
|
|
|
|
Implement repr(transparent)
r? @eddyb for the functional changes. The bulk of the PR is error messages and docs, might be good to have a doc person look over those.
cc #43036
cc @nox
|
|
|
|
|
|
|
|
|
|
Remove `impl Foo for .. {}` in favor `auto trait Foo {}`
Rebase of https://github.com/rust-lang/rust/pull/46480 with restored parsing support.
|
|
No longer parse it.
Remove AutoTrait variant from AST and HIR.
Remove backwards compatibility lint.
Remove coherence checks, they make no sense for the new syntax.
Remove from rustdoc.
|
|
Remove deprecated unstable attribute #[simd]
The `#[simd]` attribute has been deprecated since c8b6d5b23cc8b2d43ece9f06252c7e98280fb8e5 back in 2015. Any nightly crates using it have had ample time to switch to `#[repr(simd)]`, and if they didn't they're likely broken by now anyway.
r? @eddyb
|
|
r=estebank
type error method suggestions use whitelisted identity-like conversions
Previously, on a type mismatch (and if this wasn't preëmpted by a
higher-priority suggestion), we would look for argumentless methods
returning the expected type, and list them in a `help` note. This had two
major shortcomings: firstly, a lot of the suggestions didn't really make
sense (if you used a &str where a String was expected,
`.to_ascii_uppercase()` is probably not the solution you were hoping
for). Secondly, we weren't generating suggestions from the most useful
traits! We address the first problem with an internal
`#[rustc_conversion_suggestion]` attribute meant to mark methods that keep
the "same value" in the relevant sense, just converting the type. We
address the second problem by making `FnCtxt.probe_for_return_type` pass
the `ProbeScope::AllTraits` to `probe_op`: this would seem to be safe
because grep reveals no other callers of `probe_for_return_type`.
Also, structured suggestions are pretty and good for RLS and friends.
Unfortunately, the trait probing is still not all one would hope for: at a
minimum, we don't know how to rule out `into()` in cases where it wouldn't
actually work, and we don't know how to rule in `.to_owned()` where it
would. Issues #46459 and #46460 have been filed and are ref'd in a FIXME.
This is hoped to resolve #42929, #44672, and #45777.
|
|
The `#[simd]` attribute has been deprecated since c8b6d5b23cc8b2d43ece9f06252c7e98280fb8e5 back in 2015. Any nightly crates using it have had ample time to switch to `#[repr(simd)]`, and if they didn't they're likely broken by now anyway.
|
|
Previously, on a type mismatch (and if this wasn't preëmpted by a
higher-priority suggestion), we would look for argumentless methods
returning the expected type, and list them in a `help` note.
This had two major shortcomings. Firstly, a lot of the suggestions didn't
really make sense (if you used a &str where a String was expected,
`.to_ascii_uppercase()` is probably not the solution you were hoping
for). Secondly, we weren't generating suggestions from the most useful
traits!
We address the first problem with an internal
`#[rustc_conversion_suggestion]` attribute meant to mark methods that keep
the "same value" in the relevant sense, just converting the type. We
address the second problem by making `FnCtxt.probe_for_return_type` pass
the `ProbeScope::AllTraits` to `probe_op`: this would seem to be safe
because grep reveals no other callers of `probe_for_return_type`.
Also, structured suggestions are preferred (because they're pretty, but
also for RLS and friends).
Also also, we make the E0055 autoderef recursion limit error use the
one-time-diagnostics set, because we can potentially hit the limit a lot
during probing. (Without this,
test/ui/did_you_mean/recursion_limit_deref.rs would report "aborting due to
51 errors").
Unfortunately, the trait probing is still not all one would hope for: at a
minimum, we don't know how to rule out `into()` in cases where it wouldn't
actually work, and we don't know how to rule in `.to_owned()` where it
would. Issues #46459 and #46460 have been filed and are ref'd in a FIXME.
This is hoped to resolve #42929, #44672, and #45777.
|
|
|
|
|
|
|
|
|
|
Implements RFC 1937: `?` in `main`
This is the first part of the RFC 1937 that supports new
`Termination` trait in the rust `main` function.
Thanks @nikomatsakis, @arielb1 and all other people in the gitter channel for all your help!
The support for doctest and `#[test]` is still missing, bu as @nikomatsakis said, smaller pull requests are better :)
|
|
Use def span for non-ascii ident feature gate error
|
|
|
|
Add a feature gate for nested uses of `impl Trait`
This allows us to delay stabilization of nested `impl Trait` until we have a plan to solve the problem posed [here](https://github.com/rust-lang/rust/issues/34511#issuecomment-350715858).
r? @nikomatsakis
|
|
|
|
The Generics now contain one Vec of an enum for the generic parameters,
rather than two separate Vec's for lifetime and type parameters.
Additionally, places that previously used Vec<LifetimeDef> now use
Vec<GenericParam> instead.
|
|
Implement non-mod.rs mod statements
Fixes https://github.com/rust-lang/rust/issues/45385, cc https://github.com/rust-lang/rust/issues/44660
This will fail tidy right now because it doesn't recognize my UI tests as feature-gate tests. However, I'm not sure if compile-fail will work out either because compile-fail usually requires there to be error patterns in the top-level file, which isn't possible with this feature. What's the recommended way to handle this?
|
