| Age | Commit message (Collapse) | Author |
|---|
|
Re-add --rust-target option to replace --unstable-rust
Re-apply commit. Addresses #832
Instead of specifying whether or not to use stable, specify the Rust
release to support (one of several stable/beta releases or nightly).
The `--unstable-rust` option is still accepted and implies nightly.
The definitions of `RustTarget` and `RustFeatures` are created with
macros.
For each test that uses unions, there is a version that uses the latest stable
and 1.0.
|
|
|
|
Instead of specifying whether or not to use stable, specify the Rust
release to support (one of several stable/beta releases or nightly).
The `--unstable-rust` option is still accepted and implies nightly.
The definitions of `RustTarget` and `RustFeatures` are created with
macros.
For each test that uses unions, there is a version that uses the latest
stable and 1.0.
This also fixes the bug where unions were generated with non-Copy
fields.
|
|
This fixes stylo build failures when template instantiations tests caused a rust
compile error due to a bad test name.
This commit makes names better sanitized, preventing similar errors in the
future.
|
|
Implements Debug trait for types which do not support derive Debug
For types that do not support derive Debug be implemented automatically by rust,
we know can generate implementations of the Debug trait. This code generation is
hidden behind the '--force-derive-debug' command-line flag.
Should solve: #875
Sorry for the extra noise in lib.rs, codegen/mod.rs etc, that was rustfmt.
|
|
|
|
|
|
For types that do not support derive Debug be implemented automatically by rust,
we know can generate implementations of the Debug trait. This code generation is
hidden behind the '--force-derive-debug' command-line flag.
|
|
|
|
This reverts commit 0bb7b9f1c4652f63f41eba4064b79c044fd3d955.
It turns out our CI stopped running test expectations in an earlier
regression (from d73507e; fix incoming) and so this pull request actually
introduced a bunch of failures when compiling the test expectations and running
their unit tests :(
|
|
Instead of specifying whether or not to use stable, specify the Rust
release to support (one of several stable/beta releases or nightly).
The --unstable-rust option is still accepted and implies nightly.
The definitions of `RustTarget` and `RustFeatures` are created with
macros.
For each test that uses unions, there is a version that uses the latest
stable release and stable 1.0.
|
|
Fix recursive whitelisting and handling of opaque for derive default
Fix regression of derive default analysis.
Also fix opaque handing exposed by the above fix. r? @fitzgen
|
|
|
|
|
|
Fix regression of derive default analysis.
Also fix opaque handing exposed by the above fix.
|
|
|
|
|
|
|
|
Can derive default analysis
r? @fitzgen
|
|
|
|
Remove the incomplete `--dummy-uses` feature
This would generate dummy uses of all the whitelisted types, which we were planning on eventually using to generate DWARF for more layout testing of our types, but we decided that isn't worth the trouble. Kill it!
r? @emilio
|
|
This would generate dummy uses of all the whitelisted types, which we were
planning on eventually using to generate DWARF for more layout testing of our
types, but we decided that isn't worth the trouble. Kill it!
|
|
lib: Filter out include paths when looking for clang paths.
Fixes #848
|
|
|
|
Similar to `HasVtable::Extra`, it is no longer needed.
|
|
|
|
This is a throwback from the old, ad-hoc computation before we used the fixpoint
analysis.
|
|
|
|
|
|
When there is large enough alignment that we might generate padding which has
more members that `RUST_DERIVE_IN_ARRAY_LIMIT`, we can break our ability to
derive traits. This commit solves this issue conservatively: there are cases
where we leave a derive on the table, because in order to know that we could add
that derive, we would need to compute padding before we determine whether we can
derive.
Fixes #648
|
|
Pull out the loop that generates dependency map into its own function.
|
|
|
|
s/servo/rust-lang-nursery/ \o/
|
|
Fixes #852
|
|
|
|
|
|
Useful for debugging when constraints go wrong.
|
|
There are lots of different ways that a type can end up being opaque, and it is
best to handle all the ways in one fell swoop, rather than check each different
ways (for example, if a struct has non-type template params, if a template
instantiation's template definition has them, etc...) for each different type
kind.
|
|
|
|
|
|
|
|
debug analysis.
We have a special-case for them in codegen to generate a blob, that can derive
debug.
This is a regression from #824, and hit stylo.
|
|
whitelisted_items() for code generation.
This standardizes the behavior change at #834, but without regressions.
I've added a few more tests for #833 here.
|
|
analysis to be sound.
|
|
Use fully disambiguated name instead of a number for layout tests (fixes #394)
These numbers cause tons of churn in the diffs for checked in bindings.
r? @fitzgen
|
|
This is some copy-paste from the template param usage analysis that we don't
need here. We already assume that blacklisted items are `derive(Debug)`able, and
this doesn't change that.
|
|
a fixed point
`ConstrainResult::Changed` is much more legible than `true`.
|
|
|
|
|
|
processing replacements
Because these operations mutate the IR graph, its better to be safe and double
check again. Don't worry -- these checks only happen on
`testing_only_extra_assertions` builds!
|
