Rollup merge of #44745 - alexcrichton:no-delim-none, r=estebank
rustc: Don't use DelimToken::None if possible
This commit fixes a regression from #44601 where lowering attribute to HIR now
involves expanding interpolated tokens to their actual tokens. In that commit
all interpolated tokens were surrounded with a `DelimToken::None` group of
tokens, but this ended up causing regressions like #44730 where the various
attribute parsers in `syntax/attr.rs` weren't ready to cope with
`DelimToken::None`. Instead of fixing the parser in `attr.rs` this commit
instead opts to just avoid the `DelimToken::None` in the first place, ensuring
that the token stream should look the same as it did before where possible.
Rollup merge of #44717 - pnkfelix:debugflags-borrowckmir-implies-emitendregions, r=arielb1
Make `-Z borrowck-mir` imply that `EndRegion`'s should be emitted.
Before this change, the `-Z borrowck-mir` flag is useless if you do not also pass `-Z emit-end-regions`.
So, in the same spirit as f2892ad281cb11421ebae741d698e0af14d3ecf6, make `-Z borrowck-mir` also emit `EndRegion` statements. (This will hopefully avoid some initial speed bumps for new-comers helping out with NLL.)
Rollup merge of #44712 - oconnor663:copy_test, r=GuillaumeGomez
fix an incorrect assertion in the doc example for `std::io::copy`
I think this wasn't caught by CI because the `foo` wrapper function was only defined and not called. This seems to be the norm for doc examples that define a `foo` function. Is that on purpose?
Rollup merge of #44648 - Havvy:doc-size_of, r=dtolnay
Expand size_of docs
This PR does 3 things.
1. Adds a description of what pointer size means to the primitive pages for usize and isize.
2. Says the general size of things is not stable from compiler to compiler.
3. Adds a table of sizes of things that we do guarantee. As this is the first table in the libstd docs, I've included a picture of how that looks.
Auto merge of #44696 - michaelwoerister:fingerprints-in-dep-graph-3, r=nikomatsakis
incr.comp.: Move task result fingerprinting into DepGraph.
This PR
- makes the DepGraph store all `Fingerprints` of task results,
- allows `DepNode` to be marked as input nodes,
- makes HIR node hashing use the regular fingerprinting infrastructure,
- removes the now unused `IncrementalHashesMap`, and
- makes sure that `traits_in_scope_map` fingerprints are stable.
Retain suid/sgid/sticky bits in Metadata.permissions
Most users would expect set_permissions(Metadata.permissions()) to be
non-destructive. While we can't guarantee this, we can at least pass
the needed info to chmod.
Also update the PermissionsExt documentation to disambiguate what it
contains, and to refer to the underlying value as `st_mode` rather than
its type `mode_t`.
Auto merge of #44754 - marcusbuffett:bootstrap-config-toml-fix, r=alexcrichton
Catch IOError in bootstrap.py when loading config.toml
When I pulled this repo and tried to build using the command in the readme, I got an error about a missing `config.toml`.
If config.toml doesn't exist, then an `IOError` will be raised the `with open(...)` line. Prior to e788fa7b6cf07860eb0ff3e90ff32fc4f9d26cae, this was caught because the `except` clause didn't specify what exceptions it caught, so both `IOError` and `OSError` were caught.
First time contributing, so please let me know if I'm doing anything wrong.
Auto merge of #44682 - bluss:iter-rfold, r=dtolnay
Add iterator method .rfold(init, function); the reverse of fold
rfold is the reverse version of fold.
Fold allows iterators to implement a different (non-resumable) internal
iteration when it is more efficient than the external iteration implemented
through the next method. (Common examples are VecDeque and .chain()).
Introduce rfold() so that the same customization is available for reverse
iteration. This is achieved by both adding the method, and by having the
Rev\<I> adaptor connect Rev::rfold → I::fold and Rev::fold → I::rfold.
On the surface, rfold(..) is just .rev().fold(..), but the special case
implementations allow a data structure specific fold to be used through for
example .iter().rev(); we thus have gains even for users never calling exactly
rfold themselves.
Marcus Buffett [Thu, 21 Sep 2017 19:15:10 +0000 (12:15 -0700)]
Catch IOError
If config.toml doesn't exist, then an IOError will be raised
on the `with open(...)` line. Prior to e788fa7, this was
caught because the `except` clause didn't specify what
exceptions it caught, so both IOError and OSError were
caught
Alex Crichton [Thu, 21 Sep 2017 15:13:25 +0000 (08:13 -0700)]
rustc: Don't use DelimToken::None if possible
This commit fixes a regression from #44601 where lowering attribute to HIR now
involves expanding interpolated tokens to their actual tokens. In that commit
all interpolated tokens were surrounded with a `DelimToken::None` group of
tokens, but this ended up causing regressions like #44730 where the various
attribute parsers in `syntax/attr.rs` weren't ready to cope with
`DelimToken::None`. Instead of fixing the parser in `attr.rs` this commit
instead opts to just avoid the `DelimToken::None` in the first place, ensuring
that the token stream should look the same as it did before where possible.
Auto merge of #44679 - oli-obk:clippy_ci, r=alexcrichton
Add clippy to `toolstate.toml`
r? @alexcrichton
cc @Manishearth
I have no idea how to get clippy working... it needs proc macros, and I think I did everything right (I just did what the cargo step is doing), but it's not working:
```
error: libproc_macro-6210e4b46662ec28.so: cannot open shared object file: No such file or directory
--> src/tools/clippy/clippy_lints/src/lib.rs:47:1
|
47 | extern crate serde_derive;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
error: libproc_macro-6210e4b46662ec28.so: cannot open shared object file: No such file or directory
--> src/tools/clippy/clippy_lints/src/lib.rs:47:1
|
47 | extern crate serde_derive;
| ^
```
It's especially weird since it used to work
Anyway. Fixing it can be left for a future PR, this one adds it to CI, but marks it as "broken"
Auto merge of #44627 - zackmdavis:the_capgate_perogative, r=nrc
`--cap-lints allow` switches off `can_emit_warnings`
This boolean field on the error `Handler` is toggled to silence
warnings when `-A warnings` is passed. (This is actually a separate
mechanism from the global lint level—whether there's some redundancy
to be factored away here is an important question, but not one we
concern ourselves with in this commit.) But the same rationale
applies for `--cap-lints allow`. In particular, this makes the "soft"
feature-gate warning introduced in 8492ad24 (which is not a lint, but
just calls `struct_span_warn`) not pollute the builds of dependent
crates.
Thanks to @kennytm for pointing out the potential of
`can_emit_warnings` for this purpose.
Auto merge of #44392 - Zoxc:yield-order, r=nikomatsakis
Only consider yields coming after the expressions when computing generator interiors
When looking at the scopes which temporaries of expressions can live for during computation of generator interiors, only consider yields which appear after the expression in question in the HIR.
Auto merge of #44525 - aidanhs:aphs-no-null-deref, r=alexcrichton
Correctly bubble up errors from libbacktrace
Previously the first part of this code didn't check for a null pointer and blindly passed it back down, causing a segfault if libbacktrace failed to initialise. I've changed this to check and bubble up the error if relevant.
Auto merge of #44355 - Xaeroxe:optimize_drain_filter, r=alexcrichton
Optimize drain_filter
This PR cuts out two copies from each iteration of `drain_filter` by exchanging the swap operation for a copy_nonoverlapping function call instead. Since the data being swapped is not needed anymore we can just overwrite it instead.
Auto merge of #44505 - nikomatsakis:lotsa-comments, r=steveklabnik
rework the README.md for rustc and add other readmes
OK, so, long ago I committed to the idea of trying to write some high-level documentation for rustc. This has proved to be much harder for me to get done than I thought it would! This PR is far from as complete as I had hoped, but I wanted to open it so that people can give me feedback on the conventions that it establishes. If this seems like a good way forward, we can land it and I will open an issue with a good check-list of things to write (and try to take down some of them myself).
Here are the conventions I established on which I would like feedback.
**Use README.md files**. First off, I'm aiming to keep most of the high-level docs in `README.md` files, rather than entries on forge. My thought is that such files are (a) more discoverable than forge and (b) closer to the code, and hence can be edited in a single PR. However, since they are not *in the code*, they will naturally get out of date, so the intention is to focus on the highest-level details, which are least likely to bitrot. I've included a few examples of common functions and so forth, but never tried to (e.g.) exhaustively list the names of functions and so forth.
- I would like to use the tidy scripts to try and check that these do not go out of date. Future work.
**librustc/README.md as the main entrypoint.** This seems like the most natural place people will look first. It lays out how the crates are structured and **is intended** to give pointers to the main data structures of the compiler (I didn't update that yet; the existing material is terribly dated).
**A glossary listing abbreviations and things.** It's much harder to read code if you don't know what some obscure set of letters like `infcx` stands for.
**Major modules each have their own README.md that documents the high-level idea.** For example, I wrote some stuff about `hir` and `ty`. Both of them have many missing topics, but I think that is roughly the level of depth that would be good. The idea is to give people a "feeling" for what the code does.
What is missing primarily here is lots of content. =) Here are some things I'd like to see:
- A description of what a QUERY is and how to define one
- Some comments for `librustc/ty/maps.rs`
- An overview of how compilation proceeds now (i.e., the hybrid demand-driven and forward model) and how we would like to see it going in the future (all demand-driven)
- Some coverage of how incremental will work under red-green
- An updated list of the major IRs in use of the compiler (AST, HIR, TypeckTables, MIR) and major bits of interesting code (typeck, borrowck, etc)
- More advice on how to use `x.py`, or at least pointers to that
- Good choice for `config.toml`
- How to use `RUST_LOG` and other debugging flags (e.g., `-Zverbose`, `-Ztreat-err-as-bug`)
- Helpful conventions for `debug!` statement formatting
Rollup merge of #44689 - behnam:unicode, r=sfackler
[libstd_unicode] Expose UnicodeVersion type
In <https://github.com/rust-lang/rust/pull/42998>, we added an
uninstantiable type for the internal `UNICODE_VERSION` value,
`UnicodeVersion`, but it was not made public to the outside of the
crate, resulting in the value becoming less useful. Here we make the
type accessible from the outside.
Also add a run-pass test to make sure the type and value can be accessed
as intended.
Rollup merge of #44626 - MaulingMonkey:lld-link-natvis-regression-fix, r=michaelwoerister
Skip passing /natvis to lld-link until supported.
### Overview
Teaching rustc about MSVC's undocumented linker flag, /NATVIS, broke rustc's compatability with LLVM's `lld-link` frontend, as it does not recognize the flag. This pull request works around the problem by excluding `lld-link` by name. @retep998 discovered this regression.
### Possible Issues
- Other linkers that try to be compatible with the MSVC linker flavor may also be broken and in need of workarounds.
- Warning about the workaround may be overkill for a minor reduction in debug functionality.
- Depending on how long this workaround sticks around, it may eventually be preferred to version check `lld-link` instead of assuming all versions are incompatible.
### Relevant issues
* Broke in https://github.com/rust-lang/rust/pull/43221 Embed MSVC .natvis files into .pdbs and mangle debuginfo for &str, *T, and [T].
* LLVM patched in https://github.com/llvm-mirror/lld/commit/27b9c4285364d8d76bb43839daa100c2f80f8329 to ignore the flag instead of erroring.
Auto merge of #44620 - zackmdavis:rfc_1940_housekeeping, r=nikomatsakis
RFC 1940 housekeeping
* move test to own directory, as requested in https://github.com/rust-lang/rust/issues/43302#issuecomment-329579185
* exercise trait methods in test
* unstable book section
Auto merge of #44601 - alexcrichton:lower-attributes-in-hir, r=nrc
rustc: Forbid interpolated tokens in the HIR
Right now the HIR contains raw `syntax::ast::Attribute` structure but nowadays
these can contain arbitrary tokens. One variant of the `Token` enum is an
"interpolated" token which basically means to shove all the tokens for a
nonterminal in this position. A "nonterminal" in this case is roughly analagous
to a macro argument:
macro_rules! foo {
($a:expr) => {
// $a is a nonterminal as an expression
}
}
Currently nonterminals contain namely items and expressions, and this poses a
problem for incremental compilation! With incremental we want a stable hash of
all HIR items, but this means we may transitively need a stable hash *of the
entire AST*, which is certainly not stable w/ node ids and whatnot. Hence today
there's a "bug" where the "stable hash" of an AST is just the raw hash value of
the AST, and this only arises with interpolated nonterminals. The downside of
this approach, however, is that a bunch of errors get spewed out during
compilation about how this isn't a great idea.
This PR is focused at fixing these warnings, basically deleting them from the
compiler. The implementation here is to alter attributes as they're lowered from
the AST to HIR, expanding all nonterminals in-place as we see them. This code
for expanding a nonterminal to a token stream already exists for the
`proc_macro` crate, so we basically just reuse the same implementation there.
After this PR it's considered a bug to have an `Interpolated` token and hence
the stable hash implementation simply uses `bug!` in this location.
Auto merge of #44026 - QuietMisdreavus:trimmed-std, r=steveklabnik
hide internal types/traits from std docs via new #[doc(masked)] attribute
Fixes #43701 (hopefully for good this time)
This PR introduces a new parameter to the `#[doc]` attribute that rustdoc looks for on `extern crate` statements. When it sees `#[doc(masked)]` on such a statement, it hides traits and types from that crate from appearing in either the "Trait Implementations" section of many type pages, or the "Implementors" section of trait pages. This is then applied to the `libc`/`rand`/`compiler_builtins` imports in libstd to prevent those crates from creating broken links in the std docs.
Like in #43348, this also introduces a feature gate, `doc_masked`, that controls the use of this parameter.
To view the std docs generated with this change, head to https://tonberry.quietmisdreavus.net/std-43701/std/index.html.
In <https://github.com/rust-lang/rust/pull/42998>, we added an
uninstantiable type for the internal `UNICODE_VERSION` value,
`UnicodeVersion`, but it was not made public to the outside of the
crate, resulting in the value becoming less useful. Here we make the
type accessible from the outside.
Also add a run-pass test to make sure the type and value can be accessed
as intended.
Alex Crichton [Fri, 15 Sep 2017 15:28:34 +0000 (08:28 -0700)]
rustc: Forbid interpolated tokens in the HIR
Right now the HIR contains raw `syntax::ast::Attribute` structure but nowadays
these can contain arbitrary tokens. One variant of the `Token` enum is an
"interpolated" token which basically means to shove all the tokens for a
nonterminal in this position. A "nonterminal" in this case is roughly analagous
to a macro argument:
macro_rules! foo {
($a:expr) => {
// $a is a nonterminal as an expression
}
}
Currently nonterminals contain namely items and expressions, and this poses a
problem for incremental compilation! With incremental we want a stable hash of
all HIR items, but this means we may transitively need a stable hash *of the
entire AST*, which is certainly not stable w/ node ids and whatnot. Hence today
there's a "bug" where the "stable hash" of an AST is just the raw hash value of
the AST, and this only arises with interpolated nonterminals. The downside of
this approach, however, is that a bunch of errors get spewed out during
compilation about how this isn't a great idea.
This PR is focused at fixing these warnings, basically deleting them from the
compiler. The implementation here is to alter attributes as they're lowered from
the AST to HIR, expanding all nonterminals in-place as we see them. This code
for expanding a nonterminal to a token stream already exists for the
`proc_macro` crate, so we basically just reuse the same implementation there.
After this PR it's considered a bug to have an `Interpolated` token and hence
the stable hash implementation simply uses `bug!` in this location.
Auto merge of #44680 - infinity0:master, r=Mark-Simulacrum
rustbuild: with --no-fail-fast, report the specific commands that failed
I'm not sure this is the most elegant way of doing it, I'm still a bit of a rust noob. I tried `Vec<Command>` and keeping `Cell` instead of `RefCell` but couldn't fight my way past the borrow errors, this was the first arrangement that I could make work.
Fold allows iterators to implement a different (non-resumable) internal
iteration when it is more efficient than the external iteration
implemented through the next method. (Common examples are VecDeque and
.chain()).
Introduce rfold() so that the same customization is available for
reverse iteration. This is achieved by both adding the method, and by
having the Rev<I> adaptor connect Rev::rfold -> I::fold, Rev::fold -> I::rfold.
Adaptors are things that take iterators and adapt them into other
iterators. With this definition, fold is just a usual method, because it
doesn't normally make an iterator.
projects / rust.git / log