Commit Graph

141333 Commits

Author SHA1 Message Date
Tom Eccles
980961e330 ci: docker: x86_64: specify host explicitly 2021-03-28 16:50:16 +01:00
Tom Eccles
b2a97ff415 bootstrap: don't run linkcheck when crosscompiling
When we cross compile, some things (and their documentation) are built
for the host (e.g. rustc), while others (and their documentation) are built
for the target. This generated documentation will have broken links
between documentation for different platforms e.g. between rustc and
cargo.
2021-03-28 16:50:16 +01:00
Tom Eccles
8b40dd1f50 ci: docker: riscv64gc: specify host explicitly 2021-03-28 16:50:16 +01:00
Tom Eccles
d9dc5d83e2 run-make: skip issue-36710 on riscv64 and armhf
The test assumes it can run target binaries on the host. This not true
for riscv64 CI (or for other platforms using remote-test-server).
2021-03-28 16:49:58 +01:00
Tom Eccles
a143d6d467 run-make: Specify --target to rustc
Resolves #78911

The target's linker was used but rustc wasn't told to build for that
target (instead defaulting to the host). This led to the host instead of
the target getting tested and to the linker getting inappropriate
arguments.
2021-03-28 16:48:48 +01:00
bors
0239876020 Auto merge of #83582 - jyn514:might-not, r=joshtriplett
may not -> might not

may not -> might not

"may not" has two possible meanings:
1. A command: "You may not stay up past your bedtime."
2. A fact that's only sometimes true: "Some cities may not have bike lanes."

In some cases, the meaning is ambiguous: "Some cars may not have snow
tires." (do the cars *happen* to not have snow tires, or is it
physically impossible for them to have snow tires?)

This changes places where the standard library uses the "description of
fact" meaning to say "might not" instead.

This is just `std::vec` for now - if you think this is a good idea I can
convert the rest of the standard library.
2021-03-28 14:16:03 +00:00
Ralf Jung
1ab05c13dd adjust old test 2021-03-28 14:49:35 +02:00
bors
d4c96de64f Auto merge of #83577 - geeklint:slice_to_ascii_case_doc_links, r=m-ou-se
Adjust documentation links for slice::make_ascii_*case

The documentation for the functions `slice::to_ascii_lowercase` and `slice::to_ascii_uppercase` contain the suggestion

> To lowercase the value in-place, use `make_ascii_lowercase`

however the link to the suggested method takes you to the page for `u8`, rather than the method of that name on the same page.
2021-03-28 11:34:55 +00:00
Ralf Jung
ee1caae33c unaligned_references: align(N) fields in packed(N) structs are fine 2021-03-28 12:54:19 +02:00
Ralf Jung
a515cfd966 update Miri 2021-03-28 11:23:17 +02:00
bors
505ed7fb1b Auto merge of #83593 - petrochenkov:nounwrap, r=nagisa
rustc_target: Avoid unwraps when adding linker flags

These `unwrap`s assume that some linker flags were already added by `*_base::opts()` methods, but that's doesn't necessarily remain the case when we are reducing the number of flags hardcoded in targets, as https://github.com/rust-lang/rust/pull/83587 shows.

r? `@nagisa`
2021-03-28 08:53:51 +00:00
JohnTitor
4a314b9911 Remove unnecessary ignore-cloudabi flag 2021-03-28 15:34:59 +09:00
bors
5208f63ba8 Auto merge of #81728 - Qwaz:fix-80335, r=joshtriplett
Fixes API soundness issue in join()

Fixes #80335
2021-03-28 06:32:34 +00:00
Joshua Nelson
a0957c9d26 Avoid sorting by DefId for necessary_variants() 2021-03-28 01:13:16 -04:00
bors
1df20569dd Auto merge of #81354 - SkiFire13:binary-search-assume, r=nagisa
Instruct LLVM that binary_search returns a valid index

This allows removing bound checks when the return value of `binary_search` is used to index into the slice it was call on. I also added a codegen test for this, not sure if it's the right thing to do (I didn't find anything on the dev guide), but it felt so.
2021-03-28 03:51:22 +00:00
Joshua Nelson
f3523544f1 Address more review comments
- Add back various diagnostic methods on `Session`.

  It seems unfortunate to duplicate these in so many places, but in the
  meantime, making the API inconsistent between `Session` and `Diagnostic`
  also seems unfortunate.

- Add back TyCtxtAt methods

  These will hopefully be used in the near future.

- Add back `with_const`, it would need to be added soon after anyway.
- Add back `split()` and `get_mut()`, they're useful.
2021-03-27 22:19:32 -04:00
Joshua Nelson
230e396a76 Fix compiler docs 2021-03-27 22:16:34 -04:00
Joshua Nelson
de0fda9558 Address review comments
- Add back `HirIdVec`, with a comment that it will soon be used.
- Add back `*_region` functions, with a comment they may soon be used.
- Remove `-Z borrowck_stats` completely. It didn't do anything.
- Remove `make_nop` completely.
- Add back `current_loc`, which is used by an out-of-tree tool.
- Fix style nits
- Remove `AtomicCell` with `cfg(parallel_compiler)` for consistency.
2021-03-27 22:16:34 -04: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
Joshua Nelson
785aeac521 Remove unused DiagnosticBuilder::sub function
`Diagnostic::sub` is only ever used directly; it doesn't need to be
included in the builder.
2021-03-27 22:16:33 -04:00
bors
3bfc85149e Auto merge of #83587 - petrochenkov:asneeded, r=nagisa
linker: Use `--as-needed` by default when linker supports it

Do it in a centralized way in `link.rs` instead of individual target specs.
Majority of relevant target specs were already passing it.
2021-03-28 01:00:25 +00:00
Vadim Petrochenkov
049a49b911 rustc_target: Avoid unwraps when adding linker flags 2021-03-28 02:28:48 +03:00
Vadim Petrochenkov
6615ee89be linker: Use --as-needed by default when linker supports it 2021-03-28 01:49:15 +03:00
bors
8cd7d86ce2 Auto merge of #83103 - petrochenkov:unilex, r=Aaron1011
resolve: Partially unify early and late scope-relative identifier resolution

Reuse `early_resolve_ident_in_lexical_scope` instead of a chunk of code in `resolve_ident_in_lexical_scope` doing the same job.

`early_resolve_ident_in_lexical_scope`/`visit_scopes` had to be slightly extended to be able to 1) start from a specific module instead of the current parent scope and 2) report one deprecation lint.
`early_resolve_ident_in_lexical_scope` still doesn't support walking through "ribs", that part is left in `resolve_ident_in_lexical_scope` (moreover, I'm pretty sure it's buggy, but that's a separate issue, cc https://github.com/rust-lang/rust/issues/52389 at least).
2021-03-27 22:19:17 +00:00
Vadim Petrochenkov
ee0357af3b resolve: Partially unify early and late scope-relative ident resolution 2021-03-27 23:38:17 +03:00
Joshua Nelson
e051db6838 may not -> might not
"may not" has two possible meanings:
1. A command: "You may not stay up past your bedtime."
2. A fact that's only sometimes true: "Some cities may not have bike lanes."

In some cases, the meaning is ambiguous: "Some cars may not have snow
tires." (do the cars *happen* to not have snow tires, or is it
physically impossible for them to have snow tires?)

This changes places where the standard library uses the "description of
fact" meaning to say "might not" instead.

This is just `std::vec` for now - if you think this is a good idea I can
convert the rest of the standard library.
2021-03-27 16:01:16 -04:00
bors
9b0edb7fdd Auto merge of #83580 - Dylan-DPC:rollup-1zod4p7, r=Dylan-DPC
Rollup of 8 pull requests

Successful merges:

 - #81351 (combine: stop eagerly evaluating consts)
 - #82525 (make unaligned_references future-incompat lint warn-by-default)
 - #82626 (update array missing `IntoIterator` msg)
 - #82917 (Add function core::iter::zip)
 - #82993 (rustdoc: Use diagnostics for error when including sources)
 - #83522 (Improve fs error open_from unix)
 - #83548 (Always preserve `None`-delimited groups in a captured `TokenStream`)
 - #83555 (Add #[inline] to io::Error methods)

Failed merges:

 - #83130 (escape_ascii take 2)

r? `@ghost`
`@rustbot` modify labels: rollup
2021-03-27 19:38:01 +00:00
Dylan DPC
7d6af6751c
Rollup merge of #83555 - m-ou-se:inline-io-error-new-const, r=jackh726
Add #[inline] to io::Error methods

Fixes #82812
2021-03-27 20:37:13 +01:00
Dylan DPC
1115accccc
Rollup merge of #83548 - Aaron1011:capture-none-delims, r=petrochenkov
Always preserve `None`-delimited groups in a captured `TokenStream`

Previously, we would silently remove any `None`-delimiters when
capturing a `TokenStream`, 'flattenting' them to their inner tokens.
This was not normally visible, since we usually have
`TokenKind::Interpolated` (which gets converted to a `None`-delimited
group during macro invocation) instead of an actual `None`-delimited
group.

However, there are a couple of cases where this becomes visible to
proc-macros:
1. A cross-crate `macro_rules!` macro has a `None`-delimited group
   stored in its body (as a result of being produced by another
   `macro_rules!` macro). The cross-crate `macro_rules!` invocation
   can then expand to an attribute macro invocation, which needs
   to be able to see the `None`-delimited group.
2. A proc-macro can invoke an attribute proc-macro with its re-collected
   input. If there are any nonterminals present in the input, they will
   get re-collected to `None`-delimited groups, which will then get
   captured as part of the attribute macro invocation.

Both of these cases are incredibly obscure, so there hopefully won't be
any breakage. This change will allow more agressive 'flattenting' of
nonterminals in #82608 without losing `None`-delimited groups.
2021-03-27 20:37:12 +01:00
Dylan DPC
aee7b9e7d6
Rollup merge of #83522 - pickfire:patch-6, r=JohnTitor
Improve fs error open_from unix

Consistency for #79399
Suggested by JohnTitor

r? `@JohnTitor`

Not user if the error is too long now, do we handle long errors well?
2021-03-27 20:37:11 +01:00
Dylan DPC
f665e5a491
Rollup merge of #82993 - camelid:source-use-diag, r=jyn514
rustdoc: Use diagnostics for error when including sources

This error probably almost never happens, but we should still use the
diagnostic infrastructure. My guess is that the error was added back
before rustdoc used the rustc diagnostic infrastructure (it was all
`println!` and `eprintln!` back then!) and since it likely rarely occurs
and this code doesn't change that much, no one thought to transition it
to using diagnostics.

Note that the old error was actually a warning (it didn't stop the rest
of doc building). It seems very unlikely that this would fail without
the rest of the doc build failing, so it makes more sense for it to be a
hard error.

The error looks like this:

    error: failed to render source code for `src/test/rustdoc/smart-punct.rs`: "bar": foo
      --> src/test/rustdoc/smart-punct.rs:3:1
       |
    3  | / #![crate_name = "foo"]
    4  | |
    5  | | //! This is the "start" of the 'document'! How'd you know that "it's" ...
    6  | | //!
    ...  |
    22 | | //! I say "don't smart-punct me -- please!"
    23 | | //! ```
       | |_______^

I wasn't sure how to trigger the error, so to create that message I
temporarily made rustdoc always emit it. That's also why it says "bar"
and "foo" instead of a real error message.

Note that the span of the diagnostic starts at line 3 because line 1 of
that file is a (non-doc) comment and line 2 is a blank line.
2021-03-27 20:37:09 +01:00
Dylan DPC
b2e254318d
Rollup merge of #82917 - cuviper:iter-zip, r=m-ou-se
Add function core::iter::zip

This makes it a little easier to `zip` iterators:

```rust
for (x, y) in zip(xs, ys) {}
// vs.
for (x, y) in xs.into_iter().zip(ys) {}
```

You can `zip(&mut xs, &ys)` for the conventional `iter_mut()` and
`iter()`, respectively. This can also support arbitrary nesting, where
it's easier to see the item layout than with arbitrary `zip` chains:

```rust
for ((x, y), z) in zip(zip(xs, ys), zs) {}
for (x, (y, z)) in zip(xs, zip(ys, zs)) {}
// vs.
for ((x, y), z) in xs.into_iter().zip(ys).zip(xz) {}
for (x, (y, z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {}
```

It may also format more nicely, especially when the first iterator is a
longer chain of methods -- for example:

```rust
    iter::zip(
        trait_ref.substs.types().skip(1),
        impl_trait_ref.substs.types().skip(1),
    )
    // vs.
    trait_ref
        .substs
        .types()
        .skip(1)
        .zip(impl_trait_ref.substs.types().skip(1))
```

This replaces the tuple-pair `IntoIterator` in #78204.
There is prior art for the utility of this in [`itertools::zip`].

[`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html
2021-03-27 20:37:07 +01:00
Dylan DPC
ebea9d948f
Rollup merge of #82626 - lcnr:encode_with_shorthandb, r=estebank
update array missing `IntoIterator` msg

fixes #82602

r? ```@estebank``` do you know whether we can use the expr span in `rustc_on_unimplemented`? The label isn't too great rn
2021-03-27 20:37:06 +01:00
Dylan DPC
a900677eb9
Rollup merge of #82525 - RalfJung:unaligned-ref-warn, r=petrochenkov
make unaligned_references future-incompat lint warn-by-default

and also remove the safe_packed_borrows lint that it replaces.

`std::ptr::addr_of!` has hit beta now and will hit stable in a month, so I propose we start fixing https://github.com/rust-lang/rust/issues/27060 for real: creating a reference to a field of a packed struct needs to eventually become a hard error; this PR makes it a warn-by-default future-incompat lint. (The lint already existed, this just raises its default level.) At the same time I removed the corresponding code from unsafety checking; really there's no reason an `unsafe` block should make any difference here.

For references to packed fields outside `unsafe` blocks, this means `unaligned_refereces` replaces the previous `safe_packed_borrows` warning with a link to https://github.com/rust-lang/rust/issues/82523 (and no more talk about unsafe blocks making any difference). So behavior barely changes, the warning is just worded differently. For references to packed fields inside `unsafe` blocks, this PR shows a new future-incompat warning.

Closes https://github.com/rust-lang/rust/issues/46043 because that lint no longer exists.
2021-03-27 20:37:05 +01:00
Dylan DPC
520c9a25df
Rollup merge of #81351 - lcnr:big-money-big-prices, r=oli-obk
combine: stop eagerly evaluating consts

`super_relate_consts` eagerly evaluates constants which doesn't seem too great.

I now also finally understand why all of the unused substs test passed. The reason being
that we just evaluated the constants in `super_relate_consts` 😆

While this change isn't strictly necessary as evaluating consts here doesn't hurt, it still feels a lot cleaner to do it this way

r? `@oli-obk` `@nikomatsakis`
2021-03-27 20:37:04 +01:00
Violet
0a30c5b2ab revert rustdoc links in core to use #method. because they link to alloc, which may not be available 2021-03-27 14:38:43 -04:00
Ralf Jung
4f03f94863 clarify 'remains attached', and remove recommendation to use integer arithmetic 2021-03-27 19:31:43 +01:00
Ralf Jung
b5d71bfb0f add definition of 'allocated object', and link it from relevant method docs 2021-03-27 19:26:10 +01:00
Violet
634d48d9d6 adjust documentation links for slice ascii case functions to use newer rustdoc link format 2021-03-27 14:15:42 -04:00
Violet
d29d87f08b update links to make_ascii_lowercase for slice to point to methods on the same type, rather than on u8 2021-03-27 13:45:30 -04:00
Josh Stone
f0a6052d62 Add the tracking issue for #![feature(iter_zip)] 2021-03-27 10:14:54 -07:00
bors
afaf33dcaf Auto merge of #83573 - JohnTitor:rollup-28jnzsr, r=JohnTitor
Rollup of 10 pull requests

Successful merges:

 - #79399 (Use detailed and shorter fs error explaination)
 - #83348 (format macro argument parsing fix)
 - #83462 (ExitStatus: print "exit status: {}" rather than "exit code: {}" on unix)
 - #83526 (lazily calls some fns)
 - #83558 (Use DebugStruct::finish_non_exhaustive() in std.)
 - #83559 (Fix Debug implementation for RwLock{Read,Write}Guard.)
 - #83560 (Derive Debug for io::Chain instead of manually implementing it.)
 - #83561 (Improve Debug implementations of Mutex and RwLock.)
 - #83567 (Update rustup cross-compilation docs link)
 - #83569 (Add regression tests for #56445)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-03-27 16:34:59 +00:00
Yuki Okushi
1ad7c52812
Rollup merge of #83569 - sjakobi:issue56445-regression-test, r=jackh726
Add regression tests for #56445

Closes #56445.
2021-03-28 01:33:23 +09:00
Yuki Okushi
69acaf335f
Rollup merge of #83567 - jonjensen:patch-1, r=GuillaumeGomez
Update rustup cross-compilation docs link
2021-03-28 01:33:22 +09:00
Yuki Okushi
a800d7f63f
Rollup merge of #83561 - m-ou-se:lock-debug, r=jackh726
Improve Debug implementations of Mutex and RwLock.

This improves the Debug implementations of Mutex and RwLock.

They now show the poison flag and use debug_non_exhaustive. (See #67364.)
2021-03-28 01:33:21 +09:00
Yuki Okushi
8ad5f2143e
Rollup merge of #83560 - m-ou-se:io-chain-debug, r=sfackler
Derive Debug for io::Chain instead of manually implementing it.

This derives Debug for io::Chain instead of manually implementing it.

The manual implementation has the same bounds, so I don't think there's any reason for a manual implementation. The names used in the derive implementation are even nicer (`first`/`second`) than the manual implementation (`t`/`u`), and include the `done_first` field too.
2021-03-28 01:33:19 +09:00
Yuki Okushi
5dc29e189b
Rollup merge of #83559 - m-ou-se:rwlock-guard-debug-fix, r=jackh726
Fix Debug implementation for RwLock{Read,Write}Guard.

This would attempt to print the Debug representation of the lock that the guard has locked, which will try to lock again, fail, and just print `"<locked>"` unhelpfully.

After this change, this just prints the contents of the mutex, like the other smart pointers (and MutexGuard) do.

MutexGuard had this problem too: https://github.com/rust-lang/rust/issues/57702
2021-03-28 01:33:18 +09:00
Yuki Okushi
53cc8065a0
Rollup merge of #83558 - m-ou-se:use-finish-non-exhaustive, r=jackh726
Use DebugStruct::finish_non_exhaustive() in std.

See https://github.com/rust-lang/rust/issues/67364
2021-03-28 01:33:17 +09:00
Yuki Okushi
fa70398d6d
Rollup merge of #83526 - klensy:lazy-too, r=petrochenkov
lazily calls some fns

Replaced some fn's with it's lazy variants.
2021-03-28 01:33:16 +09:00
Yuki Okushi
3f41fdd2eb
Rollup merge of #83462 - ijackson:exitstatus-message-wording, r=joshtriplett
ExitStatus: print "exit status: {}" rather than "exit code: {}" on unix

Proper Unix terminology is "exit status" (vs "wait status").  "exit
code" is imprecise on Unix and therefore unclear.  (As far as I can
tell, "exit code" is correct terminology on Windows.)

This new wording is unfortunately inconsistent with the identifier
names in the Rust stdlib.

It is the identifier names that are wrong, as discussed at length in eg
  https://doc.rust-lang.org/nightly/std/process/struct.ExitStatus.html
  https://doc.rust-lang.org/nightly/std/os/unix/process/trait.ExitStatusExt.html

Unfortunately for API stability reasons it would be a lot of work, and
a lot of disruption, to change the names in the stdlib (eg to rename
`std::process::ExitStatus` to `std::process::ChildStatus` or
something), but we should fix the message output.  Many (probably
most) readers of these messages about exit statuses will be users and
system administrators, not programmers, who won't even know that Rust
has this wrong terminology.

So I think the right thing is to fix the documentation (as I have
already done) and, now, the terminology in the implementation.

This is a user-visible change to the behaviour of all Rust programs
which run Unix subprocesses.  Hopefully no-one is matching against the
exit status string, except perhaps in tests.
2021-03-28 01:33:15 +09:00