Commit Graph

224 Commits

Author SHA1 Message Date
Alex Crichton
482a3d06c3 rustc: Add a new wasm ABI
This commit implements the idea of a new ABI for the WebAssembly target,
one called `"wasm"`. This ABI is entirely of my own invention
and has no current precedent, but I think that the addition of this ABI
might help solve a number of issues with the WebAssembly targets.

When `wasm32-unknown-unknown` was first added to Rust I naively
"implemented an abi" for the target. I then went to write `wasm-bindgen`
which accidentally relied on details of this ABI. Turns out the ABI
definition didn't match C, which is causing issues for C/Rust interop.
Currently the compiler has a "wasm32 bindgen compat" ABI which is the
original implementation I added, and it's purely there for, well,
`wasm-bindgen`.

Another issue with the WebAssembly target is that it's not clear to me
when and if the default C ABI will change to account for WebAssembly's
multi-value feature (a feature that allows functions to return multiple
values). Even if this does happen, though, it seems like the C ABI will
be guided based on the performance of WebAssembly code and will likely
not match even what the current wasm-bindgen-compat ABI is today. This
leaves a hole in Rust's expressivity in binding WebAssembly where given
a particular import type, Rust may not be able to import that signature
with an updated C ABI for multi-value.

To fix these issues I had the idea of a new ABI for WebAssembly, one
called `wasm`. The definition of this ABI is "what you write
maps straight to wasm". The goal here is that whatever you write down in
the parameter list or in the return values goes straight into the
function's signature in the WebAssembly file. This special ABI is for
intentionally matching the ABI of an imported function from the
environment or exporting a function with the right signature.

With the addition of a new ABI, this enables rustc to:

* Eventually remove the "wasm-bindgen compat hack". Once this
  ABI is stable wasm-bindgen can switch to using it everywhere.
  Afterwards the wasm32-unknown-unknown target can have its default ABI
  updated to match C.

* Expose the ability to precisely match an ABI signature for a
  WebAssembly function, regardless of what the C ABI that clang chooses
  turns out to be.

* Continue to evolve the definition of the default C ABI to match what
  clang does on all targets, since the purpose of that ABI will be
  explicitly matching C rather than generating particular function
  imports/exports.

Naturally this is implemented as an unstable feature initially, but it
would be nice for this to get stabilized (if it works) in the near-ish
future to remove the wasm32-unknown-unknown incompatibility with the C
ABI. Doing this, however, requires the feature to be on stable because
wasm-bindgen works with stable Rust.
2021-04-08 08:03:18 -07:00
Simonas Kazlauskas
54dc7cebce Remove the insta-stable cfg(wasm)
The addition of `cfg(wasm)` was an oversight on my end that has a number
of downsides:

* It was introduced as an insta-stable addition, forgoing the usual
  staging mechanism we use for potentially far-reaching changes;
* It is a breaking change for people who are using `--cfg wasm` either
  directly or via cargo for other purposes;
* It is not entirely clear if a bare `wasm` cfg is a right option or
  whether `wasm` family of targets are special enough to warrant
  special-casing these targets specifically.

As for the last point, there appears to be a fair amount of support for
reducing the boilerplate in specifying architectures from the same
family, while ignoring their pointer width. The suggested way forward
would be to propose such a change as a separate RFC as it is potentially
a quite contentious addition.
2021-04-07 23:09:56 +03:00
bors
a6e7a5aa5d Auto merge of #81234 - repnop:fn-alignment, r=lcnr
Allow specifying alignment for functions

Fixes #75072

This allows the user to specify alignment for functions, which can be useful for low level work where functions need to necessarily be aligned to a specific value.

I believe the error cases not covered in the match are caught earlier based on my testing so I had them just return `None`.
2021-04-06 04:35:26 +00:00
Wesley Norris
448d07683a Allow specifying alignment for functions 2021-04-05 17:36:51 -04:00
Dylan DPC
0d12422f2d
Rollup merge of #80525 - devsnek:wasm64, r=nagisa
wasm64 support

There is still some upstream llvm work needed before this can land.
2021-04-05 00:24:23 +02:00
Gus Caplan
da66a31572
wasm64 2021-04-04 11:29:34 -05:00
bors
5662d9343f Auto merge of #80965 - camelid:rename-doc-spotlight, r=jyn514
Rename `#[doc(spotlight)]` to `#[doc(notable_trait)]`

Fixes #80936.

"spotlight" is not a very specific or self-explaining name.
Additionally, the dialog that it triggers is called "Notable traits".
So, "notable trait" is a better name.

* Rename `#[doc(spotlight)]` to `#[doc(notable_trait)]`
* Rename `#![feature(doc_spotlight)]` to `#![feature(doc_notable_trait)]`
* Update documentation
* Improve documentation

r? `@Manishearth`
2021-04-02 07:04:58 +00:00
Joshua Nelson
441dc3640a Remove (lots of) dead code
Found with https://github.com/est31/warnalyzer.

Dubious changes:
- Is anyone else using rustc_apfloat? I feel weird completely deleting
  x87 support.
- Maybe some of the dead code in rustc_data_structures, in case someone
  wants to use it in the future?
- Don't change rustc_serialize

  I plan to scrap most of the json module in the near future (see
  https://github.com/rust-lang/compiler-team/issues/418) and fixing the
  tests needed more work than I expected.

TODO: check if any of the comments on the deleted code should be kept.
2021-03-27 22:16:33 -04:00
Josh Stone
72ebebe474 Use iter::zip in compiler/ 2021-03-26 09:32:31 -07:00
kadmin
e4e5db4e42 Add has_default to GenericParamDefKind::Const
This currently creates a field which is always false on GenericParamDefKind for future use when
consts are permitted to have defaults

Update const_generics:default locations

Previously just ignored them, now actually do something about them.

Fix using type check instead of value

Add parsing

This adds all the necessary changes to lower const-generics defaults from parsing.

Change P<Expr> to AnonConst

This matches the arguments passed to instantiations of const generics, and makes it specific to
just anonymous constants.

Attempt to fix lowering bugs
2021-03-23 17:16:20 +00:00
mark
8c4b3dbb50 rename :pat2018 -> :pat215 2021-03-22 12:40:23 -05:00
bors
41b315a470 Auto merge of #83271 - SparrowLii:simd_neg, r=Amanieu
Add simd_neg platform intrinsic

Stdarch needs to add simd_neg to support the implementation of vneg neon instructions. Look [here](https://github.com/rust-lang/stdarch/pull/1087)
2021-03-20 09:01:35 +00:00
Dylan DPC
37b7031078
Rollup merge of #83197 - jyn514:cfg-test-dead-code, r=joshtriplett
Move some test-only code to test files

Split out from https://github.com/rust-lang/rust/pull/83185.
2021-03-19 15:03:24 +01:00
SparrowLii
0fa158b38f Add simd_neg platform intrinsic 2021-03-19 02:16:21 +08:00
Mara Bos
cfb4ad4f2a Remove unwrap_none/expect_none from compiler/. 2021-03-18 14:25:54 +01:00
Joshua Nelson
620ecc01a2 Move some test-only code to test files
This also relaxes the bounds on some structs and moves them to the impl
block instead.
2021-03-17 10:31:30 -04:00
Camelid
34c6cee397 Rename #[doc(spotlight)] to #[doc(notable_trait)]
"spotlight" is not a very specific or self-explaining name.
Additionally, the dialog that it triggers is called "Notable traits".
So, "notable trait" is a better name.

* Rename `#[doc(spotlight)]` to `#[doc(notable_trait)]`
* Rename `#![feature(doc_spotlight)]` to `#![feature(doc_notable_trait)]`
* Update documentation
* Improve documentation
2021-03-15 13:59:54 -07:00
Oli Scherer
1f7df1956a Replace type_alias_impl_trait by min_type_alias_impl_trait with no actual changes in behaviour
This makes `type_alias_impl_trait` not actually do anything anymore
2021-03-15 17:32:43 +00:00
Vadim Petrochenkov
a4cc3cae04 expand: Resolve and expand inner attributes on out-of-line modules 2021-03-14 18:10:29 +03:00
bors
acca818928 Auto merge of #83064 - cjgillot:fhash, r=jackh726
Tweaks to stable hashing
2021-03-13 20:21:40 +00:00
Camille GILLOT
34e92bbf65 Hash SyntaxContext first. 2021-03-11 12:31:31 +01:00
Camille GILLOT
fe2d728e62 Remove useless method. 2021-03-11 12:24:58 +01:00
bors
f98721f886 Auto merge of #82982 - Dylan-DPC:rollup-mt497z7, r=Dylan-DPC
Rollup of 9 pull requests

Successful merges:

 - #81309 (always eagerly eval consts in Relate)
 - #82217 (Edition-specific preludes)
 - #82807 (rustdoc: Remove redundant enableSearchInput function)
 - #82924 (WASI: Switch to crt1-command.o to enable support for new-style commands)
 - #82949 (Do not attempt to unlock envlock in child process after a fork.)
 - #82955 (fix: wrong word)
 - #82962 (Treat header as first paragraph for shortened markdown descriptions)
 - #82976 (fix error message for copy(_nonoverlapping) overflow)
 - #82977 (Rename `Option::get_or_default` to `get_or_insert_default`)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-03-10 19:12:53 +00:00
Dylan DPC
b9a2570c9b
Rollup merge of #82955 - ltoddy:fix/wrong, r=jonas-schievink
fix: wrong word
2021-03-10 17:55:44 +01:00
Dylan DPC
759204ffc4
Rollup merge of #82217 - m-ou-se:edition-prelude, r=nikomatsakis
Edition-specific preludes

This changes `{std,core}::prelude` to export edition-specific preludes under `rust_2015`, `rust_2018` and `rust_2021`. (As suggested in https://github.com/rust-lang/rust/issues/51418#issuecomment-395630382.) For now they all just re-export `v1::*`, but this allows us to add things to the 2021edition prelude soon.

This also changes the compiler to make the automatically injected prelude import dependent on the selected edition.

cc `@rust-lang/libs` `@djc`
2021-03-10 17:55:38 +01:00
ltoddy
37543ce656 fix: wrong word 2021-03-10 09:09:37 +08:00
katelyn a. martin
df45c579de rustc_target: add "unwind" payloads to Abi
### Overview

    This commit begins the implementation work for RFC 2945. For more
    information, see the rendered RFC [1] and tracking issue [2].

    A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`,
    and `Thiscall` variants, marking whether unwinding across FFI
    boundaries is acceptable. The cases where each of these variants'
    `unwind` member is true correspond with the `C-unwind`,
    `system-unwind`, `stdcall-unwind`, and `thiscall-unwind` ABI strings
    introduced in RFC 2945 [3].

 ### Feature Gate and Unstable Book

    This commit adds a `c_unwind` feature gate for the new ABI strings.
    Tests for this feature gate are included in `src/test/ui/c-unwind/`,
    which ensure that this feature gate works correctly for each of the
    new ABIs.

    A new language features entry in the unstable book is added as well.

 ### Further Work To Be Done

    This commit does not proceed to implement the new unwinding ABIs,
    and is intentionally scoped specifically to *defining* the ABIs and
    their feature flag.

 ### One Note on Test Churn

    This will lead to some test churn, in re-blessing hash tests, as the
    deleted comment in `src/librustc_target/spec/abi.rs` mentioned,
    because we can no longer guarantee the ordering of the `Abi`
    variants.

    While this is a downside, this decision was made bearing in mind
    that RFC 2945 states the following, in the "Other `unwind` Strings"
    section [3]:

    >  More unwind variants of existing ABI strings may be introduced,
    >  with the same semantics, without an additional RFC.

    Adding a new variant for each of these cases, rather than specifying
    a payload for a given ABI, would quickly become untenable, and make
    working with the `Abi` enum prone to mistakes.

    This approach encodes the unwinding information *into* a given ABI,
    to account for the future possibility of other `-unwind` ABI
    strings.

 ### Ignore Directives

    `ignore-*` directives are used in two of our `*-unwind` ABI test
    cases.

    Specifically, the `stdcall-unwind` and `thiscall-unwind` test cases
    ignore architectures that do not support `stdcall` and
    `thiscall`, respectively.

    These directives are cribbed from
    `src/test/ui/c-variadic/variadic-ffi-1.rs` for `stdcall`, and
    `src/test/ui/extern/extern-thiscall.rs` for `thiscall`.

    This would otherwise fail on some targets, see:
    fcf697f902

 ### Footnotes

[1]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
[2]: https://github.com/rust-lang/rust/issues/74990
[3]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md#other-unwind-abi-strings
2021-03-09 14:38:29 -05:00
Dylan DPC
9c310571a8
Rollup merge of #82682 - petrochenkov:cfgeval, r=Aaron1011
Implement built-in attribute macro `#[cfg_eval]` + some refactoring

This PR implements a built-in attribute macro `#[cfg_eval]` as it was suggested in https://github.com/rust-lang/rust/pull/79078 to avoid `#[derive()]` without arguments being abused as a way to configure input for other attributes.

The macro is used for eagerly expanding all `#[cfg]` and `#[cfg_attr]` attributes in its input ("fully configuring" the input).
The effect is identical to effect of `#[derive(Foo, Bar)]` which also fully configures its input before passing it to macros `Foo` and `Bar`, but unlike `#[derive]` `#[cfg_eval]` can be applied to any syntax nodes supporting macro attributes, not only certain items.

`cfg_eval` was the first name suggested in https://github.com/rust-lang/rust/pull/79078, but other alternatives are also possible, e.g. `cfg_expand`.

```rust
#[cfg_eval]
#[my_attr] // Receives `struct S {}` as input, the field is configured away by `#[cfg_eval]`
struct S {
    #[cfg(FALSE)]
    field: u8,
}
```

Tracking issue: https://github.com/rust-lang/rust/issues/82679
2021-03-08 13:13:23 +01:00
bors
76c500ec6c Auto merge of #81635 - michaelwoerister:structured_def_path_hash, r=pnkfelix
Let a portion of DefPathHash uniquely identify the DefPath's crate.

This allows to directly map from a `DefPathHash` to the crate it originates from, without constructing side tables to do that mapping -- something that is useful for incremental compilation where we deal with `DefPathHash` instead of `DefId` a lot.

It also allows to reliably and cheaply check for `DefPathHash` collisions which allows the compiler to gracefully abort compilation instead of running into a subsequent ICE at some random place in the code.

The following new piece of documentation describes the most interesting aspects of the changes:

```rust
/// A `DefPathHash` is a fixed-size representation of a `DefPath` that is
/// stable across crate and compilation session boundaries. It consists of two
/// separate 64-bit hashes. The first uniquely identifies the crate this
/// `DefPathHash` originates from (see [StableCrateId]), and the second
/// uniquely identifies the corresponding `DefPath` within that crate. Together
/// they form a unique identifier within an entire crate graph.
///
/// There is a very small chance of hash collisions, which would mean that two
/// different `DefPath`s map to the same `DefPathHash`. Proceeding compilation
/// with such a hash collision would very probably lead to an ICE and, in the
/// worst case, to a silent mis-compilation. The compiler therefore actively
/// and exhaustively checks for such hash collisions and aborts compilation if
/// it finds one.
///
/// `DefPathHash` uses 64-bit hashes for both the crate-id part and the
/// crate-internal part, even though it is likely that there are many more
/// `LocalDefId`s in a single crate than there are individual crates in a crate
/// graph. Since we use the same number of bits in both cases, the collision
/// probability for the crate-local part will be quite a bit higher (though
/// still very small).
///
/// This imbalance is not by accident: A hash collision in the
/// crate-local part of a `DefPathHash` will be detected and reported while
/// compiling the crate in question. Such a collision does not depend on
/// outside factors and can be easily fixed by the crate maintainer (e.g. by
/// renaming the item in question or by bumping the crate version in a harmless
/// way).
///
/// A collision between crate-id hashes on the other hand is harder to fix
/// because it depends on the set of crates in the entire crate graph of a
/// compilation session. Again, using the same crate with a different version
/// number would fix the issue with a high probability -- but that might be
/// easier said then done if the crates in questions are dependencies of
/// third-party crates.
///
/// That being said, given a high quality hash function, the collision
/// probabilities in question are very small. For example, for a big crate like
/// `rustc_middle` (with ~50000 `LocalDefId`s as of the time of writing) there
/// is a probability of roughly 1 in 14,750,000,000 of a crate-internal
/// collision occurring. For a big crate graph with 1000 crates in it, there is
/// a probability of 1 in 36,890,000,000,000 of a `StableCrateId` collision.
```

Given the probabilities involved I hope that no one will ever actually see the error messages. Nonetheless, I'd be glad about some feedback on how to improve them. Should we create a GH issue describing the problem and possible solutions to point to? Or a page in the rustc book?

r? `@pnkfelix` (feel free to re-assign)
2021-03-07 23:45:57 +00:00
Vadim Petrochenkov
5dad6c2575 Implement built-in attribute macro #[cfg_eval] 2021-03-06 23:03:19 +03:00
Mara
2cd1f79aa1
Rollup merge of #82773 - mgacek8:feature/add_diagnostic_item_to_Default_trait, r=oli-obk
Add diagnostic item to `Default` trait

This PR adds diagnostic item to `Default` trait to be used by rust-lang/rust-clippy#6562 issue.
Also fixes the obsolete path to the `symbols.rs` file in the comment.
2021-03-05 10:57:24 +01:00
Mara
e6a6df5daa
Rollup merge of #80723 - rylev:noop-lint-pass, r=estebank
Implement NOOP_METHOD_CALL lint

Implements the beginnings of https://github.com/rust-lang/lang-team/issues/67 - a lint for detecting noop method calls (e.g, calling `<&T as Clone>::clone()` when `T: !Clone`).

This PR does not fully realize the vision and has a few limitations that need to be addressed either before merging or in subsequent PRs:
* [ ] No UFCS support
* [ ] The warning message is pretty plain
* [ ] Doesn't work for `ToOwned`

The implementation uses [`Instance::resolve`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/instance/struct.Instance.html#method.resolve) which is normally later in the compiler. It seems that there are some invariants that this function relies on that we try our best to respect. For instance, it expects substitutions to have happened, which haven't yet performed, but we check first for `needs_subst` to ensure we're dealing with a monomorphic type.

Thank you to ```@davidtwco,``` ```@Aaron1011,``` and ```@wesleywiser``` for helping me at various points through out this PR ❤️.
2021-03-05 10:57:14 +01:00
Mateusz Gacek
58d6f80f96 Fix comment with path to symbols! macro 2021-03-04 10:14:56 -08:00
Yuki Okushi
f898aa3f5b
Rollup merge of #80527 - jyn514:rustdoc-lints, r=GuillaumeGomez
Make rustdoc lints a tool lint instead of built-in

- Rename `broken_intra_doc_links` to `rustdoc::broken_intra_doc_links` (and similar for other rustdoc lints; I don't expect any others to be used frequently, though).
- Ensure that the old lint names still work and give deprecation errors
- Register lints even when running doctests
- Move lint machinery into a separate file
- Add `declare_rustdoc_lint!` macro

Unblocks https://github.com/rust-lang/rust/pull/80300, https://github.com/rust-lang/rust/pull/79816, https://github.com/rust-lang/rust/pull/80965. Makes the strangeness in https://github.com/rust-lang/rust/pull/77364 more apparent to the end user (note that `missing_docs` is *not* moved to rustdoc in this PR). Closes https://github.com/rust-lang/rust/issues/78786.

## Current status

This is blocked on #82620 (see https://github.com/rust-lang/rust/pull/80527#issuecomment-787401519)
2021-03-04 20:01:01 +09:00
Ryan Levick
1999a3147f Fix borrow and deref 2021-03-03 11:23:29 +01:00
Ryan Levick
da3995f0ec Remove lint pass on borrow and deref 2021-03-03 11:23:14 +01:00
Ryan Levick
a6d926d80d Fix tests 2021-03-03 11:22:44 +01:00
Ryan Levick
f49ed7a6b7 Add tests and support two more noop methods 2021-03-03 11:22:17 +01:00
Ryan Levick
040735c110 First version of noop-lint 2021-03-03 11:22:16 +01:00
Yuki Okushi
5e68c60406
Rollup merge of #82516 - PoignardAzur:inherent-impl-ty, r=oli-obk
Add incomplete feature gate for inherent associate types.

Mentored by ``````@oli-obk``````

So far the only change is that instead of giving an automatic error, the following code compiles:

```rust
struct Foo;

impl Foo {
    type Bar = isize;
}
```

The backend work to make it actually usable isn't there yet. In particular, this:

```rust
let x : Foo::Bar;
```

will give you:

```sh
error[E0223]: ambiguous associated type
  --> /$RUSTC_DIR/src/test/ui/assoc-inherent.rs:15:13
   |
LL |     let x : Foo::Bar;
   |             ^^^^^^^^ help: use fully-qualified syntax: `<Foo as Trait>::Bar`
```
2021-03-02 21:23:15 +09:00
Joshua Nelson
cc62018e61 Rename rustdoc lints to be a tool lint instead of built-in.
- Rename `broken_intra_doc_links` to `rustdoc::broken_intra_doc_links`
- Ensure that the old lint names still work and give deprecation errors
- Register lints even when running doctests

  Otherwise, all `rustdoc::` lints would be ignored.

- Register all existing lints as removed

  This unfortunately doesn't work with `register_renamed` because tool
  lints have not yet been registered when rustc is running. For similar
  reasons, `check_backwards_compat` doesn't work either. Call
  `register_removed` directly instead.

- Fix fallout

  + Rustdoc lints for compiler/
  + Rustdoc lints for library/

Note that this does *not* suggest `rustdoc::broken_intra_doc_links` for
`rustdoc::intra_doc_link_resolution_failure`, since there was no time
when the latter was valid.
2021-03-01 19:29:15 -05:00
Cameron Steffen
6a3b834b39 Use diagnostic items in into_iter_collections 2021-03-01 09:04:11 -06:00
Cameron Steffen
eada4d1c45 Add diagnostic items 2021-03-01 09:04:11 -06:00
Cameron Steffen
4a6e67ead7 Add missing diagnostic item Symbols 2021-02-26 22:12:36 -06:00
Guillaume Gomez
0db8349fff
Rollup merge of #81940 - jhpratt:stabilize-str_split_once, r=m-ou-se
Stabilize str_split_once

Closes #74773
2021-02-26 15:52:29 +01:00
bors
98f8cce6db Auto merge of #82447 - Amanieu:legacy_const_generics, r=oli-obk
Add #[rustc_legacy_const_generics]

This is the first step towards removing `#[rustc_args_required_const]`: a new attribute is added which rewrites function calls of the form `func(a, b, c)` to `func::<{b}>(a, c)`. This allows previously stabilized functions in `stdarch` which use `rustc_args_required_const` to use const generics instead.

This new attribute is not intended to ever be stabilized, it is only intended for use in `stdarch` as a replacement for `#[rustc_args_required_const]`.

```rust
#[rustc_legacy_const_generics(1)]
pub fn foo<const Y: usize>(x: usize, z: usize) -> [usize; 3] {
    [x, Y, z]
}

fn main() {
    assert_eq!(foo(0 + 0, 1 + 1, 2 + 2), [0, 2, 4]);
    assert_eq!(foo::<{1 + 1}>(0 + 0, 2 + 2), [0, 2, 4]);
}
```

r? `@oli-obk`
2021-02-25 18:14:50 +00:00
Olivier FAURE
4f4e15d5eb Add feature gate for inherent associate types. 2021-02-25 14:10:25 +01:00
Mara Bos
d3b564c3d7 Pick the injected prelude based on the edition. 2021-02-25 12:47:58 +01:00
Amanieu d'Antras
d87eec1bf6 Add #[rustc_legacy_const_generics] 2021-02-23 17:25:55 +00:00
Dylan DPC
e2561c58a4
Rollup merge of #82296 - spastorino:pubrules, r=nikomatsakis
Support `pub` on `macro_rules`

This rebases and updates `since` version of #78166 from ``@petrochenkov``

r? ``@nikomatsakis``
2021-02-23 16:10:23 +01:00