rather being stored inline. Refactor (and rename) the visitor so that
(by default) it only visits the interior content of an item not nested
items.
This is a [breaking-change] for anyone who uses the HIR visitor. Besides
changing `visit::` to `intravisit::`, you need to refactor your visitor
in one of two ways, depending on what it requires:
1. If you just want to visit all items (most common), you should call
`krate.visit_all_items(&mut visitor)`.
2. If you need to visit nested items in the middle of the parent items,
you should override `visit_nested_item` with something like:
`self.visit_item(self.tcx.map.expect_item(item.id))`, presuming you
have access to a tcx (or at least a HIR map).
Rather than modifying the installer to disable directory rewriting,
this patch modifies the directory structure passed to the installer so
that the rewriting gives the correct results. This means that if a
non-standard --libdir is passed to configure then the same --libdir
option (relative to the --prefix) must be passed to the install
script. In the `make install` case this is handled automatically.
Binary distributions are generally generated using the default
--libdir and then have paths optionally rewritten by the installer,
which should continue to work.
This has the advantage of not complicating the installer interface
intended for end-user use.
Fixes#29561
What this patch does:
- Stability annotations are now based on "exported items" supplied by rustc_privacy and not "public items". Exported items are as accessible for external crates as directly public items and should be annotated with stability attributes.
- Trait impls require annotations now.
- Reexports require annotations now.
- Crates themselves didn't require annotations, now they do.
- Exported macros are annotated now, but these annotations are not used yet.
- Some useless annotations are detected and result in errors
- Finally, some small bugs are fixed - deprecation propagates from stable deprecated parents, items in blocks are traversed correctly (fixes https://github.com/rust-lang/rust/issues/29034) + some code cleanup.
This change adds a `MirPass` erasing all early-bound regions from MIR, right before storing it in the MIR map. I've added some assertions at neuralgic points in `trans::mir` doing cheap checks whether region have actually been erased.
Here are some assumptions that I worked under:
- AdtDef references stay untouched. It's the `Substs` accompanying them that need to be handled (e.g. in `AggregateKind::Adt`).
- We can't really get rid of late-bound regions at this point because there is no version `BareFnTy` (for example) that comes without one. These still have to be handled on demand in trans.
Are this assumptions right?
r? @nikomatsakis
Previously this function used channels but this isn't necessary any more now
that threads have return values. This also has the added bonus of appropriately
waiting for the thread to exit to ensure that the function doesn't still have
running threads once it returns.
the const evaluator has a bool constant value, no need to use integers
the `fromb` function is very old. It took me a while of git-blame until i found where it was created. I think it was just a hack. All tests still pass.
I also forbade `&&` and `||` on integral types
Previously this function used channels but this isn't necessary any more now
that threads have return values. This also has the added bonus of appropriately
waiting for the thread to exit to ensure that the function doesn't still have
running threads once it returns.
[breaking change]
I'm not sure if those renames are ok. [TokenType::Tt* to TokenType::*](https://github.com/rust-lang/rust/pull/29582) was obvious, but for all those Item-enums it's less obvious to me what the right way forward is due to the underscore.
On distros that use i486 or i586 in their CHOST, Rust will fail to build
because it is not handling i486 or i586 like i686 is handled. This
changes the match to do work for all instances of i?86 instead of just
i686. The Yocto Project still uses i586 as a target.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
