Skip to content

Conversation

@Jinchul81
Copy link

Warnings have been suppressed according to the following patterns:

  • Applied [[maybe_unused]]
  • Explicitly initialize the member variables in struct.
  • Unaligned type comparison between signed and unsigned. Converted unsigned to singed.
  • Hiding virtual functions in the base class. Declare using base::func.

Copy link
Member

@wgtmac wgtmac left a comment

Choose a reason for hiding this comment

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

Thanks for working on this! I've left a minor comment. Please also fix the linter errors.

std::unordered_map<std::string, std::string> defaults; // required
std::unordered_map<std::string, std::string> overrides; // required
std::vector<std::string> endpoints;
std::unordered_map<std::string, std::string> defaults{}; // required
Copy link
Member

Choose a reason for hiding this comment

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

We don't need to add {} for everything, at least not for STL containers and std::string. Please try to minimize lines of change like this.

Copy link
Author

Choose a reason for hiding this comment

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

It looks like they are necessary. The following warnings occurred when removing the initialization. Do you have any better idea?

../src/iceberg/test/rest_json_internal_test.cc:774:55: warning: missing initializer for member ‘iceberg::rest::CatalogConfig::endpoints’
../src/iceberg/test/rest_json_internal_test.cc:780:76: warning: missing initializer for member ‘iceberg::rest::CatalogConfig::overrides’

Copy link
Member

Choose a reason for hiding this comment

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

I'd suggest adding -Wno-missing-field-initializers to suppress such kind of warnings.

const TableIdentifier& identifier, const Schema& schema, const PartitionSpec& spec,
const std::string& location,
const std::unordered_map<std::string, std::string>& properties) {
[[maybe_unused]] const TableIdentifier& identifier,
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we can remove the parameters' names instead of adding [[maybe_unused]] to keep the code clear.

Copy link
Author

Choose a reason for hiding this comment

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

I am not sure your suggestion seems to be aligned with the original design. These functions overrode the pure virtual functions in Catalog.

Copy link
Contributor

@HuaHuaY HuaHuaY Nov 21, 2025

Choose a reason for hiding this comment

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

I don't get your point. Removing the names in child class don't change the function signature even though it overrides virtual function.

Result<std::unique_ptr<Table>> InMemoryCatalog::CreateTable(
    const TableIdentifier&, const Schema&, const PartitionSpec&,
    const std::string&,
    const std::unordered_map<std::string, std::string>&) {
  return NotImplemented("create table");
}

Copy link
Author

Choose a reason for hiding this comment

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

@HuaHuaY Let's compare the two options. I prefer to use [[maybe_unused]] rather than omitting the parameter name. Adding the attribute can bring better readability and maintenance when enabling parameters.

Copy link
Contributor

@HuaHuaY HuaHuaY Nov 25, 2025

Choose a reason for hiding this comment

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

According to C++ core guidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#rf-unused, [[maybe_unused]] is used when parameters are conditionally unused.
I think it's the responsibility of who implements this feature in the future to add the name back. If we don't need the variable, we should not give a name to it.

Copy link
Member

Choose a reason for hiding this comment

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

I've seen several patterns regarding to this:

void func_a([[may_unused]] int a);
void func_b(int /*a*/);
void func_c(int);

I think void func_b(int /*a*/) strikes a good balance.

case TypeId::kFixed: {
auto target_fixed_type = internal::checked_pointer_cast<FixedType>(target_type);
if (binary_val.size() == target_fixed_type->length()) {
if (static_cast<int32_t>(binary_val.size()) == target_fixed_type->length()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

In general, we should convert small types to large types. There are some similar codes in this PR that need to be modified.

Copy link
Author

Choose a reason for hiding this comment

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

Let me rewrite the change like this:

      if (target_fixed_type->length() >= 0 &&
          binary_val.size() == static_cast<size_t>(target_fixed_type->length())) {
        return Literal::Fixed(std::move(binary_val));
      }

Copy link
Contributor

@HuaHuaY HuaHuaY Nov 21, 2025

Choose a reason for hiding this comment

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

I don't think we need to check the length is not smaller than 0.

Copy link
Author

Choose a reason for hiding this comment

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

Okay, let me assume the rhs will never have a negative value.

}

std::shared_ptr<Type> CreateListOfList() {
[[maybe_unused]] std::shared_ptr<Type> CreateListOfList() {
Copy link
Contributor

Choose a reason for hiding this comment

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

@wgtmac Does this method not being used mean we are missing some tests?

friend bool operator==(const Schema& lhs, const Schema& rhs) { return lhs.Equals(rhs); }

private:
using Type::Equals;
Copy link
Contributor

@HuaHuaY HuaHuaY Nov 20, 2025

Choose a reason for hiding this comment

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

@wgtmac It seems that we should override the Equals methods in Schema instead of adding Schema::Equals(const Schema& other) const at line 108?

Copy link
Author

Choose a reason for hiding this comment

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

@lidavidm Did you intend to introduce non-overriding function Equals in this commit ebacc54?

Copy link
Author

Choose a reason for hiding this comment

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

Let me keep this change because this commit is to refactor the code.

Copy link
Contributor

@HuaHuaY HuaHuaY Nov 25, 2025

Choose a reason for hiding this comment

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

I didn't make it clear. This and the previous comments are just to remind wgtmac. You don't need to modify these.

@Jinchul81 Jinchul81 force-pushed the main branch 3 times, most recently from 973954e to 01503af Compare November 24, 2025 19:25
@Jinchul81
Copy link
Author

I believe we need to treat compiler warnings as errors. May I include it in this PR?

@wgtmac
Copy link
Member

wgtmac commented Nov 25, 2025

I believe we need to treat compiler warnings as errors. May I include it in this PR?

I think it is worth doing if the effort is manageable. In practice, we may need to add some compiler flags to suppress some warnings that are too strict or unnecessary. Sometimes a toolchain upgrade may emerge a lot of new warnings that do not show up in the past.

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.

3 participants