This warning became more strict after updates in the clang compiler.
The error message that this change fixes is:
```
error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
```
PiperOrigin-RevId: 472723024
This PR aims to simplify the logic that grapples with the interplay of usesLegacyInkLayer with properties like maxRippleRadius and inkStyle. I recently merged https://github.com/material-components/material-components-ios/pull/9818 to address this issue, and while I believe it fixes his immediate issue it still leaves other potential issues. Specifically, it does not resolve potential problems related to the ordering of calls to setters for `usesLegacyInkLayer`, `inkStyle`, and `maxRippleRadius` impacting their effectiveness. Hopefully this PR addresses those issues without breaking anything else. I tried to manually test it pretty rigorously by setting all the properties in question in different orders and making sure that everything worked how I expected it to.
Closes#9762.
This change makes it so that the `masksToBounds` property on an MDCButton's MDCInkView's MDCLegacyInkLayer is set according to whether `inkStyle` is `.unbounded` or not, regardless of whether `usesLegacyInkRipple` is set on the MDCButton.
An MDCInkView's layer is always an MDCLegacyInkLayer, even when `usesLegacyInkRipple` is set to NO. In this scenario it acts as the MDCInkView's layer, even if it's not acting as the thing that triggers the ink/ripple animation.
There was a very similar bug to this recently that https://github.com/material-components/material-components-ios/pull/9254 was intended to address. That PR addressed it in the Catalog, as you can see in the before and after gifs in the PR description, but a different client was still experiencing the issue. I built the second client's app to test this PR and it seems to fix it for them.
I wonder if we should try to get rid of MDCLegacyInkLayer, or if we should bypass that and just get rid of MDCInkView entirely, now that we have MDCRippleView.
Closes#9762.
This allows the API to handle assigning inkColor to nil, which is common practice among properties on UI classes that expose color (see UIKit - i.e. UIView.tintColor, UILabel.textColor, etc)
b/144862050
Use more Starlark macros in the BUILD file. This makes it easier for releasing
each week. Also removed the `includes` requirement by making testing imports
relative.
Part of #8150
Instead of reallocating new colors every time a default is required, using a static color can reduce memory use and allocations.
Impact: “memory watermark would be dropped in terms of KB. Memory fragmentation, cache performance, malloc contention will also be reduced slightly.”
Closes#8141
PiperOrigin-RevId: 260767570
All components should have a top-level umbrella header for their includes.
This allows easier refactoring of classes and files within the component.
Creating an umbrella for Color and using it outside the component.
Part of #8086
Adding dynamic color support to the Ink component.
Ink comprises of multiple MDCInkLayer sublayer instances, and they all should update their colors when the style of the system turns to Dark.
Closes#7871
Ink readme wasn't using the script generator and ready templates we already use in our other components. This fixes that and moves the migration guide from Ripple to Ink.
Add animation delegate callbacks for MDCLegacyInkLayer
We would like to observer the start and stop animations of an MDCInkTouchController by setting the animationDelegate of the MDCInkTouchController's MDCInkView. If [MDCInkView usesLegacyInkRipple] == YES the MDCLegacyInkLayer does not call any animation callbacks right now.
We have had errors when generating the docs using jazzy specifically around components giving a fatal error around not finding imports when depending on other components. This is because each component for jazzy is isolated and on its own unless we provide the framework root. This caused our website generator to crash each time and fail to generate a new website.
This should resolve this problem.
QA=
Before the fix when running the website generator we got these errors:
```
/material-components-ios/components/BottomAppBar/src/MDCBottomAppBarView.h:17:9: fatal error: 'MaterialButtons.h' file not found
building site
building search index
^C/Library/Ruby/Gems/2.3.0/gems/rouge-3.1.1/lib/rouge/lexer.rb:458:in `load': Interrupt
from /Library/Ruby/Gems/2.3.0/gems/rouge-3.1.1/lib/rouge/lexer.rb:458:in `load_lexer'
from /Library/Ruby/Gems/2.3.0/gems/rouge-3.1.1/lib/rouge.rb:50:in `block in <top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/rouge-3.1.1/lib/rouge.rb:49:in `each'
from /Library/Ruby/Gems/2.3.0/gems/rouge-3.1.1/lib/rouge.rb:49:in `<top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy/jazzy_markdown.rb:2:in `require'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy/jazzy_markdown.rb:2:in `<top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy/doc.rb:7:in `require'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy/doc.rb:7:in `<top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy/config.rb:5:in `require'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy/config.rb:5:in `<top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy.rb:1:in `require'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy.rb:1:in `<top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/bin/jazzy:13:in `require'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/bin/jazzy:13:in `<top (required)>'
from /usr/local/bin/jazzy:22:in `load'
from /usr/local/bin/jazzy:22:in `<top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/cli/exec.rb:74:in `load'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/cli/exec.rb:74:in `kernel_load'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/cli/exec.rb:28:in `run'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/cli.rb:463:in `exec'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/cli.rb:27:in `dispatch'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/cli.rb:18:in `start'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/exe/bundle:30:in `block in <top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/friendly_errors.rb:124:in `with_friendly_errors'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/exe/bundle:22:in `<top (required)>'
from /usr/local/bin/bundle:22:in `load'
from /usr/local/bin/bundle:22:in `<main>'
/material-components-site-generator/scripts/lib/reporter.js:36
throw e;
^
Error: Command failed: bundle exec jazzy --output "/material-components-site-generator/.stage/ios/catalog/bottomnavigation/api-docs/" --theme "/material-components-site-generator/ios-api-docs-src/theme" --head '/components' --use-safe-filenames
at checkExecSyncError (child_process.js:601:13)
at execSync (child_process.js:641:13)
at JazzyApiGenerator.build (/material-components-site-generator/scripts/lib/jazzy-api-generator.js:34:5)
at PlatformSite.generateApiDocs (/material-components-site-generator/scripts/lib/platform-site.js:212:17)
at platformSites.forEach (/material-components-site-generator/scripts/build:86:14)
at Array.forEach (<anonymous>)
at reporter.step (/material-components-site-generator/scripts/build:85:21)
at Reporter.step (/material-components-site-generator/scripts/lib/reporter.js:32:22)
at Object.<anonymous> (/material-components-site-generator/scripts/build:84:14)
at Module._compile (module.js:652:30)
at Object.Module._extensions..js (module.js:663:10)
at Module.load (module.js:565:32)
at tryModuleLoad (module.js:505:12)
at Function.Module._load (module.js:497:3)
at Function.Module.runMain (module.js:693:10)
at startup (bootstrap_node.js:191:16)
at bootstrap_node.js:612:3
```
Now we no longer get fatal errors or crash when running the script.
