Commit Graph

6967 Commits

Author SHA1 Message Date
Wim Looman
9ed3661427 Add note about why no_mangle and export_name are unsafe 2020-08-30 20:16:23 +02:00
Wim Looman
79b0ab5195 Scope no_mangle and export_name warnings to the declarations name 2020-08-30 20:16:23 +02:00
Wim Looman
66b2f9acfc Add checking for export_name to unsafe_code lint 2020-08-30 20:16:22 +02:00
Wim Looman
06a0269c11 Add checking for no_mangle to unsafe_code lint 2020-08-30 20:16:22 +02:00
Dylan MacKenzie
c03eba2d08 Add FIXME for faster cached block transfer functions
I've tried a few ways of implementing this, but each fell short.

Adding an auxiliary `_Idx` associated type to `Analysis` that defaults
to `!` but is overridden in the blanket impl of `Analysis` for `A:
GenKillAnalysis` to `A::Idx` seems promising, but the trait solver is
unable to prove equivalence between `A::Idx` and `A::_Idx` within the
overridden version of `into_engine`. Without full-featured
specialization, removing `into_engine` or splitting it into a different
trait would have a significant ergonomic penalty.

Alternatively, we could erase the index type and store a
`GenKillSet<u32>` as well as a function pointer for transmuting between
`&mut A::Domain` and `&mut BitSet<u32>` in the hopes that LLVM can
devirtualize a simple function pointer better than the boxed closure.
However, this is brittle, requires `unsafe` code, and doesn't work for
index types that aren't the same size as a `u32` (e.g. `usize`) since
`GenKillSet` stores a `HybridBitSet`, which may be a `Vec<I>`. Perhaps
safe transmute could help here?
2020-08-30 11:15:25 -07:00
Dylan MacKenzie
b19b8ea611 Update dataflow analyses to use new interface 2020-08-30 11:15:25 -07:00
Dylan MacKenzie
3233fb18a8 Extend dataflow framework to support arbitrary lattices 2020-08-30 11:15:24 -07:00
Dylan MacKenzie
9e45e90596 Allow access to the underlying Results from a ResultsCursor 2020-08-30 11:15:24 -07:00
Dylan MacKenzie
a88dc37c54 Add regex dependency to librustc_mir 2020-08-30 11:15:21 -07:00
Dylan MacKenzie
149307efb7 Improve BitSet APIs
A few small cleanups to `BitSet` and friends:

- Overload `clone_from` for `BitSet`.
- Improve `Debug` represenation of `HybridBitSet`.
- Make `HybridBitSet::domain_size` public.
- Don't require `T: Idx` at the type level. The `Idx` bound is still on
  most `BitSet` methods, but like `HashMap`, it doesn't need to be
  satisfied for the type to exist.
2020-08-30 11:13:18 -07:00
Caleb Cartwright
883b1e7592 parser: restore some fn visibility for rustfmt 2020-08-30 13:04:36 -05:00
David Wood
6ff471b1cf
ty: remove obsolete printer
This commit removes the obsolete printer and replaces all uses of it
with `FmtPrinter`. Of the replaced uses, all but one use was in `debug!`
logging, two cases were notable:

- `MonoItem::to_string` is used in `-Z print-mono-items` and therefore
  affects the output of all codegen-units tests.
- `DefPathBasedNames` was used in `librustc_codegen_llvm/type_of.rs`
  with `LLVMStructCreateNamed` and that'll now get different values, but
  this should result in no functional change.

Signed-off-by: David Wood <david@davidtw.co>
2020-08-30 18:59:07 +01:00
David Wood
0f2bd56b29
lint/ty: move fns to avoid abstraction violation
This commit moves `transparent_newtype_field` and `is_zst` to
`LateContext` where they are used, rather than being on the `VariantDef`
and `TyS` types.

Signed-off-by: David Wood <david@davidtw.co>
2020-08-30 18:57:46 +01:00
Aleksey Kladov
518cac9190 Remove unused function 2020-08-30 19:54:45 +02:00
Aleksey Kladov
ccffea5b6b Move lexer unit tests to rustc_lexer
StringReader is an intornal abstraction which at the moment changes a
lot, so these unit tests cause quite a bit of friction.

Moving them to rustc_lexer and more ingerated-testing style should
make them much less annoying, hopefully without decreasing their
usefulness much.

Note that coloncolon tests are removed (it's unclear what those are
testing).

\r\n tests are removed as well, as we normalize line endings even
before lexing.
2020-08-30 19:53:36 +02:00
Aaron Hill
a97dcfa375
Run cfg-stripping on generic parameters before invoking derive macros
Fixes #75930

This changes the tokens seen by a proc-macro. However, ising a `#[cfg]` attribute
on a generic paramter is unusual, and combining it with a proc-macro
derive is probably even more unusual. I don't expect this to cause any
breakage.
2020-08-30 13:46:19 -04:00
mark
9e5f7d5631 mv compiler to compiler/ 2020-08-30 18:45:07 +03:00