| 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
|
|
FusedIterator is a marker trait that promises that the implementing
iterator continues to return `None` from `.next()` once it has returned
`None` once (and/or `.next_back()`, if implemented).
The effects of FusedIterator are already widely available through
`.fuse()`, but with stable `FusedIterator`, stable Rust users can
implement this trait for their iterators when appropriate.
|
|
Add regression test for #48551
[Issue link](https://github.com/rust-lang/rust/issues/48551)
|
|
Stabilize LocalKey::try_with
The `LocalKey::try_with` method is now stabilized.
`LocalKey::state` and `LocalKeyState` marked as deprecated. Although, is there any reason to keep them - should we perhaps remove them completely?
Closes #27716
r? @alexcrichton
|
|
etaoins:fix-find-width-of-character-at-span-bounds-check, r=estebank
Fix find_width_of_character_at_span bounds check
Commit 0bd96671f0 added bounds checking of our current target byte position to prevent infinite loops. Unfortunately it was comparing the file-relative `target` versus the global `file_start_pos` and `file_end_pos`.
The result is failing to detect multibyte characters unless their file-relative offset fit within their global offset. This causes other parts of the compiler to generate spans pointing to the middle of a
multibyte character which will ultimately panic in `bytepos_to_file_charpos`.
Fix by comparing the `target` to the total file size when moving forward and doing checked subtraction when moving backwards. This should preserve the intent of the bounds check while removing the offset confusion.
cc @davidtwco
Fixes #48508
|
|
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
|
|
r=nikomatsakis
[Underspecified semantics] Type check defaults at declaration.
Fixes #46669. See the test for code that compiles on stable but will no longer compile. This falls under a "Underspecified language semantics" fix. **Needs crater**.
On type and trait declarations, we currently allow anything that name checks as a type parameter default. That allows the user to write a default that can never be applied, or even a default that may conditionally be applied depending on the type of another parameter. Mostly this just defers the error to use sites, but also allows clever hacks such as `Foo<T, U = <T as Iterator>::Item>` where `U` will be able to apply it's default only when `T: Iterator`. Maybe that means this bug is a feature, but it's a fiddly behaviour that seems undesirable.
This PR validates defaults at declaration sites by ensuring all predicates on the parameter are valid for the default. With the exception of `Self: Sized` which we don't want to check to allow things like `trait Add<RHS = Self>`.
|
|
|
|
The out-of-line module #37195
|
|
|
|
Fixes #47311.
r? @nrc
|
|
Improve recovery for trailing comma after `..`
|
|
|
|
|
|
|
|
|
|
This is the most conservative possible and should be always correct.
|
|
|
|
|
|
Given a trait predicate, if all params appearing in the LHS have
defaults then it should be a backwards compatible predicate. We verify
that by checking the WF of predicate with all defaults substituted
simultaneously.
|
|
|
|
And refactor duplicated code.
|
|
|
|
|
|
Ensure main() always has external linkage
This ensures that the entry function is never elided due to inlining, even with `inline(always)`. Fixes #47783.
There were a couple of possible ways of addressing this issue; I simply picked the one that seemed most direct. A warning could be appropriate, but considering using inlining hints in other places it doesn't apply also throws no warnings, and it seems like an edge case anyway, I haven't added one for now.
|
|
Restrict the Termination impls to simplify stabilization
Make a minimal commitment in preparation for stabilization. More impls, or broader ones, are likely in future, but are not necessary at this time and are more controversial.
cc https://github.com/rust-lang/rust/issues/48453#issuecomment-368155082
r? @nikomatsakis
|
|
Comprehensively support trailing commas in std/core macros
I carefully organized the changes into four commits:
* Test cases
* Fixes for `macro_rules!` macros
* Fixes for builtin macros
* Docs for builtins
**I can easily scale this back to just the first two commits for now if such is desired.**
### Breaking (?) changes
* This fixes #48042, which is a breaking change that I hope people can agree is just a bugfix for an extremely dark corner case.
* To fix five of the builtins, this changes `syntax::ext::base::get_single_str_from_tts` to accept a trailing comma, and revises the documentation so that this aspect is not surprising. **I made this change under the (hopefully correct) understanding that `libsyntax` is private rustc implementation detail.** After reviewing all call sites (which were, you guessed it, *precisely those five macros*), I believe the revised semantics are closer to the intended spirit of the function.
### Changes which may require concensus
Up until now, it could be argued that some or all the following macros did not conceptually take a comma-separated list, because they only took one argument:
* **`cfg(unix,)`** (most notable since cfg! is unique in taking a meta tag)
* **`include{,_bytes,_str}("file.rs",)`** (in item form this might be written as "`include!{"file.rs",}`" which is even slightly more odd)
* **`compile_error("message",);`**
* **`option_env!("PATH",)`**
* **`try!(Ok(()),)`**
So I think these particular changes may require some sort of consensus. **All of the fixes for builtins are included this list, so if we want to defer these decisions to later then I can scale this PR back to just the first two commits.**
### Other notes/general requests for comment
* Do we have a big checklist somewhere of "things to do when adding macros?" My hope is for `run-pass/macro-comma-support.rs` to remain comprehensive.
* Originally I wanted the tests to also comprehensively forbid double trailing commas. However, this didn't work out too well: [see this gist and the giant FIXME in it](https://gist.github.com/ExpHP/6fc40e82f3d73267c4e590a9a94966f1#file-compile-fail_macro-comma-support-rs-L33-L50)
* I did not touch `select!`. It appears to me to be a complete mess, and its trailing comma mishaps are only the tip of the iceberg.
* There are [some compile-fail test cases](https://github.com/ExpHP/rust/blob/5fa97c35da2f0ee/src/test/compile-fail/macro-comma-behavior.rs#L49-L52) that didn't seem to work (rustc emits errors, but compile-fail doesn't acknowledge them), so they are disabled. Any clues? (Possibly related: These happen to be precisely the set of errors which are tagged by rustc as "this error originates in a macro outside of the current crate".)
---
Fixes #48042
Closes #46241
|
|
|
|
macros: improve struct constructor field hygiene, fix span bug
Fixes #47311.
r? @nrc
|
|
This is named for the issue as it's testing the specific details of that
bug. It's a bit tricky as the ICE requires multiple files and debug info
enabled to trigger.
|
|
This ensures that the entry function is never elided due to inlining, even with `inline(always)`. Fixes #47783.
There were a couple of possible ways of addressing this issue; I simply picked the one that seemed most direct. A warning could be appropriate, but considering using inlining hints in other places it doesn't apply also throws no warnings, and it seems like an edge case anyway, I haven't added one for now.
|
|
Make a minimal commitment for stabilization. More impls are likely in future, but are not necessary at this time.
|
|
|
|
include! and the pretty test do not mix
|
|
Implement multiple patterns with `|` in `if let` and `while let` (RFC 2175)
cc https://github.com/rust-lang/rust/issues/48215
|
|
Allow parentheses in `dyn (Trait)`
r? @eddyb @nikomatsakis
|
|
r=cramertj
reset default binding mode when we pass through a `&` pattern
Fixes #46688.
r? @cramertj
|
|
Fix parsing of extern paths in types and poly-traits
Fixes https://github.com/rust-lang/rust/issues/48262
|
|
Allow two-phase borrows of &mut self in ops
We need two-phase borrows of ops to be in the initial NLL release since without them lots of existing code will break. Fixes #48129.
CC @pnkfelix and @nikomatsakis
r? @pnkfelix
|
|
Termination trait in tests
Support the `Termination` trait in unit tests (cc https://github.com/rust-lang/rust/issues/43301)
Also, a drive-by fix for #47075.
This is joint work with @bkchr.
|
|
Error on nested impl Trait and path projections from impl Trait
cc #34511
r? @nikomatsakis
|
|
|
|
|
|
jseyfried:improve_tuple_struct_field_access_hygiene, r=petrochenkov
Improve tuple struct field access hygiene
Fixes #47312 by fixing a span bug.
r? @nrc
|
|
Fix nested impl trait lifetimes
Fixes #46464
cc https://github.com/rust-lang/rust/issues/34511
r? @nikomatsakis
|
|
|
|
src/rfc-1937-termination-trait/termination-trait-for-result-box-error_ok.rs
|
|
Fixes #46688.
|
|
|
