Skip to content

Added the 'no_randomize_layout' attr to clang #16

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1,485 commits into from
Feb 26, 2019

Conversation

Nixoncole
Copy link

@Nixoncole Nixoncole commented Feb 12, 2019

Closes #6

Please ignore my poorly named git branch...

Outside of that, I think this should work. Next is docs, which will touch both of these files again.

This doesnt have to be merged if you dont want to @connorkuehl but here ya go

Copy link

@connorkuehl connorkuehl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should work

Only one way to find out 😉

My preference here would be to also address the remaining acceptance criteria on #6 in this PR (see this comment). My reason for that is so we don't have a vestigial attribute that is otherwise unused in the code that we're shipping on the develop branch.

@Nixoncole
Copy link
Author

Ah I'll be honest I did not know there was formalized acceptance criteria. I'll look around and see about emitting compiler warnings etc.

@tim-pugh
Copy link
Member

tim-pugh commented Feb 13, 2019

Let's add this PR to a develop branch (a different one then the current one named develop :-) ) so we can prep for the RFC, but besides that I'll have to take a look at this tomorrow/when the rest of the bits come on in.

@connorkuehl
Copy link

Let's add this PR to a develop branch (a different one then the current one named develop :-) )

I might be mistaken, but I thought we were branching off only for features that would be merged AFTER we instate the code freeze. Is that correct?

@tim-pugh
Copy link
Member

tim-pugh commented Feb 15, 2019

Let's add this PR to a develop branch (a different one then the current one named develop :-) )

I might be mistaken, but I thought we were branching off only for features that would be merged AFTER we instate the code freeze. Is that correct?

We've talked about this last Tueday

"We'll call a code freeze, send rfc, have a develop branch for the stretch, fix the feedback, and can resubmit again"

If a stretch goals is all good then we'll just do a pr from that branch (or branches) into our mainline before the code freeze. That is fine.

legrosbuffle and others added 19 commits February 18, 2019 07:59
Summary:
A store to an object whose lifetime is about to end can be removed.

See PR40550 for motivation.

Reviewers: niravd

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D57541

llvm-svn: 354244
Second attempt, trying to navigate out of the UB zone using
union for storage instead of raw bytes.

I'm prepared to revert that commit as soon as validation breaks,
which is likely to happen.

llvm-svn: 354246
Reviewers: courbet, gchatelet

Reviewed By: courbet, gchatelet

Subscribers: tschuett, llvm-commits

Differential Revision: https://reviews.llvm.org/D54895

llvm-svn: 354250
Summary:
The policy is about cmake_include_files ignoring
CMAKE_REQUIRED_LIBRARIES in the OLD behavior. Llvm already sets this
policy to NEW, but that is overridden by our cmake_minimum_required
command.

This makes our cmake policy setup consistent with the llvm build files
and avoids a warning when using newer versions of cmake.

Reviewers: sgraenitz, xiaobai

Subscribers: mgorny, lldb-commits

Differential Revision: https://reviews.llvm.org/D58279

llvm-svn: 354251
COFF files are modelled in lldb as having one big container section
spanning the entire module image, with the actual sections being
subsections of that. In this model, the base address is simply the
address of the first byte of that section.

This also removes the hack where ObjectFilePECOFF was using the
m_file_offset field to communicate this information. Using file offset
for this purpose is completely wrong, as that is supposed to indicate
where is this ObjectFile located in the file on disk. This field is only
meaningful for fat binaries, and should normally be 0.

Both PDB plugins have been updated to use GetBaseAddress instead of
GetFileOffset.

llvm-svn: 354258
Summary:
This patch unifies all those tests which check the correctness of the
redecl chains. Previously we had several structurally very similar test
cases for each language construct (class, function, variable, function
template, ...).

We still use value-parameterized tests for the different AST
compatibility switches (-fdelayed-template-parsing, -fms-compatibility).
Gtest makes it possible to have either value-parameterized or
type-parameterized fixtures. However, we cannot have both value- and
type-parameterized test fixtures. So we use a value-parameterized test
fixture in the gtest sense. We intend to mimic gtest's type-parameters
via the type template parameter. We manually instantiate the different
tests with the each types.

After this patch I am planning to put the "generic redecl chain" related
tests into their own separate test file (in another patch).

Reviewers: a_sidorin, shafik, a.sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Differential Revision: https://reviews.llvm.org/D57236

llvm-svn: 354259
…State. NFCI

This is another change in preparation for PR37494.
No functional change intended.

llvm-svn: 354261
Summary:
Indexing context was skipping explicit template instantiations as well.
This patch makes sure it only skips implicit ones.

Subscribers: arphaman, jdoerfert, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D58189

llvm-svn: 354262
…r modules

This re-commits r353677, which was reverted due to test failures on the
windows bot. The issue there was that ObjectFilePECOFF vended its base
address through the incorrect interface. SymbolFilePDB depended on that,
which lead to assertion failures when SymbolFilePDB was attempting to
use the placeholder object files as a base. This has been fixed in
r354258

It also fixes one small problem in the original patch. The issue was that the
Module class would attempt to overwrite the object file we created in
CreateModuleFromObjectFile if the file corresponding to the placeholder object
file happened to exist (but we have already disqualified it due to UUID
mismatch. The fix is simple -- we set the m_did_load_objfile flag to properly
record the fact that we have already created an object file for the module.

The original commit message was:

The reason this wasn't working was that ProcessMinidump was creating odd
object-file-less modules, and SymbolFileBreakpad required the module to
have an associated object file because it needed to get its base
address.

This fixes that by introducing a PlaceholderObjectFile to serve as a
dummy object file. The general idea for this is taken from D55142, but
I've reworked it a bit to avoid the need for the PlaceholderModule
class. Now that we have an object file, our modules are sufficiently
similar to regular modules that we can use the regular Module class
almost out of the box -- the only thing I needed to tweak was the
Module::CreateModuleFromObjectFile functon to set the module's FileSpec
in addition to it's architecture. This wasn't needed for ObjectFileJIT
(the other user of CreateModuleFromObjectFile), but it shouldn't hurt it
either, and the change seems like a straightforward extension of this
function.

Reviewers: clayborg, lemo, amccarth

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D57751

llvm-svn: 354263
This is a follow-up to r354246 and a reimplementation of https://reviews.llvm.org/D57097?id=186600
that should not trigger any UB thanks to the use of an union.

This may still be subject to the problem solved by std::launder, but I'm unsure how it interacts whith union.
/me plans to revert if this triggers any relevant bot failure. At least this validates in Release mode with
clang 6.0.1 and gcc 4.8.5.

llvm-svn: 354264
This adds ACLE-defined macros to test for code being compiled in the ROPI and
RWPI position-independence modes.

Differential revision: https://reviews.llvm.org/D23610

llvm-svn: 354265
Reviewers: a_sidorin, shafik, a.sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D57910

llvm-svn: 354267
…olved name or incomplete type.

Summary:
Multiple diagnostics can be caused by the same unresolved name or incomplete type,
especially if the code is copy-pasted without #includes. The cache can avoid making
repetitive index requests, and thus reduce latency and allow more diagnostics to be
fixed (we limit the number of index requests for each parse).

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, jdoerfert, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D58239

llvm-svn: 354268
This is similar to D58048.

Instead of scanning the dynamic table to read the
DT_VERDEFNUM, we could take it from the sh_info field.
(https://docs.oracle.com/cd/E19683-01/816-1386/chapter6-94076/index.html)

The patch does this.

llvm-svn: 354270
…mination.

This patch fixes a bug where register writes performed by optimizable register
moves were sometimes wrongly treated like partial register updates.  Before this
patch, llvm-mca wrongly predicted a 1.50 IPC for test reg-move-elimination-6.s
(added by this patch).  With this patch, llvm-mca correctly updates the register
defintions in the PRF, and the IPC for that test is now correctly reported as 2.

llvm-svn: 354271
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D58190

llvm-svn: 354272
topperc and others added 23 commits February 20, 2019 20:18
…ow up to r354363.

This avoids depending on the peephole pass to do load folding.

Also adds some load folding for some insert_subvector patterns that use blend.

All of this was found by temporarily adding TB_NO_FORWARD to the blend immediate entries in the load folding tables.

I've added -disable-peephole to some of the affected tests from that experiment to ensure we're testing isel patterns.

llvm-svn: 354511
We unconditionally predefine these macros. However, they may be used to
determine if the type is supported. In that case, there are unnecessary
failures to compile the code.

This is the proposed fix for https://bugs.llvm.org/show_bug.cgi?id=40559

Differential revision: https://reviews.llvm.org/D57577

llvm-svn: 354512
Second part of https://bugs.llvm.org/show_bug.cgi?id=40442.

This adds an extra UnrollVectorOverflowOp() method to SDAG, because
the general UnrollOverflowOp() method can't deal with multiple results.

Additionally we need to expand UMULO/SMULO during vector op
legalization, as it may result in unrolling, which may need additional
type legalization.

Differential Revision: https://reviews.llvm.org/D57997

llvm-svn: 354513
…e LHS when handling ISD::AND

If the LHS has known zeros, then the RHS immediate mask might have been simplified to remove those bits.

This patch adds a call to computeKnownBits to get the known zeroes to handle that possibility. I left an early out to skip the call if all of the demanded bits are set in the mask.

Differential Revision: https://reviews.llvm.org/D58464

llvm-svn: 354514
Summary:
gcc warns that `__throw_runtime_error` is declared both in `<__locale>`
and `<stdexcept>`, if `-Wredundant-decls` is passed on the command
line; this is the case with FreeBSD when ${WARNS} == 6.

Since `<__locale>` gets its first declaration via a transitive include
of `<stdexcept>`, and the second declaration is after the first
invocation of `__throw_runtime_error`, delete that second declaration.

Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>

Reviewers: kristina, MaskRay, EricWF, ldionne, ngie

Reviewed By: EricWF

Subscribers: krytarowski, brooks, emaste, dim, christof, jdoerfert, libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D58425

llvm-svn: 354515
Reviewers: arsenm

Reviewed By: arsenm

Subscribers: volkan, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, rovka, kristof.beyls, dstuttard, tpr, t-tye, llvm-commits

Differential Revision: https://reviews.llvm.org/D52922

llvm-svn: 354516
Summary:
The analsis on the throwing behvaiour on functions and statements gave only
a binary answer whether an exception could occur and if yes which types are
thrown.
This refactoring allows keeping track if there is a unknown factor, because the
code calls to some functions with unavailable source code with no `noexcept`
information.
This 'potential Unknown' information is propagated properly and can be queried
separately.

Reviewers: lebedev.ri, aaron.ballman, baloghadamsoftware, alexfh

Reviewed By: lebedev.ri, baloghadamsoftware

Subscribers: xazax.hun, rnkovacs, a.sidorin, Szelethus, donat.nagy, dkrupp, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D57883

llvm-svn: 354517
Summary:
Remove stores that are immediately overwritten by larger
stores.

Reviewers: courbet, rnk

Reviewed By: rnk

Subscribers: javed.absar, hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D58467

llvm-svn: 354518
This is the 'sub0' (negate) pattern from PR31754:
https://bugs.llvm.org/show_bug.cgi?id=31754

llvm-svn: 354519
…from BTC/BTS/BTR instructions when LHS of AND has known zeros.

We can currently remove the mask if the immediate has all ones in the LSBs, but if the LHS of the AND is known zero, then the immediate might have had bits removed.

A similar issue also occurs with shifts and rotates. I'm preparing a common fix for all of them.

llvm-svn: 354520
This change makes some basic type combinations for G_SHUFFLE_VECTOR legal, and
implements them with a very pessimistic TBL2 instruction in the selector.

For TBL2, support is also needed to generate constant pool entries and load from
them in order to materialize the mask register.

Currently supports <2 x s64> and <4 x s32> result types.

Differential Revision: https://reviews.llvm.org/D58466

llvm-svn: 354521
Summary: Quick follow-up to: https://reviews.llvm.org/D58156

Reviewers: vitalybuka

Differential Revision: https://reviews.llvm.org/D58358

llvm-svn: 354522
…ions

When we can't determine with certainty the signature of a function
import we pick the fist signature we find rather than error'ing out.

The resulting program might not do what is expected since we might pick
the wrong signature.  However since undefined behavior in C to use the
same function with different signatures this seems better than refusing
to compile such programs.

Fixes PR40472

Differential Revision: https://reviews.llvm.org/D58304

llvm-svn: 354523
PR was slightly behind, update and fix punctuation
All attributes that emit warnings are required
to be members of a warning group; this is checked
by the clang-test regression suite.
All supported attributes must be etched in stone
in the supported attributes regression test.
@connorkuehl connorkuehl self-requested a review February 23, 2019 06:02
@connorkuehl
Copy link

I have no idea why Github is displaying all these commits in this PR; they've already landed in develop.

It's easier to review the PR by seeing the branch diff here.

@Nixoncole
Copy link
Author

This looks pretty good if you ask me! Thank you for providing the link to an easier view.

@jeffreytakahashi jeffreytakahashi merged commit ae1bf92 into develop Feb 26, 2019
connorkuehl pushed a commit that referenced this pull request Mar 8, 2019
Introduces memory leak in FunctionTest.GetPointerAlignment that breaks sanitizer buildbots:

```
=================================================================
==2453==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 128 byte(s) in 1 object(s) allocated from:
    #0 0x610428 in operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:105
    llvm#1 0x16936bc in llvm::User::operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/lib/IR/User.cpp:151:19
    #2 0x7c3fe9 in Create /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/IR/Function.h:144:12
    #3 0x7c3fe9 in (anonymous namespace)::FunctionTest_GetPointerAlignment_Test::TestBody() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/IR/FunctionTest.cpp:136
    #4 0x1a836a0 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc
    #5 0x1a836a0 in testing::Test::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2474
    #6 0x1a85c55 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11
    #7 0x1a870d0 in testing::TestCase::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28
    #8 0x1aa5b84 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43
    #9 0x1aa4d30 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc
    #10 0x1aa4d30 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4257
    #11 0x1a6b656 in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46
    #12 0x1a6b656 in main /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50
    #13 0x7f5af37a22e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)

Indirect leak of 40 byte(s) in 1 object(s) allocated from:
    #0 0x610428 in operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:105
    llvm#1 0x151be6b in make_unique<llvm::ValueSymbolTable> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/ADT/STLExtras.h:1349:29
    #2 0x151be6b in llvm::Function::Function(llvm::FunctionType*, llvm::GlobalValue::LinkageTypes, unsigned int, llvm::Twine const&, llvm::Module*) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/lib/IR/Function.cpp:241
    #3 0x7c4006 in Create /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/IR/Function.h:144:16
    #4 0x7c4006 in (anonymous namespace)::FunctionTest_GetPointerAlignment_Test::TestBody() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/IR/FunctionTest.cpp:136
    #5 0x1a836a0 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc
    #6 0x1a836a0 in testing::Test::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2474
    #7 0x1a85c55 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11
    #8 0x1a870d0 in testing::TestCase::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28
    #9 0x1aa5b84 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43
    #10 0x1aa4d30 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc
    #11 0x1aa4d30 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4257
    #12 0x1a6b656 in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46
    #13 0x1a6b656 in main /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50
    #14 0x7f5af37a22e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)

SUMMARY: AddressSanitizer: 168 byte(s) leaked in 2 allocation(s).
```

See http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/11358/steps/check-llvm%20asan/logs/stdio for more information.

Also introduces use-of-uninitialized-value in ConstantsTest.FoldGlobalVariablePtr:
```
==7070==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x14e703c in User /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/User.h:79:5
    llvm#1 0x14e703c in Constant /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/Constant.h:44
    #2 0x14e703c in llvm::GlobalValue::GlobalValue(llvm::Type*, llvm::Value::ValueTy, llvm::Use*, unsigned int, llvm::GlobalValue::LinkageTypes, llvm::Twine const&, unsigned int) /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/GlobalValue.h:78
    #3 0x14e5467 in GlobalObject /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/GlobalObject.h:34:9
    #4 0x14e5467 in llvm::GlobalVariable::GlobalVariable(llvm::Type*, bool, llvm::GlobalValue::LinkageTypes, llvm::Constant*, llvm::Twine const&, llvm::GlobalValue::ThreadLocalMode, unsigned int, bool) /b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/Globals.cpp:314
    #5 0x6938f1 in llvm::(anonymous namespace)::ConstantsTest_FoldGlobalVariablePtr_Test::TestBody() /b/sanitizer-x86_64-linux-fast/build/llvm/unittests/IR/ConstantsTest.cpp:565:18
    #6 0x1a240a1 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc
    #7 0x1a240a1 in testing::Test::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2474
    #8 0x1a26d26 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11
    #9 0x1a2815f in testing::TestCase::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28
    #10 0x1a43de8 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43
    #11 0x1a42c47 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc
    #12 0x1a42c47 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4257
    #13 0x1a0dfba in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46
    #14 0x1a0dfba in main /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50
    #15 0x7f2081c412e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
    #16 0x4dff49 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/unittests/IR/IRTests+0x4dff49)

SUMMARY: MemorySanitizer: use-of-uninitialized-value /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/User.h:79:5 in User
```

See http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/30222/steps/check-llvm%20msan/logs/stdio for more information.

llvm-svn: 355616
@connorkuehl connorkuehl deleted the no_ranomize_layout_attr branch July 6, 2019 15:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.